跳转到主要内容

标签(标签)

资源精选(342) Go开发(108) Go语言(103) Go(99) angular(82) LLM(78) 大语言模型(63) 人工智能(53) 前端开发(50) LangChain(43) golang(43) 机器学习(39) Go工程师(38) Go程序员(38) Go开发者(36) React(33) Go基础(29) Python(24) Vue(22) Web开发(20) Web技术(19) 精选资源(19) 深度学习(19) Java(18) ChatGTP(17) Cookie(16) android(16) 前端框架(13) JavaScript(13) Next.js(12) 安卓(11) 聊天机器人(10) typescript(10) 资料精选(10) NLP(10) 第三方Cookie(9) Redwoodjs(9) ChatGPT(9) LLMOps(9) Go语言中级开发(9) 自然语言处理(9) PostgreSQL(9) 区块链(9) mlops(9) 安全(9) 全栈开发(8) OpenAI(8) Linux(8) AI(8) GraphQL(8) iOS(8) 软件架构(7) RAG(7) Go语言高级开发(7) AWS(7) C++(7) 数据科学(7) whisper(6) Prisma(6) 隐私保护(6) JSON(6) DevOps(6) 数据可视化(6) wasm(6) 计算机视觉(6) 算法(6) Rust(6) 微服务(6) 隐私沙盒(5) FedCM(5) 智能体(5) 语音识别(5) Angular开发(5) 快速应用开发(5) 提示工程(5) Agent(5) LLaMA(5) 低代码开发(5) Go测试(5) gorm(5) REST API(5) kafka(5) 推荐系统(5) WebAssembly(5) GameDev(5) CMS(5) CSS(5) machine-learning(5) 机器人(5) 游戏开发(5) Blockchain(5) Web安全(5) Kotlin(5) 低代码平台(5) 机器学习资源(5) Go资源(5) Nodejs(5) PHP(5) Swift(5) devin(4) Blitz(4) javascript框架(4) Redwood(4) GDPR(4) 生成式人工智能(4) Angular16(4) Alpaca(4) 编程语言(4) SAML(4) JWT(4) JSON处理(4) Go并发(4) 移动开发(4) 移动应用(4) security(4) 隐私(4) spring-boot(4) 物联网(4) nextjs(4) 网络安全(4) API(4) Ruby(4) 信息安全(4) flutter(4) RAG架构(3) 专家智能体(3) Chrome(3) CHIPS(3) 3PC(3) SSE(3) 人工智能软件工程师(3) LLM Agent(3) Remix(3) Ubuntu(3) GPT4All(3) 软件开发(3) 问答系统(3) 开发工具(3) 最佳实践(3) RxJS(3) SSR(3) Node.js(3) Dolly(3) 移动应用开发(3) 低代码(3) IAM(3) Web框架(3) CORS(3) 基准测试(3) Go语言数据库开发(3) Oauth2(3) 并发(3) 主题(3) Theme(3) earth(3) nginx(3) 软件工程(3) azure(3) keycloak(3) 生产力工具(3) gpt3(3) 工作流(3) C(3) jupyter(3) 认证(3) prometheus(3) GAN(3) Spring(3) 逆向工程(3) 应用安全(3) Docker(3) Django(3) R(3) .NET(3) 大数据(3) Hacking(3) 渗透测试(3) C++资源(3) Mac(3) 微信小程序(3) Python资源(3) JHipster(3) 语言模型(2) 可穿戴设备(2) JDK(2) SQL(2) Apache(2) Hashicorp Vault(2) Spring Cloud Vault(2) Go语言Web开发(2) Go测试工程师(2) WebSocket(2) 容器化(2) AES(2) 加密(2) 输入验证(2) ORM(2) Fiber(2) Postgres(2) Gorilla Mux(2) Go数据库开发(2) 模块(2) 泛型(2) 指针(2) HTTP(2) PostgreSQL开发(2) Vault(2) K8s(2) Spring boot(2) R语言(2) 深度学习资源(2) 半监督学习(2) semi-supervised-learning(2) architecture(2) 普罗米修斯(2) 嵌入模型(2) productivity(2) 编码(2) Qt(2) 前端(2) Rust语言(2) NeRF(2) 神经辐射场(2) 元宇宙(2) CPP(2) 数据分析(2) spark(2) 流处理(2) Ionic(2) 人体姿势估计(2) human-pose-estimation(2) 视频处理(2) deep-learning(2) kotlin语言(2) kotlin开发(2) burp(2) Chatbot(2) npm(2) quantum(2) OCR(2) 游戏(2) game(2) 内容管理系统(2) MySQL(2) python-books(2) pentest(2) opengl(2) IDE(2) 漏洞赏金(2) Web(2) 知识图谱(2) PyTorch(2) 数据库(2) reverse-engineering(2) 数据工程(2) swift开发(2) rest(2) robotics(2) ios-animation(2) 知识蒸馏(2) 安卓开发(2) nestjs(2) solidity(2) 爬虫(2) 面试(2) 容器(2) C++精选(2) 人工智能资源(2) Machine Learning(2) 备忘单(2) 编程书籍(2) angular资源(2) 速查表(2) cheatsheets(2) SecOps(2) mlops资源(2) R资源(2) DDD(2) 架构设计模式(2) 量化(2) Hacking资源(2) 强化学习(2) flask(2) 设计(2) 性能(2) Sysadmin(2) 系统管理员(2) Java资源(2) 机器学习精选(2) android资源(2) android-UI(2) Mac资源(2) iOS资源(2) Vue资源(2) flutter资源(2) JavaScript精选(2) JavaScript资源(2) Rust开发(2) deeplearning(2) RAD(2)

