〇、前言

前文已经介绍了，单击查看全部系列文章：缓存Storage，那么本文再介绍另一新的类别：身份与会话管理。

身份与会话管理，涵盖 Cookies 和 Private state tokens。

• Cookies 是最早的客户端存储机制，每次请求都会自动携带，适合服务器端识别用户身份或维持会话；
• Private state tokens 是为替代第三方 Cookie 而设计的隐私保护方案，用于在不追踪用户的前提下验证用户行为（如：防欺诈），属于现代隐私沙盒的一部分。

下面来详细介绍下。

一、什么是 Cookies？

1.1 简介

Cookie 是服务器通过 HTTP 响应头发送至浏览器、存储在用户本地设备上的小型文本数据文件，主要用于识别用户身份、维持会话状态及记录用户偏好。其核心作用是解决 HTTP 协议的无状态特性，使网站能够“记住”用户行为。

三个特点：

• 数据形式：以键值对（如：username=John）存储的纯文本文件，仅能被创建它的服务器读取。
• 存储位置：由浏览器管理，不同浏览器路径不同（如：Chrome 存储在 Cookies 文件中），用户无法直接通过 JavaScript 修改非 HttpOnly 属性外的 Cookie 内容。
• 自动传输：浏览器在后续同域请求中自动将 Cookie 附加到 HTTP 请求头，服务器通过解析识别用户身份。

两种生命周期类型：

• 会话 Cookie：无明确过期时间，仅在浏览器会话期间有效（关闭浏览器后自动删除），常用于临时状态管理（如：购物车）。
• 持久 Cookie：通过 Max-Age 或 Expires 属性设置过期时间（如：7 天），关闭浏览器后仍长期有效，用于“记住登录”等场景。

实际上，Cookie 并非传统意义上的“缓存”（如：资源复用），而是会话状态管理工具，需谨慎处理敏感信息。用户可通过浏览器设置管理或删除 Cookie，但禁用必要 Cookie 可能导致部分功能失效。开发者应优先使用 HttpOnly + Secure + SameSite=Strict 组合，最大限度保障安全性。

1.2 按照功能可以分为三类：必要、功能、追踪

1）必要 Cookie（Essential / Strictly Necessary Cookies）

这个类别是网站正常运行的“基础设施”，也是网站提供用户明确要求的服务所绝对不可或缺的。

三个主要作用：

    会话管理：维持用户的登录状态，防止用户在浏览不同页面时被反复要求重新登录。
    安全与验证：防范跨站请求伪造（CSRF）攻击，验证用户身份，保障支付和表单提交的安全性。
    负载均衡：将用户的请求分配到不同的服务器，确保网站在高并发下的稳定性。

根据 GDPR（通用数据保护条例）等隐私法规，必要 Cookie 通常不需要获取用户的明确同意即可部署，但必须在隐私政策中向用户声明。

生命周期特点：绝大多数是会话级 Cookie（Session Cookie），在用户关闭浏览器后会自动删除，不会长期驻留。

2）功能 Cookie（Functional / Preference Cookies）

此类别旨在提升用户体验的“个性化记忆”，它们允许网站记住用户的选择和自定义设置。例如：

    界面偏好：记住用户选择的深色/浅色模式、字体大小、页面布局等。
    本地化设置：保存用户选择的语言、国家/地区、货币单位等，避免每次访问都要重新设置。
    多媒体与交互：例如记住视频播放器上次播放的进度，或保存用户在评论区输入的昵称。

由于涉及收集用户的个人偏好数据，通常需要事先获得用户的明确同意（Opt-in）。如果用户拒绝，网站仍应可用，但可能无法提供这些个性化便利。

生命周期特点：通常为持久性 Cookie（Persistent Cookie），会设定一个较长的过期时间（如：几个月或一年），以便用户下次访问时依然生效。

3）追踪 Cookie（Tracking / Marketing / Analytics Cookies）

此类别是商业变现与数据洞察的“探针”，主要用于分析用户行为、衡量广告效果或进行精准营销。

常见的分析方法有三种：

    数据分析（Analytics）：收集匿名或半匿名的统计数据，如页面访问量、停留时间、跳出率、用户点击热力图等，帮助网站优化内容和结构（如：Google Analytics）。
    广告定向（Targeting/Advertising）：记录用户的浏览历史和兴趣标签，构建用户画像，从而在用户访问其他网站时推送高度相关的个性化广告。
    归因分析（Attribution）：追踪用户是从哪个广告链接点击进入的，帮助广告主评估营销活动的投资回报率（ROI）。

