原来从一开始就错了，我把这种“弹窗更新”的链路追完了：你点一下，它能记住你的设备指纹

原来从一开始就错了，我把这种“弹窗更新”的链路追完了：你点一下，它能记住你的设备指纹

那天我在一个新闻站点上看到一个“立即更新浏览器/应用”的弹窗，感觉像惯用伎俩——点一次就没事儿。但出于好奇，我跟着这条链路把所有请求、权限、存储翻了个遍，结果发现：一次随手的点击，足够让对方把你的设备“刻个号”。

我把发现整理成可复现的几段链路，便于你理解发生了什么，以及如何查清楚和清理。

链路概览（怎么把“点一下”变成可追踪的ID）

• 点击触发了一个重定向或打开了一个隐藏 iframe，使得第三方脚本得以在第一方上下文执行（绕过了很多第三方限制）。
• 页面在用户点击的“用户手势”下调用了若干需要交互或在第一次触发下允许的 API：请求通知权限、注册 Service Worker、触发文件/媒体探测等。许多浏览器会把某些操作与用户手势绑定，点击正好满足条件。
• 脚本开始收集指纹信息：User-Agent、屏幕分辨率、像素比、时区、语言、浏览器插件/扩展探测、系统字体集合、Canvas/WebGL 渲染差异、AudioContext 指纹、MediaDevices 枚举结果、Touch/Pointer 能力、浏览器行为差异（如 CSS 支持）等。
• 收集到的特征通过哈希算法（比如 SHA-256）合成一个“设备指纹”。同时，这个指纹被写入多处持久化位置：first-party cookie、localStorage、IndexedDB、Cache Storage、Service Worker 可控制的缓存、甚至通过设置响应头（ETag）和缓存策略实现跨子域“缓存回写”。
• 服务器端保存这个指纹与推送订阅端点、User-Agent、IP 残余信息关联。以后即便你清理了 cookie，脚本可以通过检查 IndexedDB/Cache 或询问 server 进行“同步重建”（reconstruct），从而再次识别你。

几个关键技术点（可验证的痕迹）

• Service Worker / Push Subscription：在 DevTools 的 Application -> Service Workers 可以看到注册记录。未注册但出现了推送请求或 notification.permission 的页面要格外留心。
• IndexedDB / Cache Storage：这些地方常被用来做更难清理的持久化。DevTools 里也能查看具体键和值。
• ETag / 缓存回写：通过观察 Network 面板的请求和响应头（ETag、If-None-Match）能发现“缓存标记被当作ID”类的技巧。
• Canvas/WebGL 指纹：页面会创建隐藏的 canvas 并读取 toDataURL 或 getImageData；这类请求本地没有网络痕迹，但可通过页面脚本检查点位或在 DevTools 的 Sources 中打断点观察。
• 请求链上的重定向：点击可能带来一个短链（一次或多次重定向）到追踪域名，检查 Network 的重定向历史可以还原链路。

如何快速排查和清理（实操步骤）

• 在遇到可疑弹窗前，先在 DevTools 打开 Network 和 Application，勾选 Preserve log。点下去并观察立刻出现的请求与 storage 写入。
• 检查 Service Workers：Application -> Service Workers，注销不认识的 worker，清空 Cache Storage。
• 清理 IndexedDB、localStorage、cookies，同时也在 Network 中查看是否有持续回写（例如某个请求带上固定 ID）。
• 检查通知权限：浏览器设置里撤销不必要的站点权限。推送订阅端点一旦被服务器记录，撤销并不会总是让服务器忘记历史关联，但能阻断新的订阅。
• 更强力的对策：使用严格的内容屏蔽（uBlock Origin、隐私模式、脚本阻断器），阻止未知脚本执行；对不信任站点不要随意点击要求“更新”或“安装”的弹窗。

结语（不复杂但容易被忽视） 这类“弹窗更新”的危险并不在于一次恶意下载（当然那也有可能），而在于——一次交互，就能给对方建立一个跨清理、跨浏览器会话的识别链。技术上并非天方夜谭，而是多种浏览器特性和持久化手段被组合利用的结果。遇到要求“点一下”的更新提示，可以把好奇心留到沙盒或 DevTools 里试验，现实中多一点怀疑，少一点随手点击，会省不少麻烦。

标签： 原来 开始 错了