category

第三方 Cookie 有多种用途,但它们也是跨网站跟踪的重要驱动因素。为方便测试,Chrome 已限制 1% 的用户从 2024 年第 1 季度起使用第三方 Cookie,并计划从 2025 年初开始逐步弃用所有用户的第三方 Cookie,但要解决英国竞争和市场管理局 (CMA) 可能尚未解决的竞争问题。

在此页面上,您将了解到适用于传统上依赖第三方 Cookie 的嵌入式场景的隐私保护解决方案,以及有助于您选择最符合您需求的解决方案的策略。

嵌入式服务或嵌入服务包括第三方内容(例如视频、地图)、互动组件(例如聊天、评论系统或付款服务)、登录服务等。

从第三方 Cookie 过渡的大部分工作需要由嵌入式开发者完成,而不是由托管嵌入式内容的网站来完成。本指南将主要讨论适用于创建嵌入式服务的开发者的解决方案。

如果您的网站依赖于使用第三方 Cookie 的嵌入,请务必审核和测试与嵌入相关的历程。如果您发现任何中断,请与嵌入提供商联系。

要确定您的嵌入是否受到第三方 Cookie 逐步淘汰的影响,最好的方法是在启用第三方 Cookie 逐步淘汰测试标记的情况下测试您的第三方嵌入用户流。

限制第三方 Cookie 后,请测试以下常见的嵌入场景:

  • 聊天微件:您可以发起聊天会话吗?您是否能在不丢失会话的情况下刷新页面?您是否可以导航到其他网页并维护您的会话?
  • 内容嵌入:您是否可以看到视频内容或其他嵌入内容?系统是否能保留用户偏好设置(例如语言或字幕)?您是否在符合预期时看到了广告(例如,未看到他们订阅的付费内容)?
  • 登录:登录(包括任何单点登录 (SSO) 登录)在支持它们的嵌入中是否有效?它们在页面重新加载和导航到使用相同嵌入的页面时是否仍然存在?
  • 评论微件:您能对评论进行评论、顶和顶吗?
  • 嵌入式付款解决方案:您能成功完成付款吗?