传统的追踪 Cookie 多为第三方 Cookie（由广告网络或分析平台而非当前访问的网站设置）。随着隐私意识的觉醒和浏览器政策的变化（如：Safari 和 Firefox 已默认拦截，Chrome 正在逐步淘汰第三方 Cookie），这类 Cookie 的生存空间正在被大幅压缩，行业正逐渐转向隐私沙盒（Privacy Sandbox）等新技术。

追踪 Cookie 是隐私监管最严格的领域。包括浏览器在内的工具，必须通过醒目的 Cookie 弹窗获取用户的明确同意，且必须提供与“同意”同等便捷的“拒绝”选项。用户有权随时撤回同意并清除相关数据。

在实际的网站开发或隐私合规审查中，建议对这三类 Cookie 实行严格的分级管理：非必要不收集，收集必告知，追踪必授权。这不仅是法律合规的要求，也是建立用户信任、提升品牌声誉的关键。

1.3 按来源可以分两类：第一方、第三方

第一方 Cookie 就像是“店铺的私人助理”，只在本店为您服务，提升您的购物体验；而第三方 Cookie 则像是“尾随的陌生人”，跟着您穿梭于各个店铺，记录您的喜好并试图向您推销商品。

1）第一方 Cookie（First-Party Cookies）

此类 Cookie 指的是由用户当前正在访问的网站（即浏览器地址栏中显示的域名）直接创建和读取的数据文件。

主要用途是服务于网站的核心功能与用户体验。例如：保持用户的登录状态，无需在每次跳转页面时重新验证；保存电商购物车中的商品；记住用户的语言、主题偏好或界面设置。

第一方 Cookie 的数据仅在用户与当前网站之间传输，不会与其他网站共享，因此通常不被视为侵入式跟踪。

所有主流浏览器均默认允许第一方 Cookie 的运行，它们是维持现代互联网基础体验的必要技术。

2）第三方 Cookie（Third-Party Cookies）

由当前访问的网站域名之外的第三方（如：广告商、社交媒体插件、数据分析平台）设置的 Cookie。它们通常通过网页中嵌入的外部资源（如：<iframe>、广告横幅、追踪脚本）植入用户的设备。

主要用途：跨站追踪与商业变现。

    构建用户画像：当用户访问多个嵌有同一第三方广告代码的网站时，该第三方可以读取并合并这些 Cookie，从而拼凑出用户的完整浏览历史、兴趣偏好和个人档案。
    精准定向广告：基于收集到的跨站行为数据，广告商可以在不同的网站上向用户推送高度个性化的广告（例如：在 A 网站搜索了手机，在 B 网站的社交媒体上就会看到手机广告）。

第三方 Cookie 往往在用户不知情或未明确同意的情况下，持续追踪用户的网络行为，这引发了极大的隐私担忧，甚至被用于实施身份盗窃或欺诈。

GDPR（通用数据保护条例）和 CCPA（加州消费者隐私法案）等法规要求，使用此类 Cookie 必须获得用户的明确同意，并允许用户查看或删除相关数据。

3）行业趋势：第三方 Cookie 的终结与替代

由于严重的隐私问题，整个互联网行业正在经历一场“去第三方 Cookie”的变革：

    浏览器拦截：苹果的 Safari 和 Mozilla 的 Firefox 浏览器早已默认阻止或严格限制第三方 Cookie 的跨站追踪行为。
    Chrome 的政策转向：谷歌曾计划在 Chrome 浏览器中逐步淘汰第三方 Cookie，并推出了“隐私沙盒（Privacy Sandbox）”计划作为替代方案（旨在通过聚合用户兴趣群组而非追踪个体来实现广告投放）。但受限于反垄断调查及行业阻力，谷歌在 2025 年宣布终止该淘汰计划，维持现状。

尽管第三方 Cookie 的消亡进程有所波折，但行业向“隐私优先”转型的趋势不可逆转。企业正越来越多地转向依赖第一方数据、情境智能广告（Contextual Advertising）以及统一身份识别方案（如：UID2.0）来替代传统的第三方追踪。

1.4 典型应用场景

1）会话管理

用户登录状态维持：服务器生成唯一 SessionID 存入 Cookie，后续请求通过该 ID 识别用户，避免重复登录。
购物车数据保存：电商网站利用 Cookie 临时存储未结算商品，即使关闭页面后重新打开仍可恢复。

