@ooooo
1. 如果他们想，当然可以。因为网页版执行的代码是完全从服务器拉取的，只需要（对某个用户） serve malicious javascript 就可以拿到主密钥。即使是客户端，如果开了自动更新 /没有 reproducible build 保证开源代码与二进制对应的情况下也可以做到。
2. 网址本身是暴露给服务端的。网页端显示的 favicon 是从服务端拉取的，没有文章，直接去看代码或者 f12 看一下请求就知道了。

@vpsvps 得了吧，站方是能看到你存了哪些网站的。
并且网页端是对服务器绝对信任的，只要管理员想，给你 serve 的网页脚本里加点东西就能轻松偷走主密钥，什么端到端加密都没用。

chrome 默认插件都是静默自动更新的。
所以可以理解为，10w 个用户的远程代码执行，可以卖多少钱？

那不就是权重么，weighting function

听说贵司喜欢“拔网线”，恰好在关键时刻让用户登录不上被爆仓，如果传言属实的话再“完善”也没用啊，这是 feature 。

肯定是 Draw.io

自己搭建就 bitwarden，不想搭建就 keepass 。

直接保存网页到本地，所有资源全部 inline 。

国外浏览器和国产网站水土不服。

国外网站移动版一般提供一个按钮，你点击以后跳转 app ；相应的国外浏览器也不阻止跳转。
国内网站移动版一加载就尽可能的、不停地尝试跳转 app ；相应的国产浏览器（ via 这种）就会在跳转前询问。

你怕不是完全没理解 vlan 。
vlan 是在二层划分，不同 vlan 之间无法二层直接互通，需要通讯只能通过三层路由。
对于那些无需访问局域网的设备，直接给一个 /31 的点对点连接，即除了访问网关和通过网关访问互联网以外，看不到任何其他设备。
而不同 vlan 之间通过路由连通了，那你就操作路由表和防火墙就是了。划分 vlan 以后你的 nas 对它来说和 baidu 一样，相当于“外网”。

@hronro #5 并不是，自动更新是指（合法地）在用户设备上执行任意代码，通过 appstore 自动更新也满足条件。
关键点只有一个：如果开发者决定对某一个特定的用户进行攻击，那么用户能否抵御。
要实现这样的安全模型，是有一定困难的，包括但不限于：
1. 端到端加密
2. 代码完全开源，经过安全审计
3. reproducible build 和 签名验证
4. 没有“后门”（包括自动更新 /网页版等远程任意代码执行）

总得来说要保证：软件是开源且经过安全审计的 <-> 用户运行的软件与发布的源代码对应 <->每个用户收到的代码完全一致 <-> （更新）代码和签名可验证

放在这个例子里，如果没有自动更新，普通用户除非立刻就盲目地更新到了有后门的版本以外，后续看到新闻，或者官方发布了修复，都不会中招。

@hronro 检查更新可以，自动更新肯定不行。
合格的安全模型应该能对开发商自身进行防范，即使是 cia 敲门 /他们给得实在太多了的情况下，开发商也没有办法窃取到某一特定用户的信息（推送一个含有后门的版本）。

“只读”不就是可下载吗？

不了解 NIO，但是
>怎么判断出这个报文属于什么协议
这个需求看起来很奇怪，你要实现 socket mux 么？ NIO 是个 IO/网络库吧，正常来说不需要判断啊，数据直接给上层，上层按照自己的协议解析。

如果确实要实现 socket mux，那么应该进行 连接追踪，即请求第一次到达并 dispatch 到相应的后端后记录来源 socket，后续来自相同 socket 的数据 dispatch 到相同的后端。

自动更新就是一种“合法的后门”，出现这种问题本身就说明这个秘密管理器的安全模型不合格。

阻塞 /非阻塞 IO 只是把并行处理由系统线程移到用户程序。
根本原因是多任务的实现，线程由于是抢占式的，在切换上下文时不知道需要保留哪些数据，于是只能把栈帧、寄存器等都保留，因而开销大。为了支持大并发降低开销，需要一种机制让用户决定保留哪些状态，而实现这种机制的抽象 /模式就是各种协程 /callback/async 等等。