Morfiade
简体中文
试用

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),可以迁移,并且其中的调试功能也是被允许的。

由此得到一条关于操作顺序的实用规则:一个会话不会追溯性地变得可迁移,而是从你在一个独立配置文件里建立它的那一刻起,才变得可迁移。 完整分析见文章《关于会话转移》