H4.04.2data cleanup after permission revocation设计研究
撤回后需清理已获取数据
别名: 撤回清理 · 权限撤销删数据 · revocation erasure · post-revoke cleanup
概念解释
关掉权限只停止以后的访问。通讯录副本、已上传的照片、缓存的精确坐标若还留在服务器或本地数据库里，撤回在效果上不完整。撤回之后需要按该权限曾打开的数据范围做清理或隔离，并让人能看见清理是否完成。这条谈的是已取数据的命运，不是应用里有没有跳转设置的入口。
机制
授权被实现成「读一次，写进自己的存储」。系统开关管的是 API 调用，不管应用已经复制走的那份。人的心智模型却是「关上水龙头，水应该不在了」；若好友列表、人脸相册、行踪轨迹还在，撤回被体验成开关失灵。清理要把派生数据算进去：从通讯录算出的「可能认识的人」、从照片抽出的位置标签。只删界面上的入口、不删后端对象，是另一种「界面消失不等于删除」。
怎么研究
在授权期间制造可识别的数据痕迹（一条带标记的联系人、一张带唯一文件名的照片），撤回后检查客户端存储、备份和应用服务器。
自变量：撤回后是否触发删除请求、删除是否包含派生画像、是否等待用户确认不可逆。 因变量：痕迹是否仍能被 API 读出、界面是否仍展示、用户对「已经删了吗」的判断是否符合实际。
不要只查本地缓存。同步队列、分析管道和推荐模型里的副本才是常见残留。实验室若只看撤回后的下一屏，会把「列表空了」误读成「数据没了」。
边界
法律或安全留存（账单一侧的地址、反欺诈所需的设备指纹）可以拒绝立刻删净，但必须在撤回流程里说明留什么、留多久、为什么。共同所有的内容（别人仍在用的共享相册）不能因一人撤回权限而被单方面销毁。一次性授权若从未把数据送出设备，清理范围是本地缓存，不是服务器。
怎么落地
- 为每条权限列「授权期间可能写出的数据对象」，撤回时按清单删除或切断标识符，含派生表。
- 在撤回完成态告诉人：哪些已经从本应用去掉、哪些因账单或法律还要留、预计何时删完。
- 撤回后的界面不得继续展示已无权刷新的通讯录或图库内容，即使本地还暂时有一份待删缓存。
- 验证：授权后写入一条可检索的标记数据，撤回，等同步完成，用同一账号在新设备登录并查服务端。标记仍在，清理失败。再问用户「这些数据还在吗」——答案与实际不一致，告知也失败。