最容易被放过的权限，我把“每日大赛官网”的链路追完了：你以为关掉就完事，其实还没结束；我把自救步骤写清楚了
很多人对网站权限的直觉是：弹窗里点“允许”后会被骚扰，点“阻止”就万事大吉。可我把“每日大赛官网”的链路从前端到后台、从浏览器到第三方域名追完后发现：真正能持续影响你的，不是那一条明显的权限弹窗，而是几条经常被忽略的链路——service worker / push 订阅、第三方 OAuth 授权、跨域存储与嵌入脚本、以及浏览器扩展或缓存残留。下面把发现过程和实操自救步骤都摆清楚，按着做一步步清掉痕迹。
一、我看到的链路（通俗版）
- 你在“每日大赛官网”点了允许通知或用社交账号登录；
- 网站注册了一个 service worker，把推送订阅（push subscription）存到第三方推送服务器（可能是一个独立的域名或CDN）；
- 同时，页面里嵌入了第三方脚本（统计/广告/联运），这个脚本也能读取 cookies/localStorage 或向自己的域发请求，把你的标识同步到别的域；
- 即便你后来在页面里关闭了“通知”弹窗，浏览器界面显示已阻止，服务端那边仍然有一份订阅或 token，可以通过别的路径继续触达或再激活；
- 如果你曾用社交账号一键登录（OAuth），授权并不会自动随着前端“关闭通知”而撤销；该第三方仍可访问你同意的范围内的数据或刷新 token；
- 最后，浏览器扩展或移动端应用有时会替第三方做持久化，把信息保留在本地。
二、关键原因（为什么“关掉”不够）
- 前端只是 UI 层：页面取消订阅/撤销权限有可能只是前端行为，真正的订阅信息还存在服务端；
- Service worker 是持久的：即便页面关闭，service worker 仍在控制域名下的事件（推送、后台同步等）；
- 跨域存储和多域名：一个公司可能用多个域名/子域名协同工作，删掉某个域的权限并不会影响其他域；
- OAuth/第三方授权独立于浏览器权限：需要在对应的第三方账号里撤销授权；
- 缓存与 cookie：旧的 cookie、localStorage、IndexedDB 里可能还保存着可以重建会话的标识。
三、发现过程（我如何追踪链路）
- DevTools（Network / Application）：看请求里有没有指向第三方域名的 push/register、identify 或 token 请求；Application 里查看 Service Workers、Push subscriptions、Local Storage 和 Cookies；
- 查看 page 源码与脚本加载链：找出哪些第三方脚本被加载，哪些域名被请求；
- 模拟撤销并观察：在浏览器设置里撤销通知后再刷新页面、重新登录，观察是否仍有推送或请求被恢复；
- 检查 OAuth 授权：登录相应社交账号的“应用与网站”授权页，看“每日大赛官网”或相关第三方是否还在名单里；
- 检查扩展与移动端：排查是否有浏览器扩展或已安装的 App 在代为操作。
四、可操作的自救步骤（按顺序做，建议逐项核验） 1) 取消并彻底删除浏览器里的站点权限与数据
- 打开浏览器设置的站点权限/网站数据管理，找到“dailycontest（或每日大赛官网对应域名）”及其相关子域，删除所有站点数据（Cookies、Local Storage、IndexedDB 等）并撤销通知、地理位置、摄像头/麦克风权限。
- 在 DevTools → Application → Service Workers，找到并 unregister 与该域名相关的 service worker（有时需要在每个子域/第三方域下分别检查）。
- 在 DevTools → Application → Push 订阅（或 Push Messaging）查看是否存在订阅，若存在，先手动删除（unregister/unsubscribe），再刷新确认无恢复。
2) 撤销第三方推送/服务端订阅（如果页面上无法彻底删除）
- 如果可见第三方推送域名（在 Network 请求里能看到），打开该域名对应的站点设置（或直接联系站点客服）请求删除你的推送订阅/退出推送列表。
- 若订阅来自服务端而非你本地，单靠浏览器端撤销有时不足，联系站点运营方或在站点的个人中心查找“消息订阅”“通知设置”，在站点后台取消订阅并要求删除相关标识。
3) 撤销 OAuth 与第三方应用权限
- 如果曾用 Google/Facebook/Apple 等社交账号登录，分别登录这些账号的“应用与网站”或“安全与授权”页，找到并移除“每日大赛官网”或可疑第三方项。具体入口通常在账户安全/隐私设置下（例如 Google：myaccount.google.com → 安全 → 第三方应用访问权限）。
- 移除后回到原站点，尝试用普通注册/密码重新登录或完全退出账户。
4) 清理扩展与移动端权限
- 检查浏览器扩展，停用或卸载不熟悉或不必要的扩展，尤其是能读写页面内容或跨站请求的扩展。
- 在手机上（Android/iOS）检查应用权限：浏览器和已安装的相关 App 是否有通知、存储或后台运行权限，不需要的关闭或卸载。另外，iOS 的 web push 在 iOS16.4+ 支持，要在“设置 → 通知”里管理 Safari 或对应浏览器的权限。
5) 改密码、登出并强制刷新会话
- 在被登录的网站（如果你在网站上有帐号）改密码并选择“退出所有设备”或“强制注销所有会话”。
- 在所有关联社交账号（OAuth 提供方）里也执行一次登出并更换密码，启用两步验证以防被滥用。
6) 再次核验与监控
- 清理后，重新打开 DevTools → Network 与 Application，访问该站点并观察是否还有 push 注册、第三方请求或被动恢复的订阅。
- 关注一段时间：若仍收到异常通知、邮件或短信，收集发送来源与请求头，作为联系站点或平台客服的证据。
五、常见误区（别被表面现象骗了）
- 误区一：只在页面上“取消通知”就够。要同时删除 service worker、push subscription 与服务端订阅。
- 误区二：清 cookie 就能断开一切。Cookies 只是部分痕迹，IndexedDB、localStorage 和 service worker 都可能保存更多。
- 误区三：撤销浏览器权限就自动撤销 OAuth。社交登录授权需要在各自账号里单独撤销。
六、如果你不是技术高手，最稳妥的做法（简化版）
- 浏览器里把该站点的权限全部设为“阻止”，并删除站点数据（通常在设置 → 隐私与安全 → 网站设置 → 目标站点 → 清除数据）。
- 在社交登录的账号安全页面撤销与该站点相关的第三方应用授权。
- 检查并删除可疑浏览器扩展，手机上卸载不常用或来源不明的 App。
- 改网站密码并开启两步验证。
- 有证据时直接联系该站点客服，要求彻底删除你的订阅/账户数据。
七、最后的建议（一句话） 别只信浏览器弹框的表面结果；想断掉“链路”，必须把浏览器、服务端、第三方授权、扩展和移动端都一并检查清楚。
