@drymonfidelia 说错了，应该是难点在哪里

@stimw 把 context 转换为只对这个 session 有效的参数有什么难度？

@leesa 我早就看过这个了，“对于已启⽤⾼级数据保护的⽤户，” “在某些情况下，Apple 可能会保留与这些 iCloud 服务相关的有限信息，如果请求⽅提出在所在国家/地区合法有效的正当请求，则可以获取这些信息 (如有)。” 都是这种模糊的话，完全没有参考价值

@leesa #49 补充：国区 iCloud 是写明了 由云上贵州运营，你觉得运营方有可能没有对自己服务器的完整控制权吗？ gov 要调取数据完全不用经过 Apple ，经过云上贵州这个国企就够了

@leesa 在中国，iCloud 是云上贵州的服务器，不是 Apple 的服务器，Apple 无权拒绝。在美国，你觉得 Apple 有可能拒绝吗？前几天币安的事还没结束你就忘了？

@leesa 另外 Apple 设备在任何情况下每 7 天一定会要求一次密码解锁（停用 Face ID 、Touch ID ），在很多情况下这一间隔会缩短，因此绝大部分用户不会使用 8 位以上长密码。

@leesa 虽然没有准确数据，但绝大部分用户的锁屏密码是 6 位数字，因为在解密 E2EE 数据时输入密码的界面无法切换密码类型，Apple 服务器上肯定存储了密码类型。另外你贴的文章中“每次尝试约耗时 80 毫秒”是建立在 Apple 的移动设备+单线程计算前提下的，在从 Apple 服务器中获得数据后可以多线程计算进一步缩短时间。

@drymonfidelia 大概是这个意思，合同原文不方便贴

另外我做的外包合同都会写一条 仅包含甲方作为产品最终客户的授权，如果需要二次销售产品本体，每份授权收取项目预算 45%授权费

如果后续还可能合作就尽量舔，否则如果合同已经执行完了，没约定二次授权相关内容的话直接拉黑吧

@ZE3kr 我已经考虑到了这一点，参考 17 楼，你的 Apple ID 密码登录时是明文 POST 上去的，云上贵州极大概率会 log 全部的登录 payload

@leesa 另外我不确定 Apple ID 本身的密码是否参与加密主密钥（大概率没有），我也没逆向过它的实现，我的工作不是逆向，但是有又怎么样，登录 Apple ID 的时候你的密码是没经过任何加密直接 post 上去的，登录协议早就有人逆向好扔 GitHub 上了，随便搜了一下 https://github.com/majd/ipatool/blob/6597f5ac77a9e2323529604feaac6ba29c73366b/pkg/appstore/appstore_login.go#L63 不管你信不信，我是 100%不信真想解密你的数据的时候靠 Apple 服务器上的数据做不到。

@leesa 另外因为业务的原因我刚好有研究过 iCloud 这个端到端加密，密钥怎么来的、怎么存 Apple platform security 里都没提，完全是黑盒，可能有后门的地方很多

@leesa 即使是国外，大公司也不可能妨碍执法部门（虽然表面上要表现地非常尊重用户隐私），不然下场就和以前的 MEGA 一样直接服务器被抱走了（现在的 MEGA 已经不是以前那个 MEGA 了，创始人都被赶走了 /t/210095 ） 这也是很多极客不相信大公司的原因

不过 Apple 这套功能也不是完全没用糊弄人的，至少在数据泄露的时候黑客不可能把每个人的数据全部暴力破解跑出来再卖

@leesa 是有后门的，你试试在新设备上登录解密，即使其它设备全部离线关机新设备也只要输入任意一个有加密数据的设备的锁屏密码就能解密，苹果交出 iCloud 数据的时候能暴力破解，大部分人锁屏密码都是 6 位数字，即使用慢哈希算法搞到主流平台解密一次要 1 秒，总共就 100 万种可能你觉得并行跑一遍要多久

@daniel8642 #10 “小众软件”是重点，只要你在国内做大一点，即使没出事也必然让你下掉，要不出事了监管部门有责任 v 站上大部分人都只是开发，没真在国内运营过服务，不了解有多少困难

@xausky 115 可以不管是因为都是实名的，把用户数据交出来就能撇清责任了

@xausky 错了 管不管你取决于做的大不大以及有没用户拿你的产品干坏事，你做的不大即使有分享功能，没人拿你产品发违规内容找你做什么？做大了即使没有分享功能，开发菠菜的人用了你的产品，数据在你服务器上，cop 找你拿数据，你拿不出来，那就抓你进去充业绩，想发个案例搜索不到了