Seal 想替你保管身后信，但信任不能只交给密码学
据 Seal 开源仓库，这款面向 iPhone 和 iPad 的独立项目，希望让用户把信件、文件和重要线索加密留给指定的人。项目称已于 9 月提交 App Store，目前提供 TestFlight；同时明确写出：没有独立安全审计，不能把它当作重要钱包种子词的唯一备份。
作者：沈南乔｜OC 社会影响编辑
据 Seal 开源仓库，这款面向 iPhone 和 iPad 的独立项目，希望让用户把信件、文件和重要线索加密留给指定的人。项目称已于 9 月提交 App Store，目前提供 TestFlight；同时明确写出：没有独立安全审计，不能把它当作重要钱包种子词的唯一备份。
一句话结论：数字遗产工具必须同时解决保密、交接和长期可恢复性，其中任何一项都不能靠“用了加密”来代替。
人不在的时候，产品才迎来真正的考试
普通笔记软件出故障，用户还能回来修正。身后交接工具的特殊之处，是最需要它正常工作时，最了解资料的人可能已无法解释。收件人不知道在哪里找、该找谁、哪份信息最新，都可能让技术上完整的备份失去实际价值。
Seal 用每人一份信封、分散保管的密钥份额和定期报平安来组织这个过程。它不运行自己的后端，但仍依赖 Apple 的 CloudKit 存放密文与相关记录。“没有自建服务器”因此不能理解为完全离线，也不能理解为不依赖外部平台。
这种设计的吸引力很明确：开发者不必持有能解开所有内容的一把总钥匙。不过服务依赖、设备更换和家人多年后能否操作，仍是另外一组需要验证的问题。
谁能打开，和什么时候打开，不是同一个保证
项目采用门限分片，让达到数量要求的持有人参与释放；收件人的设备还承担自己的解密角色。这样可以区分帮助交接的人和最终读信的人。
但 README 也指出，倒计时不是密码学时间锁，而是诚实客户端遵守的签名记录流程。足够数量的持有人与收件人合谋，仍可能提前打开。它不是一个数学上保证“某天之前绝不解密”的保险箱。
这不是一句小字可以带过的例外，而是用户选人的依据。信任对象之间是否相互独立，某个人失联后怎么办，家庭关系改变后怎样撤换，都会影响承诺能否持续成立。
可检查的记录，也有检查不到的部分
Seal 提供独立验证器检查导出的签名记录，这是值得肯定的可迁移设计：不把所有验证都锁在某个 App 按钮里。
不过项目也说明，验证签名不自动证明记录完整。一个事件是真是假，与是否还有事件被遗漏，是两种问题。若不同参与者持有的记录不一致，就需要比较它们，而不是看到“签名有效”就结束审查。
同样，源代码公开不等于发行二进制已被验证与源码一致；作者自己披露的审查，也不等于外部独立审计。将这些层次分清，才不会把透明度当成已经通过安全认证。
从低风险资料开始，先练习交接
OC 不建议读者因为一个精巧方案就迁移不可替代的秘密。更适合先验证的是低敏感线索：重要纸质文件在哪里、有哪些账户需要联系、家人应先找谁。使用前应完整演练恢复过程，并保留独立备份。
还要把软件交付与法律授权分开。收到一段密码、一个文件，并不自动获得处置相关账户或资产的权利；具体安排不能仅靠 App 里的角色名称决定。本文评估的是产品设计，不把它当作法律遗嘱的替代品。
真正可用的交接工具，应该能承受人忘记打开应用、设备损坏、联系人离开，以及开发者停止维护。它需要的可靠性，远比一个顺利的首次演示更长。
关键事实
- 阶段：项目方称提交 App Store，TestFlight 可试用；不是已完成独立审计的成熟保管服务。
- 依赖：无 Seal 自建后端，但使用 CloudKit。
- 信任：门限参与者与收件人仍是安全模型的一部分。
- 限制：倒计时不具备密码学强制时间锁保证。
OC 判断
沈南乔认为，Seal 最值得讨论的是它愿意公开限制，而非“谁也打不开”的漂亮说法。身后交接产品应先证明家人能恢复，再讨论能存多少秘密。透明披露是起点，不能替代外部审计与长期恢复演练。
为什么重要
- 对开发者：恢复路径与退出路径必须和加密一起设计。
- 对家庭：联系人、设备和备份需要定期核实。
- 对用户：暂不把高价值、不可替代秘密的唯一副本交给未经独立审计的工具。
评论
围绕这篇文章补充信息、提出问题或分享观察。