由于这个问题很笼统,让我们深入探讨一下。
查看App Store 审查指南,有三个地方提到不应收集用户的联系人。
第一和第二,不应该强迫用户提供他们的通讯录来换取应用程序的功能(用联系人支付;添加了亮点,类似的短语用于应用程序订阅):
应用程序应该允许用户在不执行其他任务的情况下获得他们所支付的费用,例如在社交媒体上发帖、上传联系人、[...]
第三,在服务器上上传和/或存储联系人会影响用户的隐私,并且在以下用例中被禁止:
不要使用来自联系人、照片或其他访问用户数据的 API 的信息来构建联系人数据库供您自己使用或出售/分发给第三方,并且不要收集有关用户设备上安装了哪些其他应用程序的信息出于分析或广告/营销的目的。
这并不排除使用联系人来创建社交图以使您的用户受益。但是,收集所有联系人可能违反数据最小化原则。因此,Apple 建议不要只上传所有联系人,而是使用联系人选择器(请参阅ContactsUI),其中应用程序只能访问用户选择的联系人:
数据最小化:应用程序应该只请求访问与应用程序核心功能相关的数据,并且应该只收集和使用完成相关任务所需的数据。如果可能,请使用进程外选择器或共享表,而不是请求对照片或联系人等受保护资源的完全访问权限。
艺术。GDPR 第 32 条要求您采取
[…] 最先进的技术、实施成本以及处理的性质、范围、背景和目的 […]
考虑到。
我认为该过程必须透明(如向用户解释的那样):
- 用户应该可以控制哪些联系人用于发现。全部都是有效的选择——选择的联系人(通过联系人选择器)或手动输入联系人信息(电话号码、电子邮件——无论用于您的联系人发现过程)也是有效的选择。
- 即使用户拒绝访问联系人,该应用程序也应正常运行。在这种情况下,您仍然可以提供联系人选择器或手动输入。
- 您必须在您的隐私政策中描述该过程,包括使用哪些信息以及用于什么目的。
- 您至少应该对处理后的值进行哈希处理,因为您不需要实际的电话号码或电子邮件地址来发现联系人,并且哈希处理不需要太多的努力和成本。但是,请注意,个人身份信息的散列不足以“匿名”这些值——这是一个常见的误解。
如需更高级的保护,您可以查看Signal 应用程序作者的博客文章,其中描述了有关如何保护联系人发现过程的技术细节。