后 Cookie 时代的设备指纹识别：2026 年的监管与技术全景
第三方 Cookie 已经或正在消失，指纹识别受到前所未有的审视。2026 年全景：技术层面（ITP、Privacy Sandbox）与法律层面（GDPR、ePrivacy）发生了什么变化，以及为何第一方反欺诈指纹识别自成一类。
“后 Cookie 时代”这个说法把两个截然不同的故事压缩成了一个，而这种混为一谈引发了围绕设备指纹识别在 2026 年是否仍然可行的大部分困惑。一个故事是技术层面的：浏览器先是限制、随后移除了第三方 Cookie，并构建了替代机制。另一个故事是法律层面的：监管机构明确指出，指纹识别受与 Cookie 相同的规则约束。两个故事都真实存在，都很重要，也都常被误读为“指纹识别已死”，而它们实际确立的结论要具体得多。
本文对两者都做梳理——浏览器里发生了什么变化、法律怎么说、以及两者如何相互作用——并贯穿一条一致的主线：决定技术可行性与法律地位的，是识别的目的，而非机制。目标读者是那些正在决定是否以及如何部署设备智能的隐私、法务与工程相关方。
“后 Cookie 时代”实际移除了什么
后 Cookie 时代的转变移除的是第三方 Cookie——即跨站追踪机制——同时保留了第一方状态与第一方设备识别。这一区分是评估指纹识别时最重要的一个事实，也是最常被忽略的一个。
第三方 Cookie 由地址栏中域名之外的域设置，它让该第三方能够在其代码运行的所有互不相关的站点上识别同一用户。这是跨站行为广告的引擎，也是浏览器所拆解的对象。第一方 Cookie——由你实际访问的站点设置、仅该站点可读——从来都不是打击目标，并且仍然照常工作。
各家浏览器采用了不同的时间表和不同的机制，但方向是一致的：消灭跨站第三方状态，保留第一方关系。
Safari（智能追踪防护）。 苹果的 ITP 自 2020 年起默认屏蔽第三方 Cookie，并逐步收紧脚本设置状态的第一方存储生命周期，以限制追踪的变通手段。ITP 专门针对跨站追踪这一用例。
Firefox（增强型追踪保护 / 全面 Cookie 保护）。 Firefox 默认屏蔽第三方追踪 Cookie，并按站点对存储进行分区，因此第三方在每个站点上获得的是一个单独的 Cookie 罐，而不是横跨所有站点的一个共享身份。同样——跨站关联才是目标。
Chrome（Privacy Sandbox）。 Chrome 的路径更漫长、也更具争议。谷歌没有简单地屏蔽第三方 Cookie，而是构建了 Privacy Sandbox——一组按目的限定的 API（用于兴趣信号的 Topics、用于再营销的 Protected Audience、用于转化衡量的 Attribution Reporting），旨在不依赖跨站标识符的情况下实现广告效果。其推出节奏、弃用时间表以及面向用户的选择权的确切状态在 2024–2026 年间反复变动，但架构意图始终不变：用聚合的、受隐私限定的机制取代跨站标识符。其对指纹识别的具体影响见 Privacy Sandbox 的影响。
上述每一项针对的都是同一件事：第三方在其并不拥有的站点上识别用户。它们没有一项针对——在不破坏 Web 的前提下也无法针对——某个站点在其自有页面上识别其自有访客。这正是反欺诈指纹识别所处的空间。
第一方反欺诈指纹识别是一种不同的用例
用于反欺诈的指纹识别在本质上是第一方且单站点的：某个平台在其自有页面上识别其自有访客以做出安全决策。这与浏览器所拆解的跨站广告用例有着本质区别，而浏览器机制并不限制它——因为若不破坏每个站点都依赖的核心功能，它们就无法限制。
设想一下浏览器要阻止第一方设备识别必须破坏什么。它必须阻止站点读取正在渲染其自有页面的浏览器的特征——屏幕尺寸、语言、站点运行所需的时序与渲染行为、以及它本就在与之通信的网络栈。这些并非追踪钩子；它们是 Web 应用运行所依赖的基本表面。限制它们会破坏正当功能，因此浏览器限制的是这些信号的跨站组合与滥用，而非其第一方观测。
这正是设备与 Cookie 之别之所以重要的原因。在单一平台上识别一台回访设备的反欺诈系统，并不是在重建第三方 Cookie——它做的是第三方 Cookie 本就从未做好的事情：为站点自身的安全目的，产生一个抗清除的稳定身份。而且是在完全不用 Cookie的情况下做到的，从而绕开了整个 Cookie 弃用的问题。
因此，技术可行性的结论很直接：后 Cookie 时代的浏览器变化削弱了跨站指纹识别（更难、更受限），而基本上原封不动地保留了第一方反欺诈指纹识别。依赖跨站信号共享的反欺诈系统会陷入困境；围绕第一方设备身份构建的系统则不会。
GDPR 与 ePrivacy 对指纹识别究竟怎么说
欧洲法律对待设备指纹识别的方式与对待 Cookie 相同：它按目的、以及按对用户设备的访问来监管，而不按具体技术。指纹识别不会因为不是 Cookie 而逃脱规则，也不会自动落入规则之下——分析取决于你为何这么做。
有两部法规适用，且它们依次运作。
**ePrivacy 指令（第 5(3) 条）**规范在用户终端设备上存储信息、或获取其中已存储信息的行为。这就是所谓的“Cookie 法”，但其文本是技术中立的——它涵盖“信息”与“访问”，而监管机构（以及欧洲数据保护委员会的指引）一贯将其解读为包括访问设备特征的指纹识别技术。因此,无论是否涉及 Cookie，从设备上读取信号都属于 ePrivacy 的适用范围。
关键在于，第 5(3) 条包含豁免。当访问是传输通信、或提供用户明确请求的服务所严格必要时，不需要同意。用户所请求的服务确实依赖的安全与反欺诈，对于严格必要豁免具有真实的基础——这一点下文会再谈。
GDPR 规范由此产生的任何个人数据的处理。能够单独识别出某一个人的设备指纹属于个人数据，因此其处理需要第 6 条下的合法依据。与反欺诈相关的依据是正当利益（第 6(1)(f) 条）——而 GDPR 自身的鉴于条款明确将反欺诈列为一种正当利益——以及在适用情况下的法律义务。详细的合规机制正在于此：目的限制、数据最小化、透明度、留存期限，以及一份有据可查的正当利益评估。合规部署的实际形态在 符合 GDPR 的设备指纹识别 中有阐述。
两部法规叠加：ePrivacy 决定你访问设备是否需要同意，GDPR 决定你处理所获取内容是否有合法依据。对于反欺诈,可行的路径是 ePrivacy 的严格必要豁免加上 GDPR 的正当利益——但这条路径有条件，并非自动成立。
反欺诈指纹识别需要同意吗？
这取决于目的，而这一分野很鲜明：用于广告、分析或跨站追踪的指纹识别需要同意；对用户所请求的反欺诈服务严格必要的指纹识别，则具有在无需同样选择加入的情况下运作的真实基础。两种情况下机制完全相同——法律处理则完全因为何而分道扬镳。
对于广告与分析目的，不存在什么认真的争论：这正是 ePrivacy 同意要求所针对的对象，它对用户所请求的任何服务都不是严格必要的，因此需要像任何追踪 Cookie 一样事先取得知情同意。
对于反欺诈，严格必要豁免的理由真实存在但有条件。在以下情形下它最为成立：
- 指纹识别对交付用户所请求的服务确实必要——保护其登录、保护其支付、防止其账户被接管。当用户使用该服务时，安全就是他们所请求内容的一部分。
- 处理仅限于安全目的，不被再用于营销、画像或用户未曾请求的任何用途。目的限制在这里发挥着实实在在的作用；一旦同一指纹被用于广告，豁免的理由便告崩塌。
- 数据收集被最小化到安全目的所需，留存有界限，且处理有据可查、透明公开（即便同意并非依据，也在隐私声明中予以披露）。
这不是漏洞，也不应被当作漏洞看待。它是一项受目的约束的豁免，仅在目的保持有界的前提下才成立。悄悄把信号共享进广告图谱的反欺诈系统，已不再是在做严格必要的安全处理，因而失去豁免。可持续的立场是这样一种反欺诈部署：它是、并始终是它所声称的样子——第一方、以安全为目的、经过最小化、并与营销相隔离。
以上均非法律意见，具体适用取决于司法辖区、各国 ePrivacy 的实施、行业规则以及你的具体处理——此处的分析是一般性的监管形态，真实的部署需要其自身的正当利益评估与法律顾问审查。
可持续的架构
同时挺过技术转变与法律转变的架构，正是以反欺诈为核心的指纹识别早已趋向的那种：第一方、偏重服务端信号、目的限于安全、并且独立于跨站机制。
从上述全景可得出三项设计承诺。
依托第一方与服务端信号。 浏览器变化对跨站客户端探测的限制最为严厉。服务端信号——网络栈指纹、TLS 特征、连接行为——是在用户连接到你的服务时从你自有的基础设施上观测到的，本质上是第一方的，且不受浏览器正在收紧的客户端限制的约束。偏重这类信号的系统，比建立在可能被削减的客户端探测之上的系统更经得起时间考验。
让目的保持有界且可见。 法律可行性完全取决于是否停留在安全目的之内。这意味着不把反欺诈信号再用于营销、不构建跨站图谱、在隐私声明中披露处理、最小化收集、并对留存设界。这些并非事后加装的合规负担——它们正是整个方法得以合法的前提条件。
核心裁决不要依赖跨站信号共享。 匿名化、聚合的跨客户情报可以增强检测，但主要的设备身份应仅凭第一方信号成立，这样系统就不必仰赖那些既在技术上受限、又在法律上需要同意的跨站机制。
以这种方式构建的反欺诈指纹识别系统是真正意义上的后 Cookie：它不使用 Cookie、不需要 Cookie、不依赖第三方状态，也不会在下一个追踪防护特性上线时土崩瓦解——因为它从一开始就不曾做跨站追踪。
Tracio 正是按这种形态构建的。其身份是第一方且无 Cookie 的，在服务端网络信号与客户端设备信号之间加权，目的限于安全与反欺诈决策，且不喂养广告图谱。它被设计为在浏览器隐私变化中保持稳定，因为它不依赖那些变化所针对的跨站机制。详细的合规机制见 GDPR 部署指南；术语表 涵盖了底层概念。
想看看第一方、以安全为目的的设备身份如何契合你的隐私与合规态势？