H3.14.4PII redaction in error reports设计研究
上报数据涉及用户内容时需要脱敏处理
别名: 脱敏 · PII redaction · 上报隐私
概念解释
错误载荷很容易把字段值、文件名、消息正文、地址一并带走，因为这些往往就在出问题的那一行。涉及用户内容必须脱敏：默认不采集原文，必要的形态用类别或哈希代替，人能复现任务，读不到秘密。没有这一层，自动上报会从恢复工具变成一次静默的内容外泄。这条管载荷里的内容，不管发不发、路径全不全。
机制
异常对象、URL、日志插值和「把当前表单状态打出来」都是原文入口。原文对修复几乎没有额外价值：需要的是「这是邮箱字段、长度超出」，不是那串地址。一旦原文进了日志栈，访问控制、保留期、分包商都会看到一份本不该离开设备的副本。脱敏要在离开设备之前做：类别化（邮箱 / 电话 / 自由文本）、截断、对标识符做不可逆哈希。事后在仓库里删，补不回已经同步到别处的副本。用户若看不到上报里有自己的内容，退出诊断的决定也做不成。
怎么研究
对含有典型字段的失败做一次上报，审查载荷。比较未脱敏、字段级类别化、禁止自由文本。
自变量：是否在客户端剥离原文、URL 查询串是否保留、附件是否上传。 因变量：能复现的比例、载荷中可识别个人数据的条数、审查人员是否能读出内容。
不要在真实用户流量上做「先采再看有没有 PII」的实验。用夹具数据。
边界
用户主动点「附加截图或日志」并看到将发送的内容时，可以发送更富的材料，那是明示同意，不是默认上报。崩溃时内存转储往往含原文，默认关闭或只在选择加入的诊断包里。监管要求更长保留的审计日志与错误上报分开，不要用「审计」当未脱敏上报的借口。内部员工工具仍要脱敏，内部不等于无隐私。
怎么落地
- 默认上报白名单：界面 ID、动作类型、错误码、版本、经过类别化的字段类型；字段值、消息正文、文件内容、精确坐标不在名单上。
- 客户端在发送前扫 URL、异常 message、自定义上下文里的邮箱、电话、证件号模式并剥离。
- 设置里用一句人话说明会上报什么，并给看最近一条已脱敏样本的入口。
- 验证：用含真实格式的假个人数据走失败路径，打开发出的载荷。能读出那串假数据，脱敏就还没发生在离开设备之前。