2）个性化服务

偏好设置记忆：自动应用用户选择的语言、字体大小等，减少重复配置。
内容定制：根据历史行为推送相关内容（如：新闻推荐），提升用户体验。

3）行为分析与广告

流量统计：匿名记录访问路径、停留时长等，优化网站设计（如 Google Analytics）。
精准营销：基于浏览记录投放相关广告，实现跨站追踪（需用户同意）。

1.5 与其他缓存的区别

特性	Cookie	LocalStorage/SessionStorage
存储容量	≤4KB	≥5MB
自动随请求发送	是（同域请求自动附加）	否
生命周期控制	由服务器设置过期时间	需手动清除或依赖会话
主要用途	会话管理、身份识别	大容量数据缓存

二、什么是 Private state tokens？

2.1 简介

Private State Tokens（私有状态令牌，简称 PST）并非传统意义上的浏览器缓存类型，而是一种隐私保护技术，用于在不泄露用户身份的前提下验证用户行为真实性（如：区分真人与机器人）。它不用于存储网页资源或会话数据，而是通过加密令牌机制解决跨站跟踪与隐私泄露问题。

  隐私优先的身份验证：PST 允许网站向用户发放匿名化验证令牌，证明用户是“合法访问者”，但不暴露具体身份信息，避免传统 Cookie 跨站追踪问题。
  非缓存机制：与 Cookie、LocalStorage 等存储技术不同，PST 不用于缓存网页资源或用户数据，而是专注于安全验证流程，属于浏览器隐私沙箱的一部分。

PST 不是浏览器缓存技术，而是一种隐私优先的匿名验证协议，核心价值在于平衡安全验证与用户隐私。开发者无法将其用作数据存储方案，其适用场景严格限定于反欺诈、广告验证等特定领域，且目前处于早期实验阶段。若需实现常规缓存功能，仍应优先使用 Cache-Control、Service Worker 等标准机制。

与传统缓存的关键区别：

特性	Private State Tokens	传统浏览器缓存（如 Cookie）
主要用途	匿名验证用户真实性	存储会话状态、资源副本或用户偏好
数据可见性	完全加密，开发者无法直接读取内容	可被服务器或 JavaScript 读取
存储目的	防机器人/反欺诈，非资源复用	加速页面加载或维持会话状态

2.2 令牌生成与验证流程

1）发行方（Issuer）签发：受信任的第三方（如广告平台、安全服务）通过浏览器隐私沙箱生成加密令牌，仅包含“用户已通过验证”的证明，无具体身份信息。

2）用户端存储与使用：浏览器将令牌安全存储在隔离的隐私沙箱中，当用户访问合作网站时，自动提供验证证明，无需跨站传递用户标识。

3）匿名化验证：网站通过浏览器 API 验证令牌有效性，但无法获知用户身份或行为轨迹，实现“证明合法性而不泄露隐私”。

2.3 关键技术依赖

浏览器隐私沙箱：令牌生成、存储和验证均在浏览器受控环境中完成，开发者无法直接访问原始数据。

JavaScript API 交互：通过 navigator.privateStateToken.exchange() 触发验证流程，但返回的 token 是不透明的加密 Blob，无法被解析或篡改。

2.4 典型应用场景

1）反机器人与广告验证

广告欺诈防护：广告平台通过 PST 证明用户是真人，避免机器人刷量，同时不收集跨站浏览历史。
无验证码验证：替代传统 CAPTCHA，用户无需手动验证即可通过 PST 证明“非自动化流量”。

2）隐私合规的跨站交互

替代第三方 Cookie：在 Safari、Firefox 逐步禁用第三方 Cookie 的背景下，PST 提供符合 GDPR/CCPA 的跨服务验证方案，仅传递“验证通过”信号，不共享用户标识。
安全登录辅助：与 OAuth 等协议结合，在敏感操作（如：支付）中追加匿名化真人验证，降低欺诈风险。

2.5 现状

浏览器支持有限，仅 Chrome 125+ 原生支持，且需手动启用实验性 Flag（--enable-features=PrivateStateTokens）。

严格环境要求：必须运行在 HTTPS 或 localhost 环境。发行方域名需预注册至浏览器白名单（由 Chrome 团队管理，不可自定义）。

开发者控制权弱：令牌内容由浏览器生成，开发者无法自定义数据结构，仅能触发验证流程。

