用 CloudKit 实现一个私密的小圈子社交软件 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
这是一个专门讨论 idea 的地方。

每个人的时间,资源是有限的,有的时候你或许能够想到很多 idea,但是由于现实的限制,却并不是所有的 idea 都能够成为现实。

那这个时候,不妨可以把那些 idea 分享出来,启发别人。
andyzhshg
V2EX    奇思妙想

用 CloudKit 实现一个私密的小圈子社交软件

  •  
  •   andyzhshg 313 天前 3070 次点击
    这是一个创建于 313 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近在研究 Apple 的 CloudKit ,基本上通读了相关的文档:CloudKitCloudKit Web Service

    CloudKit 基本上可以认为是一个支持存储用户私人数据的 NoSQL 数据库,其本身的设计保证了即使是 App 的开发者也无法访问用户的私人数据,可以有效的保护用户的隐私。这使得其非常适用于私人数据的同步,比如记账类,日记类的 App 。

    但我的关注点在它的另外一项功能,也就是分享Shared Records,使得可以在用户可控的情况下分享指定的资源(虽然这个分享实操起来比较复杂)。

    我的计划是通过分享功能创建一个私密的小圈子社交( Apple 的文档说一个记录只能分享最多 100 人),用户之间可以通过创建分享记录,来查看彼此的信息。

    这整个过程,都可以仅基于 Apple 的 CloudKit API 完成!虽然实现起来很复杂,但是开发者可以无需提供自己的网络服务,好处有几个:

    1. 解除用户对开发者的隐私疑虑,开发者看不到用户的数据 [可以通过开源,或者测试 App 是否链接 Apple 之外的外源服务来审计]
    2. 解除用户对服务持续性的疑虑,因为不使用 CloudKit 之外的任何外源服务,所以原则上只要 Apple 不倒闭,或者不关闭 CloudKit ,用户就可以继续使用。

    问题:

    1. Apple 生态的封闭性,很少看到在 Apple 生态之外使用 CloudKit 的案例,但是读过CloudKit Web Service文档之后,我认为 CloudKit Web Service 提供的能力是与原生 Apple 平台等价的,可以借助 CloudKit Web Service 实现 Web Apple 甚至是其他平台的原生 App 。要求是用户至少有一个 Apple ID 。
    2. 国内的特殊生态,众所周知,Apple iCloud 在中国是独立的由云上贵州运营的,不可避免的就会有各种问题,我目前测试的是通过 CloudKit Web Service 的授权登录国内账号返回的 token 不可用,但是通过设备 Native 获取的 token (CKFetchWebAuthTokenOperation)又可用;也有人说分享功能在国内不可用(/t/1035315);更别说国区账号和外区账号是否可以 share 更是需要测试。

    抛开问题不谈,我觉得理想状态下,这非常适合实现一个类似私密朋友圈的社交软件,三五好友,或者家人之间建立一个小的圈子,分享些照片视频之类的,无需担心被平台窥视(当然,你是你相信 Apple 不会作恶窥视你的信息的前提下)。

    大家对这个有什么建议,或者有类似想法或者使用过 CloudKit 踩过什么坑的都可以来分享一下。

    30 条回复    2025-01-29 11:44:05 +08:00
    richard1122
        1
    richard1122  
       313 天前
    没有做过 iOS 开发,想请问下这种 Shared Records 可以跨云吗?也就是说云上贵州和 global 的用户能够共同访问同一份 records ?
    andyzhshg
        2
    andyzhshg  
    OP
       313 天前 via iPhone   1
    @richard1122 我还没有测试到这一步,目前看是不乐观。
    icestraw
        3
    icestraw  
       313 天前
    我觉得不好,这就不是技术问题。你自己开发了程序,你也是平台啊,就因为你说“你只用 CloudKit”我就相信你不上传数据?作为用户无法证实的话,你数据放在哪其实都一样,大多数用户也不在乎这个。
    musi
        4
    musi  
       313 天前
    “其本身的设计保证了即使是 App 的开发者也无法访问用户的私人数据,可以有效的保护用户的隐私。”
    不理解怎么保证的
    你存的数据不是用 app 存的吗? app 都是你开发的你在存之前把数据往云端推一份这做不到吗?
    SayHelloHi
        6
    SayHelloHi  
       313 天前
    有没有啥好用的 CloudKit 库推荐
    SingeeKing
        7
    SingeeKing  
    PRO
       313 天前 via iPhone
    #1 #3 #4 的问题 op 不是直接在帖子里回复过了吗…
    icestraw
        8
    icestraw  
       313 天前
    @SingeeKing 他觉得他回复了。实际操作上,用户无法一直抓包检查看开发者是否做了坏事,用户即使抓包了,也无法得知他到底是这时候没传,还是一直没传。用户也没办法单独把这个程序的网络权限给关掉。程序在无网环境其实也无法运行。所以说,他说的只是开发者的角度“理论上”可以这么做。

    这从来就不是技术问题,作为开发者本来就应该为程序的隐私背书,也必然是保管隐私的第一责任人。什么技术反而是其次,假设开发者用了“安全”CloudKit ,但是犯了一些代码上的错误,或者错误接入三方 SDK ,导致隐私泄露,这种可能性也是有的,但那也是不行的啊,也不能说“我用 CloudKit 所以我安全”。归根结底,责任人是程序发行商。用户也只会信这个。
    leo72638
        9
    leo72638  
       313 天前 via iPhone
    有这些需求不如直接用 iMessage 群组和 iCloud 共享相册
    wyd011011daniel
        10
    wyd011011daniel  
       313 天前
    @icestraw [可以通过开源,或者测试 App 是否链接 Apple 之外的外源服务来审计] 他不是括号括起来了么。 那肯定表示在这个条件下解除用户对开发者的隐私疑虑。

    你说“不能说“我用 CloudKit 所以我安全””

    但他说的是可以通过开源,或者测试 App 是否链接 Apple 之外的外源服务来审计后解除用户对开发者的隐私疑虑,他并没有说“我用 CloudKit 所以我安全”。
    SingeeKing
        11
    SingeeKing  
    PRO
       313 天前   2
    @icestraw 你说的没错,事实上你提出的问题和现在我对很多开源的端对端加密的程序的怀疑一样,即使开源 + 第三方审计,我也会怀疑,不可能每个版本都去审计,那么有没有可能现行的版本增加了漏洞,或是线上的版本和开源的版本不同,更或者是否面临了公司都不知道的供应链攻击。这确实不是一个技术问题。

    但是我觉得,前面几位想表述的问题和你想表述的问题不一样,不然问法不会是那样子的;我更觉得是他们根本没有读完整个帖子,而是看了标题看了开头就直接质疑了
    UPVzxvnU1N5OhCZS
        12
    UPVzxvnU1N5OhCZS  
       313 天前
    op 的产品包含个人隐私保护和社交属性,可以看看能不能加强或发散一下这两个属性。
    wyd011011daniel
        13
    wyd011011daniel  
       313 天前
    @wyd011011daniel

    这种安全的体现方式是“ app 不会向除了苹果以外的服务器发送消息 ”这件事情第三方软件审计或者开源 app 都可证明。

    但第三方服务器用户无从得知开发者的操作也无法审计。

    区别在于提供了证明开发者没有获取数据的方式,用户当然不可能审计无时无刻审计,但有的用户可能会审计,有的用户可能看的懂代码。如果这里有一个人发现有问题并给出证明,那么开发者就身败名裂。

    类似的开源软件内审查是否有问题的方式也类似,一方面代码公开 一方面谁都能运行代码并测试是否有异常流量。

    我想说明的是 使用 cloudkit 并且通过开源,或者测试 App 是否链接 Apple 之外的外源服务来审计 相对于 开发者使用自己的服务器。是会带来更多的安全性和可审核性。
    andyzhshg
        14
    andyzhshg  
    OP
       313 天前
    @SayHelloHi 目前在 Apple 原生平台之外还没有发现特别流行的库,苹果有一个 CloudKit.js ,应该可以用来开发 Web App ,但是也没见到比较有名的应用案例。
    如果思路可行,我倒是有计划基于 CloudKit Web Service 封装一个 flutter 的 package ,如果真做出来了会开源出来。
    andyzhshg
        15
    andyzhshg  
    OP
       313 天前
    感谢大家的回复 @wyd011011daniel @SingeeKing @icestraw @musi
    看来大家对隐私的顾虑都很大,确实通过开源或者外部审计无法打消用户的顾虑,但如果这是一个可行的商业模式,开发者是没有动力来主动破坏这种信任的,就像苹果的所谓隐私保护,也是因为大家相信他不会抛弃自己赖以生存的卖点为前提的。
    除了隐私之外,我觉得这个方案的另一个特点被大家忽视了,就是服务的可持续性。为什么小开发者没办法做网盘之类对可持续性要求高的应用,就是大家会担心万一开发者撂挑子不干了,我的数据就没了。采用这种方案可以不恰当的理解为这就是一个单机应用(我甚至在考虑加一个本地存储选项,用户的云端数据在本地都有镜像备份,当然确实会浪费设备的存储空间),并且从第一个版本就提供数据的导出功能。维持一个没有服务端的 App 的成本是远低于维护大规模用户云端服务的成本的。
    总之吧,目前也还是构想阶段,只是想了解下大家的想法,集思广益。
    wyd011011daniel
        16
    wyd011011daniel  
       313 天前
    @andyzhshg 可持续性有个有意思的点 在于开发者不能主动下架 app 然后开发者要持续支付年费。(当然不续费使用过的用户还是可以去下载的)

    最好的可持续我想是便捷的导出为可理解的格式。譬如 qq 聊天记录是可以导出为 html 格式的。或者健康心率之类的导出为 json 格式。

    这样如果 app 不幸终止服务,用户也可以相对轻松(python 脚本或者第三方工具)导出数据转换到别的平台

    当然别的平台也需要有导入手段。
    andyzhshg
        17
    andyzhshg  
    OP
       313 天前
    @wyd011011daniel 我觉得支持两种格式就可以,一种是可读性强的格式,比如 PDF 或者 HTML ;一种是结构化的数据,比如 json 或者是直接是一个 sqlite 文件之类的。

    不过因为开发者的成本基本只剩开发者年费了,这个成本其实是很低的。
    FringJX
        18
    FringJX  
       313 天前
    这个类型的 app 已经有了, app store 搜:遇见夏天
    icestraw
        19
    icestraw  
       313 天前
    @andyzhshg 你说的这个其实就比较像微信小程序,或者 iMessage 里的小插件。完美符合“不存储聊天记录,但是提供额外功能”这一点。甚至不联网。不然,如果你不保存,不拥有聊天记录,只提供额外功能,你完全没必要设计聊天程序本体,承担不必要的责任。

    @wyd011011daniel 可以分析一下这个信任链:

    1. 开发者开源=>用户可以审计代码
    用户会吗?每个用户都审计代码吗?

    2. 开发者开源=>用户信任
    用户怎么知道,开发者上传到商店的二进制,是开源的代码编译成的二进制?二进制需要签名的,校验哈希都没法用。做 GitHub Actions 自动打包?那先不说可不可行,是不是又引入了一个新的,需要信任的对象呢?

    3. 审计
    无论什么审计方法,都引入了额外需要信任的对象。而对于终端用户而言,信任的对象越少越好。不然安全性从何而来呢?苹果的 CloudKit 也会用 Azure ,也会用 AWS ,但是苹果没有要求你额外信任这些公司,只是自己承担了责任。


    @SingeeKing 我感觉他们很多是想从代码层面证明,这是一个比较 Geek 且可行的想法,但是和现实应用差距很大。
    icestraw
        20
    icestraw  
       313 天前
    @SingeeKing 而且他们不可能搞真的端到端加密的,相比加密和隐私,他们承担不起“用户忘记唯一的密钥,数据丢失”的风险。我记得苹果 iOS10 还是 11 的时候搞了个 像那么回事的 端到端加密的钥匙串,一旦密码想不起来,他就给你钥匙串全删掉。估计后来因为太多人忘记密码,被人喷狠了,逻辑就改了很多。
    gogo88
        21
    gogo88  
       313 天前 via iPhone
    “关于”这个页面内容排列有点怪异。“客户支持”“五星好评,分享 App”这些非功能类的东西是不是应该放在“实验室”下面?
    wyd011011daniel
        22
    wyd011011daniel  
       312 天前
    @icestraw

    1 用户审计代码是指所有用户中有一部分愿意审计代码

    2 还有“app 不会向除了苹果以外的服务器发送消息”这件可以另一个角度证明的方式

    app 不可能知道什么时候在不在被监控对不对,那如果任何时候任意一个用户发现 app 在对除了苹果以外的服务器发送消息,那不就会暴露并且开发者身败名裂。

    上述两个部分是同时互相交叉验证的。逻辑链我来给你缕缕

    1 开发者宣传只使用 cloudkit 并且开源
    2 部分用户审计代码发现代码逻辑里确实没有对除了苹果以外的服务器发送消息
    3 部分用户使用流量监测发现确实没有对除了苹果以外的服务器发送消息
    4 如果用户审计代码发现代码逻辑对除了苹果以外的服务器发送消息 则开发者需要解释或者身败名裂
    5 如果用户使用流量监测发现对除了苹果以外的服务器发送消息 则开发者需要解释或者身败名裂

    对比使用开发者自己的服务器的 app
    1 用户无法确认自己的数据去的服务器是否安全 会不会泄露 (apple cloud 和 开发者自己服务器安全性的对比)
    2 用户无法确认自己的数据会不会被开发者滥用( cloudkit 上传的数据开发者看不了 服务器上的数据开发者看得了)

    那么在 开发者宣传只使用 cloudkit 并且开源 是不是比使用开发者自己的服务器 的 app 有更好的安全性和可审核性?
    wyd011011daniel
        23
    wyd011011daniel  
       312 天前
    @icestraw 我说了 审计方式是使用 app 的用户数量大了必然有愿意审计 app 的看得懂代码的用户 不依靠第三方用户审计。

    即对这种软件的信任来自于用户量大了之后必然存在的 geek 用户,geek 用户可以通过自己审计代码自己检测流量的方式。

    开发者宣传只使用 cloudkit 并且开源
    geek 用户可以通过自己审计代码自己检测流量
    没有问题爆出来即软件相对使用开发者自己的用户更安全

    你对我的反驳完全来自己于期望用户能够完全掌握 app 的审计等工作以实现对软件安全性的完全掌握。

    但这是事实上不可能,只要用户期望使用第三方联网的服务,独立个体用户也不可能审计所有代码并且对开发者的服务器也没有任何审计能力。

    但是 cloukit 的信任链很容易建立不是么,只要软件宣传只是用 cloudkit ,任意用户发现异常并报告则软件生涯结束。
    那么对大部分用户只要软件有大量用户并且没有异常报告就可以认为是可信任的。

    类似的如果一个软件宣传只使用 webdav 上传数据到用户自己的服务器。这也是类似的逻辑链啊。
    icestraw
        24
    icestraw  
       312 天前
    @wyd011011daniel 我为什么感觉我和你观点一样但是结论不一样

    "只要用户期望使用第三方联网的服务,独立个体用户也不可能审计所有代码并且对开发者的服务器也没有任何审计能力。"
    对啊,正因如此,开发者无论用什么技术都无所谓啊,反正用户信任的也是这个 App 。

    问题就在于“他宣传 xxx”和“他实际 xxx”不一定是匹配的。开发者无论宣传的多好,都有可能做出额外的行为来泄露隐私,这本来就是无解的,用户只能选择“相信这个 App”或者“不用这个 App”。
    至于他用不用 CloudKit...真没那么重要,开发者想传隐私信息,怎么都是能传的。方式有太多种了。
    万一他接入了三方统计 SDK ,把数据发给他们了呢?
    万一他用 AppLink 或者剪贴板传递隐私信息,实际发起请求的是别的程序呢?
    哪怕就把它加密传在崩溃日志里,发给 Apple ,也是可以的啊。
    这些需求都是合情合理的啊,防不住的。
    更别提不合理的方式了:我检测到抓包我就不传隐私数据,没有抓包我再传。除非你在网络层抓包,那网络层同一个手机那么多 App 请求,谁知道是哪个 App 发出来的?开发者完全可以检测到手机上装了 qq 我再传,然后我还把隐私信息发给腾讯的统计 sdk ,诸如此类。域名看不出来,内容也是加密的,证书可能还做了 ssl pinning 。根本没法防的。
    wyd011011daniel
        25
    wyd011011daniel  
       312 天前
    @icestraw

    我认为你和我的逻辑是反过来的

    你认为技术无论如何都做不到尽善尽美,所以用哪个技术手段完全不重要。
    我认为更透明更开源的实现方式能给用户更多安全感和安全性。

    这种观点的辩论无意义了。
    andyzhshg
        26
    andyzhshg  
    OP
       312 天前
    看了大家的讨论都集中在隐私上,可见大家对隐私的确实是很关切。
    其实我能有这个想法,第一点是我知道隐私对用户的重要性;第二点也是更现实的一点,就是对于小的独立开发者来说,运行和维护一个用户量越来越多的网络服务,是非常有挑战的,无论是资金还是精力的方面。
    还有个问题前面没有提到,就是这个“社交网络”的数据,实际上是存储在用户的个人空间的,也就是说会占据用户的 iCloud 的存储,如果用户没有额外订阅 iCloud 空间,也会是一个问题。
    icestraw
        27
    icestraw  
       312 天前
    @wyd011011daniel 我认为至少要是“理论成立”的技术信任链,才是证明。否则就是宣传,说得再好听,也是宣传。尤其是开源。其实完全不开放服务端,只开源客户端,同样是一种开源(这不就是 tg 和以前的 iMessage ),而且是“理论成立”的。客户端可以完成加密工作,密钥交换可以私底下进行。只需要客户端做好端到端加密,服务器做什么都无所谓。用户拿开源的代码一样可以接入到服务器,这才是“理论成立”的信任链。CloudKit 的问题就在于,只有开发者用自己证书签名过的代码,才能运行,而这个步骤开发者做了什么是完全不可知的。当然,这不是说 CloudKit 真有问题。CloudKit 应该是一种帮助开发者“尽到保护隐私责任”的工具,而不是“免除隐私泄露责任”的挡箭牌。保护隐私的责任仍必须在开发者。

    当然,像楼主说的,他是“为了减少服务器维护成本”,这当然没问题,而且是好事情。但是一定要和隐私联系上,不太现实。而且这个数据同步的实时性,可能还有点挑战。
    wyd011011daniel
        28
    wyd011011daniel  
       312 天前
    @icestraw 不是哥们,没人说“保护隐私的责任不在开发者。” 太无聊了,感觉自己浪费了好多时间
    icestraw
        29
    icestraw  
       312 天前
    @wyd011011daniel 是 你时间宝贵 有法律效应的隐私协议都没有这种开源有安全感,那我还能说啥。反正对我来说,这种开源我安心不了一点,开源的项目和商店里完全可以是两个不相干的项目。你安心你随意吧...
    agagega
        30
    agagega  
       258 天前 via iPhone
    讨论开源是否可信任有点歪楼了,但我简单 Demo 试过 CloudKit Web Services ,能用是能用,但这玩意连文档都不完整,我甚至怀疑是不是已经不维护了
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     2965 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 34ms UTC 14:11 PVG 22:11 LAX 07:11 JFK 10:11
    Do have faith in what you're doing.
    ubao snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86