H4.09.3contact-upload retention disclosure设计研究
上传通讯录用于匹配好友需明确告知服务器留存方式
别名: 通讯录匹配 · 好友匹配上传 · hash matching · address book upload
概念解释
「看看谁在用」若要把通讯录送到服务器做匹配，授权瞬间必须说清：哪些字段离开设备、以明文还是摘要形式、在服务器留多久、匹配失败的号码会不会仍被保存、能不能删。只说「用于查找好友」等于没说留存。这条谈上传与留存的告知，不是设备上选一个联系人就够不够，也不是相册粒度。
机制
本地选人只把一条记录交给应用；匹配好友却把一张社会图交给服务端，用于交叉用户、补全未注册者、有时还用于推荐与广告。人的默认模型是「对一下就扔」，实际常见的是哈希表长期存放、未注册号码反复尝试邀请。不披露留存，人无法对「这一次查找」和「把我的通讯录变成你们的增长资产」做区分。告知失败后，即使匹配功能有用，被发现留存时仍会按欺骗来算，因为当初同意的对象不是这张表。
怎么研究
给同一匹配功能写「对完即删」与「摘要将保留以再次匹配」两种说明，在选择前测预测。
自变量：是否写明离开设备、是否写明保留期限、是否写明未注册号码的命运。 因变量：对「服务器还有没有我朋友的号码」的判断、允许率、发现真实留存后的愤怒与撤权。
允许率升高若来自隐瞒留存，测到的是欺骗有效。审计必须对照实际上传与删除日志，不能只看文案。实验室里的「匹配」没有真实社交后果，生态效度有限，应用日志与监管抽查更关键。
边界
完全在设备上完成的交叉（两边都只上传自己的号码做交集、立刻丢弃）仍要说明「摘要会离开设备」，哪怕不建档案。法律强制的留存应写期限与用途，不能藏在隐私政策第十七页。用户本人主动导出通讯录备份，是另一份同意，不能拿来覆盖好友匹配这条数据流。
怎么落地
- 在匹配功能的前置说明里用短句列出：上传字段、是否哈希、保留期限、未注册联系人是否保存、撤回后多久删除。
- 提供不上传的替代：分享链接、手动输入对方账号；匹配失败不得为此再要一次全量通讯录。
- 撤回匹配或关掉通讯录权限时，按说明发起服务端删除，并在完成态回报。
- 验证：让未参与设计的人看完说明后画出数据流向。说不出「号码会不会留在服务器」，告知失败。再用测试号码走匹配，查服务端在声称的期限后是否仍能命中该号码。