App-Bound Encryption
App-Bound Encryption 是 Chrome 从 127 版本开始用来保护 Cookie 的加密方式。密钥不是绑定在文件上,而是绑定在浏览器本身和机器上:只有 Chrome,而且只有在 Cookie 最初所在的那台机器上,才能把它们解密出来。
这类记录很容易通过数值的开头来识别——v20,而不是之前的 v10。
对普通人来说发生了什么变化
以前,Chrome 配置文件靠复制文件夹就能迁移。现在不行了:复制到另一台电脑上的 Cookie 会变成无法读取的乱码,而且 Chrome 在首次启动时就会把它们当作损坏数据清理掉。大小都还在,但登录状态没了。
我们在一个真实使用中的配置文件上做的测量:
| 检查内容 | 结果 |
|---|---|
| 主配置文件的 Cookie | 共 2618 个,全部是 v20 |
| 同一个文件夹,复制到别处后 | 2618 个里读到 0 个 |
| 在单独文件夹里新建配置文件的 Cookie | 全部是 v10——正常 |
第二把锁:调试功能
加密只是问题的一半。从 Chrome 136 开始,当浏览器运行在默认配置文件夹上时,就不再接受调试密钥(--remote-debugging-port、--remote-debugging-pipe)了。以前,通过调试通道发一条命令就能一次性拿走整个配置文件的所有 Cookie——盗号程序用的正是这一招,现在这扇门被关上了。
这两项限制都是针对会话盗取而出现的,而且对所有人一视同仁。
由此可以得出什么结论
没有人能从你的主 Chrome 里拿走会话——无论是通过文件,还是通过调试通道。如果有人向你承诺相反的说法,那要么是一个旧版本的 Chrome,要么是一个根本不该出现在你电脑上的程序。
与此同时,书签、历史记录、自动填充和扩展程序依然能正常迁移,而密码则作为单独的一步,通过 Chrome 自带的导出到文件功能来完成。
为什么独立配置文件的情况不同
非默认的配置文件夹使用的是不同的加密密钥——这一点写在 Google 自己的公告里。因此,这类配置文件里的 Cookie 仍然是普通的(v10),可以迁移,并且其中的调试功能也是被允许的。
由此得到一条关于操作顺序的实用规则:一个会话不会追溯性地变得可迁移,而是从你在一个独立配置文件里建立它的那一刻起,才变得可迁移。 完整分析见文章《关于会话转移》。
