日常正常用官方原版的就好，安装速度这种一次性的时间成本不需要考虑吧？

@lisxour #32 LTSC 也是微软官方的哇，有什么问题吗？

断网不行，需要联网的，Android 和 iOS ，NFC 读出加密数据，联网验证

访问 https://www.google.com/ncr 有用吗？

有没有一种可能，他图标就是只有主体，周围是透明的，只不过 iOS 给加了背景色

这个我理解就两个情况吧，创建一个元素，编辑，确认，这个时候你是直接合成到图片上还是不合成，合成了就只有一个视图了，不合成就是视图叠加了，后续可以继续编辑。

@cooltechbs #5 这个功能是不是部分 Android 是自带的？我的 24 小时挂机的 Pixel 就是一直连着充电，但是偶尔看屏幕上显示的电量会掉到 60 多

写过 Go 的话，Go 本身不就是可以直接跨平台编译吗？甚至简单到只要指定个环境变量就行了。但仅限于纯 Go 代码，没有 C 依赖的。

@pkokp8 #12 权限的话，就是当前用户的权限，如果禁用了 UAC 警告的话，可以无提示自动提升为管理员，没禁用的话提权默认会弹警告，但如果有提权漏洞利用的话，也许也可以绕过 UAC 警告弹窗直接提权到管理员甚至更高。

@cnbatch @RobinHuuu 经过排查，不是 MTU 的问题，但是感谢提供 ping 的思路，通过 ping 发现具体的问题了。

通过 ping ，发现只有 icmp_seq 序号为偶数（ 0 、2 、4……）的 ping 包才能收到响应，而奇数的包都是超时。就去排查 nftables 规则，发现问题所在：

我给指定服务器做转发，是在 nat 的 prerouting 链上判断目标地址为 17 服务器的包打上 meta mark ，然后在 ip rule 里匹配 fwmark lookup 表，default 路由到 Wireguard 的 wg0 出口。

看了下文档，nat 链只在第一个包会命中，后续包就跳过了。因为有 conntrack 跟踪数据包信息，所以 UDP 包也是只在第一个包会命中，后续包不会命中，导致只有第一个握手包发给了 Wireguard ，后续包都从物理网卡直接出去了，导致了 conntrack 同一个内网 IP + 端口对应不同的出口，触发了 conntrack 的 destroy ，所以服务端响应的包就找不到 NAT 回复的目标了。

我自己写的 UDP 测试程序之所以没问题，是因为每次电脑端每次发送都是用的随机 UDP 端口发一个包，conntrack 只跟踪第一个包，所以正常。如果给客户端代码也加上 bind ，使用相同端口来请求，就会发现和 ping 一样的，一次通，一次不通，分别是 conntrack 的 NEW 和 DESTROY 。

解法是在 meta mark set 的同时加上 ct mark set meta mark 给 conntrack 也打上标记，然后加了个 filter prerouting 的 mangle 链，匹配 ct mark 也设置上 meta mark set 就好了。

软件的数字签名，开发者用私钥签名，用户使用公钥验证软件来源且未被篡改。

@lxh1983 #2 我觉得网盘数据本身就得分两类：
一类是大文件影视作品这些，本身需要秒传且没必要加密，且加密耗时长、资源消耗大。
另一类是用户相册备份，包括照片、视频，这一类文件本身就几乎不存在文件去重的，每个手机里的相册都是独一份的，而这一部分才是需要加密存储的。

所以完全可以做到区分存储容量，相册备份和共享存储。通过相册备份的，加密且不可分享，要分享，就解密挪到共享存储里面去，既然都要共享了，也就没有加密的必要了。
当然，也可以进一步，相册共享加密，分享的时候用端到端加密共享密钥，但就不允许回收权限了，

@hiboshi #16 貌似说不太通。目前看到的复现案例，有多个数据一样的，甚至顺序都一样。
如果是国内 ID 和新加坡 ID 冲突，导致新建的国内相册 ID 碰撞到了新加坡相同 ID 的数据。那就解释不通多个人能碰撞到完全相同的相册了，国内新建相册 ID 不至于都重复吧？

WebAssembly 了解一下？可以把各种语言 C/C++, Rust, Go 等编译到浏览器运行。
在浏览器环境下，JS 需要由 HTML 来加载，WebAssembly 需要由 JS 来加载，这都是为了向前兼容。
古旧浏览器不支持 JS 的，在 HTML 里可以打印降级提示，旧浏览器不支持 WebAssembly 的，也可以用 JS 写降级逻辑。