Chrome 153把Related Website Sets彻底删了——这件事把企业Chrome托管的根子变了

你企业里 Chrome 的那些「跨站登录」策略，153 版本一升全没了。

Chrome 153 上周进 Beta，稳定版 9 月 8 日到。这是 Chrome 第一次在 2 周发布周期下跑——你的「等一个月再测」策略，现在和下一版发布直接撞上了。但比发布节奏更麻烦的是这次同时删掉的那堆企业策略：有 CTAP2 的，有 Related Website Sets 的，有 XSLT 的，有 rSAFor 的。

其中最该优先测的，是 Related Website Sets（RWS）彻底从 Chrome 删除。

RWS 是什么？

Related Website Sets，前身叫 First Party Sets，是 Chrome 在第三方 Cookie 彻底消亡之前给企业留的一条后路。它允许你声明一组关联站点——比如主站 example.com 加子站 app.example.com、加合作伙伴 portal.partner.com——让它们在跨站场景下共享一组 Cookie。

这样有些企业在第三方 Cookie 被浏览器屏蔽之前，还能靠这个机制维持多域名单点登录。

Chrome 153 说：不伺候了，直接删。

受影响的有这四个策略：

一旦升到 153，这些策略在 chrome://policy 里直接显示「未知策略」，配置被浏览器忽略。

什么场景会爆？

如果你的企业工作流满足以下任意一条，升级后很可能出现 SSO 循环或者会话断掉：

1. 依赖跨域 Cookie 的老系统还在跑

有些内部工具、legacy SaaS，登录态靠的就是 RWS 框架下的 Cookie 共享。RWS 一删，那些域之间的 Cookie 互操作直接回到第三方 Cookie 隔离模式——等于降级。

2. 用 RWS 作为第三方 Cookie 的临时替代

Chrome 原来打的算盘是：等第三方 Cookie 正式退出，RWS 顶上。但后来 Google 宣布第三方 Cookie 不强制退出，这套方案的优先级就一路下跌，到 153 直接拔管。

3. 用 staged policy bundle 分批部署

更隐蔽的坑在这里：如果你的策略用模板批量下发，153 之前的 Chrome 会读 RWS 策略，153 之后的版本直接忽略。同一个配置，两套语义。你的测试环境和生产环境很可能就是这样「分脑」了。

怎么测？

现在就去 Beta 上跑一遍：

1. 装 Chrome 153 Beta（desktop）
2. 用你的托管 profile 正常登录这套工作流
3. 打开 chrome://policy，确认有没有「未知策略」或者「已忽略」字样
4. 核心流程走一遍：登录 → 跳转子域 → 回到主域 → 确认 Session 还在

如果用了 CI 自动化浏览器测试：

Chrome for Testing 的 artifacts 页面可以固定版本，不被自动更新带着跑。跑完记得更新你的 CI 镜像里的 Chrome 版本，不然你会以为 bug 是你引入的，其实是升级漂移。

还有别的坑在路上

RWS 不是唯一被删的。Chrome 153 同时在推进的还有：

XML 解析切 Rust：DOMParser / XMLHttpRequest / SVG 的 XML 解析引擎从 C 语言的 libxml2 换成了 Rust 实现。兼容性目前看问题不大，但有篇分析指出 Windows 上 P99 延迟涨了 209%——对 XML 密集型应用这是个信号。

XSLT 开始退出：RWS 被删和 XSLT 废弃是同一件事的两面。Chrome 已经在拆那套互依赖的 C 代码。

2 周发布周期：这是 meta-change，意思是「Beta 发现问题」到「Stable 用户遭殃」之间现在只有两周。策略变了——不是你能不能测完，而是你测得快不快。

现在该做什么

如果你的企业有托管 Chrome：

• 9 月 8 日之前把 153 Beta 的核心 SSO 路径跑一遍——特别是涉及跨子域 Cookie 的场景
• 检查 chrome://policy 里有没有 RWS 相关策略，有的话现在就开始找替代方案
• 更新你的 Chrome 版本追踪文档，别再按「四周一版」估算发布时间窗口

浏览器每次升级删策略这种事不稀奇。但删得像 153 这样密集、影响面这么广的，不多见。