身边就有例子被爸妈叫回去后闹翻的 然后一边之后辞职出来继续找工作的

slack 有个类似的项目 Nebula
https://github.com/slackhq/nebula

@Dorcoin 感觉空间可能性并不大 现在摄像头都可以突出了 还在追求轻薄的没几个品牌了

增加的机械机构带来的故障率以及维修的复杂性感觉原因更大一些 而且更高的成本也并不会带来更高的销量 对比一下弹出摄像头手机的销量 并没有在同一时间碾压其他没有这么设计的手机

而且手机这种普遍性的东西 应该要考虑不同使用情况的 或许在南方水土好的地方 灰尘没那么大使用时间的确很长 但是在北方尘土大的地方 这个设计的寿命就要大打折扣了

@Dorcoin 你说的都对

但是这么好的方案怎么就无了？而且为什么随便一搜就是各种摄像头弹不出来缩不回去教你怎么修的视频？

这东西一点都不防尘 出问题只是时间问题罢了 怎么可能不易故障…… 真有不易故障的 怕不是成本比你手机都贵了

@itechnology 你应该找公司申请一台新的设备放在家里或者把需要的设备搬到家里 而不是用自己的设备干活 这样是违反公司规定的

@dingyaguang117

国内这个环境 我能想到的唯一有点用处的就是在深信服之下 可能可以对抗一下他的 HTTPS 嗅探 但是一般用深信服也会强制安装公司的证书了 实际上你也很难真的去保证安全

至于说 HTTPS 无差别攻击 如果 HTTPS 真的那么容易被攻破的话 大家还是多担心一下自己的浏览内容为好 毕竟公司层面来说 你浏览的内容也不会比你的账户密码少到哪里去 而且如果密码加密的话 那你的任何表单的人和敏感信息都要加密但是我觉得楼主的 QA 只是集中关注了账户密码 对内容却视而不见

Facebook 的加密一样有人公开分析过了 文章在这里 https://hackmd.io/@Ostrym/facebook-client-side-encryption

只要你的代码要在前端展示出来 那么实际上对于信道攻击的防护只能说是有限保护 真要想完整保护还是需要靠着后端以及依赖与独立的 APP 而不是通过 web 的形式 最好结合 2FA 一起来保证安全 否则这些加密只是再是整个流程变得看起来更加安全

至于说行业场景下 另一个例子就是国内的银行很多都有自己的安全控件 每次登陆都要通过安全控件来做 但是你看一下国外的银行 很多知识间的网页登录而已 并没有要求你去装额外的插件来实现这些 你能说国外的银行这块的安全性做得比国内差么？这几年国内的隐私泄露难道都是因为前端没做密码加密引起的么？

@dingyaguang117 因为你没看底下的评论罢了

RSA over HTTPS 的方案也不是随便拍个脑袋放一个静态公钥吧？你觉得大多数人随便拍脑袋实现一个就比 TLS 设计时候考虑得更加周全么？

何况如果 HTTPS 都被拦截了 多点时间分析你的加密逻辑返回一个修改过的公钥回去又能有多复杂……

反过来说如果不信任 HTTPS 应该给个理由吧 而不是单纯一句我不信任你还要再去加密一下 既然 HTTPS 都不信任 那我自己实现的逻辑就能够信任了么？

@dingyaguang117

安全是个体系 又不是只靠某一个技术来决定的

对于前端而言 保障数据传输中没法被人拦截篡改才是最重要的 至于要怎么脱敏 加密处理 存储这些都是后端该干的事情 远不是仅仅一个 HTTPS 就能做到的事情 而且刨去加密 授权 /鉴权也很重要啊 只不过加密反倒是所有问题里面最简单的一部分也是最成熟的一部分 才会老被人提起来

至于你不停推崇的微博 RSA 登录加密 各种爬虫模拟教程 技术解析满天飞 好像真的打算篡改也没你想的那么难吧？

利用成熟的 TLS 远比自己拍脑袋像一个看起来安全的方案要安全的多

而且用户名密码现在越来越少见了 其他很多验证技术都在解决需要明文密码的问题 只是国内的环境根本铺不开罢了

@dingyaguang117 而且这个问题是个死循环 不信任 https 带来的麻烦远比用户名密码大得多

刨去登录的部分 用户浏览的东西要不要加密？你要不要确认用户浏览的东西没有篡改 会不会让人直接拿到用户正在浏览的东西？ 这么做下去的话那就变成用户不要通过网络看东西了 直接抱着显示器去接着服务器看最安全？而且写所有问题的根源就是 HTTPS 不可信？

说真的 HTTPS 真这么不可信的话 AWS S3 早就用私有协议去设计了 而不是依赖于 HTTPS 了

StackOverflow 上也有人跟你有一样的观点 反驳的观点在这里 https://stackoverflow.com/questions/3391242/should-i-hash-the-password-before-sending-it-to-the-server-side

另外就是随便设计一个看起来安全利用了 RSA 的系统就真的安全么？ TLS 的设计并不是一拍脑袋就想出来的那么简单

@dingyaguang117 说实话 不受信的电脑为什么一定要从你的浏览器拿数据 键盘记录器之类的都多了

而且电脑都不授信了 人家拦截一下你的响应修改一下你的公钥有有多难呢 早些年运营商各种劫持还历历在目呢 甚至还有修改下载地址的呢 而且这是前端 又不是一个单独的登录用的 app

另外你写死公钥也是不安全的行为 这个也是跟安全相抵触的 只是让你的程序看起来了安全罢了 而且你在前端打算怎么校验自己收到的公钥就是没篡改的呢？ HTTPS 至少还依靠证书信任链来校验一下 你前端打算自己实现一套类似的信任链来校验你的公钥么？

微博那套逻辑放在 https 没有普及的年代有意义 但是现在都是 HTTPS 了 如果你连 HTTPS 都不信过 那你自然也信不过现在所有的加密体系了

而且不仅 HTTPS 很多其他的协议都用的 TLS 作为加密传输层 那么你觉得其他协议是不是都得自己再套一层加密才信得过？

@sampeng 在前端做 rsa 某方面来说就是在重新发明 TLS

而且对于不信任 https 某方面来说 其实也不信任 rsa 毕竟在密钥交换阶段用的实现也包含 rsa 如果觉得 https 不安全 那么你在前端实现 rsa 也是一样的问题

整个传输走的是 https 的话 重新发明一遍 TLS 有多大意义

@daveh rsa 的性能消耗很高的 而且这个也不仅仅是前端的事情了 后端不得先弄一套对应的加解密接口给前端用？ 而且你这么造一遍轮子是真的安全了还是只是自己感觉更加安全了？为什么 TLS 选择用对称加密而没用非对称来直接加密数据？

真觉得还是不要在安全领域自己造轮子

@nekoneko 用户都能把不信任的根证装电脑上了 人家真想拿数据还用得着这么费劲么

https 在绝大多数情况下提供了足够的保护了 只要不去用 TLS 1.2 以下的版本 那安全性绝对有保障的 不知道怎么说这个测试…… 就像当年大家问为什么 chrome 密码不加密一样 人家 google 就说了人家都能从你电脑上拿到文件了 还有什么做不到的

信用卡信息说实话感觉在 log 里面泄露的问题比 https 严重多了