在接下来的部分中,您将更具体地说明这些流程可能会受到怎样的影响。

有许多 API 可用于传统上依赖第三方 Cookie 的嵌入。下表列出了一些常见工作流以及建议用作概要摘要的 API。以下部分将说明给出这些建议的原因。

用例 适用于第三方 Cookie 的推荐 API
聊天微件 条状标签
地图嵌入 条状标签
不受信任的用户内容(例如 googleusercontent.com 和 githubusercontent.com)需要按发布商限定状态的沙盒网域 条状标签
需要按发布商限定状态范围的嵌入式广告 条状标签
通过身份提供方登录 FedCM
托管在不同但相关的来源上的嵌入内容。 Storage Access API 与 Related Website Set
嵌入的内容采用基于登录的偏好设置
(例如没有广告的视频内容,或者语言/字幕偏好设置)
Storage Access API
需要登录的社交媒体评论微件 Storage Access API
针对常见用例推荐的替代 API

本部分详细介绍了如何选择合适的替代 API 并介绍了推荐的 API。

以下流程图可帮助您从可用选项中进行选择:

基于三个问题决定第三方 Cookie 替代方案的选项流程图。
决定使用哪个 API 嵌入第三方 Cookie

该流程图提出三个主要问题,我们将进一步探讨这些问题,以及在各种情况下推荐特定 API 的原因。

许多第三方嵌入代码会独立地用于完全不相关的网站。例如,用于客户服务的聊天微件通常需要 Cookie 才能正常工作,但无需在两个恰好使用相同的聊天微件解决方案的两个完全不同组织之间共享这些 Cookie。事实上,在很多情况下,人们甚至都不希望共享 Cookie。

如果您向其他网站提供第三方嵌入服务且该服务依赖于 Cookie,请考虑这些 Cookie 是否专用于相应网站上所嵌入的服务。它们是否曾被您嵌入其他网站的实例共享?

如果不需要共享 Cookie,则最简单的方法就是使用 CHIPS 对 Cookie 进行分区。该 API 会将第三方 Cookie 与顶级网站绑定,而不是允许所有使用相同的第三方嵌入代码的网站共享这些 Cookie。CHIPS 易于实现,因为它只需要向现有 Cookie 添加一个额外的 Partitioned 属性。这样一来,嵌入式服务仍然可以保存状态,但会移除允许跨网站跟踪的共享跨网站存储空间。

网站还应检查使用 Cookie 的原因是否恰当。只有在已设置 Cookie 或需要通过 HTTP 请求发送 Cookie 时,才应使用 Cookie。如果情况并非如此,且 Cookie 仅用作一种方便的存储方案,则应考虑改用各种存储 API。这样,当不需要发送数据时,数据就会保留在本地。存储 API 已在所有主流浏览器中进行分区,方式与 CHIPS 对 Cookie 进行分区的方式类似。

第三方 Cookie 的一种常见用途是提供由第三方登录服务提供方管理的登录功能,例如使用 Google 账号登录。在这种情况下,我们不能选择分区 Cookie。

联合凭据管理 (FedCM) 是专为此用例打造的专用 API,无需第三方 Cookie 即可运行。如果身份提供方支持 FedCM,则可能无需使用第三方 Cookie。

您可以参阅身份指南,详细了解如何解决逐步弃用第三方 Cookie 对登录工作流程的影响。

如果前述选项均无法替代 Cookie,则您需要考虑为嵌入重新启用第三方 Cookie 访问权限。这可以通过 Storage Access API 在受控的特定用例中启用。此 API 可重新启用对第三方 Cookie 的完全访问权限(但受到控制),这是功能最强大的方案。因此,如果限制性更强的替代方案足以满足需求,建议应避免使用它。