当前还处于早期标准化阶段，因为由 Cloudflare 联合 Chrome、Firefox、Edge 推动成为行业标准，尚未广泛落地。

PST 还是非通用存储方案，不可用于常规数据缓存（如：页面资源、用户偏好），仅适用于特定验证场景。

• 为何常被误认为“缓存类型”？

首先是术语混淆。“Tokens”一词易被误解为可存储数据的载体，但 PST 不提供开发者可读写的存储空间。

另外，部分浏览器开发者工具将 PST 归入“存储”标签页（如：Chrome 的 Application > Storage），但其本质是验证协议而非存储机制。

实际上，PST 属于隐私保护层，而非缓存层。PST 是浏览器隐私计算架构的一部分，目标是消除跨站追踪，而非优化资源加载速度。

仅在极少数情况下，PST 验证结果可能间接影响缓存策略（如：真人用户优先使用 CDN 缓存），但二者无直接技术关联。

三、两者的区别和联系

3.1 区别

Cookies 是开发者可控的传统会话标识工具，而 Private State Tokens 是浏览器自动管理的隐私保护协议。

二者均用于身份验证，但 PST 通过加密匿名化设计替代第三方 Cookie 的跨站追踪能力，不存储用户数据，开发者无法直接操作，仅用于防欺诈验证。

特性	Cookies	Private State Tokens
存储内容	明文键值对（如 user_id=123）	加密令牌，无用户标识信息
隐私风险	高（易被跨站追踪，需 SameSite 防护）	极低（设计即防追踪）
开发者访问	可读写（document.cookie）	完全不可见，仅浏览器内部使用

技术控制权方面：

Cookies：由服务器通过 Set-Cookie 头下发，开发者可自定义生命周期（Expires/Max-Age），需手动集成到业务逻辑（如：登录后写入 sessionID）。
Private State Tokens：浏览器自动管理，开发者无法直接操作。仅通过 API 触发验证流程（如：调用 navigator.privateAggregation.reportEvent），令牌生成与验证完全由浏览器控制。

核心用途方面也不同：

Cookies：维持用户级会话状态（如：登录态、购物车）。依赖服务器存储 Session 数据完成身份验证。
Private State Tokens：解决跨站欺诈问题（如：反机器人验证），不用于用户身份识别。在用户访问广告或登录页面时，匿名证明“该用户是真人”，避免暴露身份信息。

3.2 相同点

1）共同目标：验证用户真实性

二者均服务于身份验证场景，但解决的问题层次不同：

    Cookies 验证“这是哪个用户”（需关联服务器 Session）。
    PST 验证“该用户行为是否可信”（如：是否为真人操作），不涉及具体身份。

2）PST 是 Cookie 在隐私时代的演进

替代第三方 Cookie 的追踪功能：PST 通过加密协议实现跨站反欺诈验证（如：广告点击验证），无需共享用户标识，直接规避 GDPR/CCPA 合规风险。

互补而非取代：一方 Cookie 仍用于常规会话管理（如：登录态）。

PST 仅用于特定隐私敏感场景（如：广告验证），二者可共存。

3）技术协同场景

广告反欺诈验证流程：

    用户点击广告后，发布商通过 PST 向广告平台发送匿名验证请求。
    浏览器自动用 PST 生成加密令牌，证明用户行为可信（而非暴露身份）。
    广告平台验证令牌后计费，无需依赖第三方 Cookie 追踪用户。

四、小小的总结

Cookies 是“身份标识载体”，PST 是“匿名验证协议”——二者同属身份管理范畴，但 PST 通过隐私优先设计规避了 Cookie 的追踪缺陷。

PST 不存储数据、不可被开发者操控，仅用于特定反欺诈场景，无法替代 Cookies 的常规会话管理功能。

实际开发中：

    用 Cookies + Token 机制处理用户登录。
    用 PST 解决跨站隐私合规问题（如：广告验证），避免混淆二者定位。

何时使用 Cookies？

需要维持用户登录状态或存储少量会话数据时。

必须配置安全属性：HttpOnly（防 XSS 窃取）、Secure（仅 HTTPS 传输）、SameSite=Strict（防 CSRF）。

何时使用 Private State Tokens？

仅限特定场景：广告平台反欺诈验证，需符合 Privacy Sandbox 标准的跨站行为验证（如：Google Ads）。

无需主动集成：依赖浏览器自动触发，开发者仅需调用标准 API（如：privateAggregation）。