介意为什么要结婚。

@mumbler chia 过气后差不多 2023 年的时候满地都是低价矿盘，多到厂商都开始减产了否则库存都清不掉。

小硬盘是贵的，成本占了大多数。2T 卖 300 ，1T 也差不多卖 300 ，再往下要是有 0.5T 甚至 0.1T 的可能也得卖 300 。
往上你要找便宜的，12T 的二手盘也出过六七百的价格。

@wangxiang86 对，我忘了扣掉本金了，应该是 15-5=10 万利息。

相当于省下了 5 万块本金对应 28 年的利息。4%的 28 年是 3 倍，还 5 万差不多等于省下 15 万利息？

重度 Git 用户，日常使用 SmartGit 。

是 AI 读了高质量的技术内容以后才写出来的。大家都不写高质量内容的话，AI 读西北风去呢。

啊？ 799 ？官网 16+512 现在是 699 啊？我是首发买的，有个 coupon -30 ，最后是 669 到手，折算下来 4852 。京东同配置不打折是 4799 ，打折是 4059 ，美中差价就是一个京东折扣补贴的差距。

你如果只是想要纯净系统的话，买国行回来刷海外 ROM 就完事了。如果刚需 esim 和海外频段才考虑买国际版吧。

> 等你在什么都没点开的情况下也中了勒索病毒、盗号木马，造成了很大损失，你也会重视的

这不就是 CPU 侧信道攻击吗？插了 CPU 的全中招了。

你自始至终都没有对 Before 和 After 做过具体的案例分析，帖子里基本就是一些假大空的呐喊，什么坚持明文啊什么舒适区啊什么天性啊。怎么不上点干货呢。

这么高一层楼 200 来个回复，说句实话，非常给你面子了，因为讨论的过程还算礼貌，v 站大多数人也不愿意说脏话。换到激进点的论坛里，就不知道是你保卫家人在先，还是管理员看不下去直接 ban 号在先了。帖子内容太过贫乏，甚至激不起我一点讨论技术的欲望。有句话叫，非蠢即坏。看你讨论过程，好像也不像是坏，那可能只是真不懂了。但最可怕的是不懂还觉得自己是对的，有一种老子说的才是对的，你们不同意那一定是你们都是傻逼。那这就没法聊下去了。

大家的耐心是有限的，有些人「蠢」，是因为缺乏知识，旁人点拨一下，去学习了知识，懂了，就不「蠢」了。有些人坚持自己错误的想法，大家劝了劝，发现没什么用，那只好 block 之，以免浪费自己时间。

看到这种纯粹引战的 append ，我的耐心已经用完了。觉得自己老牛逼了，看别人都觉得傻逼的人，我诚挚建议你，以一种圆润的动作姿态离开这个看法和你不同的人组成的社区。

言尽于此，block 了，请勿再回，我不会收到提醒，也不会再浪费更多的时间在这个帖子里了。

@lesismal
> 你有没有想过, 很多黑产搞到东西, 但每年我们看到的新闻有多少? 被你知道的泄漏了的只是冰山一角, 你没看到不代表明文就安全了, 也不代表改造后就没带来更全的安全性.

谁出钱谁说了算。你出钱吗？你不出，所以你说了不算。

你尽管叫破喉咙，但破喉咙是不会来理你的。决定企业做什么的是企业的老总，是 org 的负责人，是 PM ，是 tech lead ，不是你。当然你可以自愿加班去完成我上面说的那些，但这关我什么事呢。你是想说服我无偿加班给公司项目加这个功能吗？我可太谢谢你了。

在资本的社会里谈理想，你的想法是不是有点太甜了。

其实刚刚又想到个事。
加密通信的时候，加密的算法和代码要不要保密或者混淆？
可能有人会觉得，加密算法当然应该保密，攻击者拿不到加密解密方法，那不就安全了吗。

但……

针对 append 部分
一共三个 part: client 端的安全, 传输信道的安全, 传输信道之后的 server 端所有流程的安全. 这其中不只是技术本身的算法流程, 最高可以到社工范畴
你们很多位, 只盯着 1 或者 2 个 part 说没用. 但目的是让完整链条的安全级别提高.
即使不用明文并且增加各种额外手段也不能 100%, 比如绑架了. 但用明文是为了在技术上让完整链条 3 个 part 的整体安全级别更强一些.
所以, 我建议各位, 不要只拿出一个 part 来说用这用那都没用.