使用 Storage Access API 有一些要求:

  • 用户之前必须已访问顶级嵌入网站。例如,如果嵌入的是评论系统,则用户还必须访问该评论系统的网站。
  • 用户需要先与嵌入对象互动,然后才能共享 Cookie。这意味着,可能无法在用户互动之前加载完整的嵌入内容。
  • 用户可能需要批准通过浏览器弹出式窗口共享 Cookie,尤其是在第一次访问时以及之后定期显示 Cookie。
  • 嵌入网站可能还需要设置其他沙盒属性

这些限制可确保仅在用户和网站预计这一点时,系统才会执行重新启用第三方 Cookie 这一有效操作。但在某些情况下,系统可能会跳过用户操作。例如,如果用户最近批准了访问权限,则在一段时间(由浏览器定义)内可能不需要重新提示他们。

用户也预料到,这种情况也发生在相关网站上。例如,有些组织使用许多不同的源,浏览器将它们视为跨网站,因此在这些来源中使用 Cookie 也被视为第三方。具体示例包括拥有特定国家/地区网站(例如 example.com 和 example.co.uk)的品牌或品牌专属网站(例如 example.car 和 example.house)。

在这种情况下,如果相关网站较少,您可以使用 Related Website Set。系统会将网站提交到 Chrome,以便 Chrome 知道它们是相关的。这样,您就能以更方便用户使用的方式访问 Storage Access API,减少用户提示数量。

对于实际上属于第三方的无关网站,以及因替代 API 不足而需要完全访问第三方 Cookie 的网站,使用 Storage Access API 时仍需遵守完整要求和提示。

每种解决方案都具有略有不同的特性和限制,因此是适用于特定应用场景的更好选择。下表总结了它们的主要区别:

  条状标签 分区存储空间 FedCM 将 Storage Access API 与 Related WebSite Set 结合使用 Storage Access API
用户不必以前作为顶级网站访问嵌入方          
无需用户提示来批准访问权限          
不需要用户与嵌入内容互动      
(对于具有顶级访问权限的嵌入式网站,也是如此。)
 
实施工作量 非常低
可用于在多个顶级网站/源之间共享 Cookie    
正在审核中的提案。
   
适用于非 Chromium 浏览器      
(回退到 Storage Access API。)
 
行为、所需工作水平,以及适用于嵌入式用例的关键 API 的可用性

正如表格的最后一行所述,浏览器兼容性是决定解决方案的主要因素之一。部分 API(CHIPS、FedCM、Related WebSite Set)仅适用于 Chromium 浏览器。目前仅有的两种跨浏览器解决方案是分区存储 API(不需要 Cookie 时)和 Storage Access API(需要 Cookie 时)。

不过,如前所述,Storage Access API 存在许多限制,可能会影响您网站上的用户体验。Chrome 团队致力于添加其他 API,这些 API 旨在满足特定用例的需求,并提供类似于使用第三方 Cookie 时的体验。因此,我们建议您考虑哪些最佳方案,并将其视为渐进式增强功能,并为不支持的浏览器回退到 Storage Access API。

Cookie 可能会因多种原因(例如浏览器设置、扩展程序)被屏蔽,因此仅靠 API 支持功能检测可能还不够。最好改为测试是否存在预期的 Cookie,如果不存在,则回退到 Storage Access API 工作流程以请求访问第三方 Cookie

如果您的第三方嵌入代码在不使用第三方 Cookie 的情况下无法正常工作,那么还有多种解决方案可供选择,可解决本演讲中所详述的潜在影响。审核服务并为逐步弃用第三方 Cookie 做好准备的时刻已经到来

如果用户在 Chrome 正在测试第三方 Cookie 的移除操作期间嵌入内容遭到破坏,可以在迁移到本文中所述的替代方案时,通过一些短期方法获得帮助。如需了解详情,请参阅保持关键用户体验文档。

如果您对本指南未涵盖的第三方嵌入用例存有疑问,可以在我们的开发者支持存储库中使用“弃用第三方 Cookie”标记提出新问题。

文章链接

标签