G3.11.2search history privacy设计研究
历史是隐私敏感数据，需可删除
别名: 查询日志隐私 · deletable history · 搜索痕迹
概念解释
查询字符串会暴露意图、健康、财务、关系和未公开的工作。搜索历史作为隐私数据，不只是「最近搜过什么」的便利缓存，而是一份可被他人、雇主、执法和后续算法读取的痕迹。AOL 在 2006 年发布「已脱敏」查询日志后，仍能把匿名 ID 还原成具体个人，说明查询本身往往就是准标识符。因此历史必须可被用户删除——单条、按时间、以及全部——删除还要覆盖本地缓存和账号侧日志，不能只清掉下拉框里的几行字。
可删除不是反对保留历史。复用需要保留；隐私要求保留可逆。不可删的历史把查找通道变成了永久档案。
机制
查询在键入的那一刻通常没有被当作「我在留档」。工作记忆里它是当前任务的临时描述，提交之后注意力已经转到结果。留存发生在视线之外：浏览器的输入自动完成、站点的账号日志、用于个性化的长期画像。人无法用「当时没觉得敏感」来预测三个月后这条记录出现在共享屏幕上的代价。
删除若只作用于界面列表，底层日志仍在，用户会形成错误的安全模型：以为擦掉了，其实还能被推荐、客服和泄露事件用上。有效删除必须沿数据流走完：设备上的建议索引、服务器上的查询日志、从查询派生的兴趣标签。任何一环留下，痕迹就还在。
怎么研究
把历史当作敏感数据来测心理模型和控制感，而不是只测复用效率。
- 范式：情景剧或日记，让人在共享设备、被旁观、账号被他人登录等条件下使用带历史的搜索；再给删除控件，看人以为删了什么、实际还剩什么。查询日志泄露事件的事后分析（AOL 日志再识别）提供存在性证据。
- 自变量：删除粒度（单条 / 时间范围 / 全部）、删除是否同步到服务端、删除后建议是否仍能「猜」出刚删的串。
- 因变量：愿意在该设备上键入敏感查询的比例、删除后对「还在不在」的判断准确率、发现残留所需的步骤。
- 方法论注意点：实验室里用无害查询会低估敏感性。要用参与者自己不愿在旁人面前读出的任务，或至少用他们指定的敏感类目。自陈「我在意隐私」与是否真的去找删除入口不是一回事，两份数据都要记。
边界
监管留存、企业合规审计、反欺诈日志可能在法律上不能按用户请求立刻擦掉；这时界面不能假装已经全部删除，必须写明哪一层还在、还要留多久。本地无账号的浏览器历史与云端账号历史是两份控制面，清一个不等于清另一个。儿童或被监护账号的删除权可能属于监护人，产品不能只按终端操作者提供擦除。
怎么落地
- 提供单条删除、按日期删除和全部清空，入口放在历史列表里，不要只藏在总设置。
- 删除动作写清范围：这台设备、这个账号、是否包含已用于个性化的派生数据。
- 删掉的字符串不得立刻从「猜你想搜」里回声出现，否则删除是假的。
- 验证：删一条敏感查询后，在下拉历史、跨设备同步、个性化建议三处各搜一次同一意图。任何一处仍能复原原串，删除就不完整。