==========

我感觉你说了这么多还是没讲到点子上。我觉得你最好重新整理一下自己的思路，否则就我看评论区的样子大家都在各说各话，讨论不到一块儿去。

就拿我司我们 org 的习惯来说吧。如果你要做一项比较大的功能改动（你说的前端加密就已经是比较大的改动了），一般需要先开一个 wiki page 把改动写在文档里。
文档分几个部分，首先是摘要，说明现状如何，遇到了哪个具体的问题，会造成什么样的后果，产生什么样的经济影响。（比如出了一个 bug 造成 3 个客户的业务离线各 3 小时，这就是经济影响。）然后是你的大体设计，这里一般简单说几句画个流程图什么的就行了。然后是产生的实际影响，比如说原本一个 bug 造成某个操作需要花 3 小时跑完，修复了 bug 只要 1 小时就能跑完，等等。

从我读你帖子和回复的内容来看，我并没有看到（ 1 ） HTTPS+明文这样的设计会造成很大的经济影响（例如大规模密码泄露，账号被盗等等），（ 2 ）你设计的解决方案会产生什么样的经济影响（例如原本 v 站大量账号被盗，经过你事故分析，确定是明文传输造成的，如果做了你这个方案，账号就不会被盗了等等）。

如果这是你自己的个人项目，躺在沙发上看电视无聊了突然一拍脑瓜想到了这个方案，爬起来给自己网站加上，这倒是无可厚非的。但是对于正规的企业级项目来说（不管是 GitHub 也好百度也好还是 Amazon 也好），一个 Jira 的立项是需要 business justification 的。就拿我们组的项目来说，修改一处很小的逻辑，也要经过（ 1 ）事故单或者 Filer 提需求（ 2 ）需求分析并撰写 wiki page （ 3 ） Manager 和 Tech lead 审核批准，如果是跨部门的单子还需要其他部门的底层员工和 Manager 签字（ 4 ）确定上线时间，和 Release Management 沟通（ 5 ）写代码，然后为代码写测试覆盖（ 6 ） Peer review （ 7 ）开服务器然后组内测试（ 8 ） FullTest 自动化测试（ 9 ）质量控制组人工测试（ 10 ）运维组人工测试（ 11 ） Demo tenancy 上线测试（ 12 ）分批灰度上线测试（ 13 ）完整上线，正式结案。

当然，不同公司规模不同，流程也不尽相同，但归根结底不要忘记了，加个功能不是拍个脑瓜公司就批给你那么多人工的，工程师又不是天天闲着没事干，处理更高等级的任务都忙死了，为什么要浪费时间处理一个无所谓有无的东西，除非你能说服你的 Manager ，不做这件事就会造成公司损失，否则没人会鸟你。

个人项目，还是那句话，你想做尽管做就是。但不要随便把手指指向别人的项目。这种行为我们有个很常见的说法，叫外行指导内行。

@cybort #160 你说的没错，所以才需要推广密码管理器，一站一码。
前端加密不是解决明文存储密码的方案。毕竟，都为了安全去搞前端加密了，怎么还会去明文存储密码呢……

看了你贴的知乎讲 github 和百度的那个帖子。但是有趣的地方就在于，百度的登录请求的那张图里，其实并没有做过 MITM 中间人防护。也就是说，虽然客户端找服务器拿了公钥，加密了密码然后再发回，但其实客户端并不知道拿到的这个公钥是真的由百度发出。HTTPS 证书世界里，要伪造可信证书是很难的，要是哪个厂敢生成他无权生成的可信证书，没几天他的 CA 就要被全球吊销了。但帖子里讲的这种非对称加密就没有这种认证机制。如果有人有心去主动攻击百度的登录服务，这种额外的加密是不堪一击的，攻击者只要自己生成秘钥对替换掉百度的公钥，然后从用户侧拿到数据解密即可完成密码破解。