CookieVault 对比 EditThisCookie

TL;DR：EditThisCookie 做了十年 Chrome Cookie 编辑器的霸主,但 Google 在 2024 年 9 月 28 日把它从 Chrome 应用商店移除了。CookieVault 是开源、原生 Manifest V3 的继任者——同样的 Editor 工作流,外加加密同步、可复现构建、和一个透明的所有者。

CookieVault 对比 EditThisCookie,是一个仍在积极维护的 Manifest V3 Cookie 编辑器与一个曾经霸主、如今已无法安装的 Manifest V2 编辑器之间的对比。CookieVault 是免费、MIT 开源的 Cookie 管理扩展,在所有 Chromium 浏览器加 Firefox 上还原了 EditThisCookie 的按站点编辑工作流;而 EditThisCookie 在 2024 年 9 月 28 日从 Chrome 应用商店下架,并正被 Chrome 的 Manifest V2 退役进程强制禁用。本页客观摆事实,让一个老 EditThisCookie 用户能基于证据而非营销做决定。

可用性与现状

简而言之：EditThisCookie 已从 Chrome 应用商店消失,CookieVault 在架且活跃。新用户根本装不了 EditThisCookie,老安装也收不到任何更新。CookieVault 在 6 个浏览器家族上发布并积极维护。

EditThisCookie 在 2024 年 9 月 28 日从 Chrome 应用商店被移除,起因是维护者账号被转让、新所有者推送了带激进商业化、违反商店政策的更新。原作者 Francesco Capano 已公开声明:他在恶意更新出现多年前就把扩展卖给了第三方,与那些改动无关。但对用户来说,无论责任在谁,结果一样:现在在商店搜原始上架页只会返回 “The item you have requested is not available”,没有任何商店内安装或更新路径。

相比之下,CookieVault 在 Chrome 应用商店、Edge 加载项、Firefox 附加组件都在架,Opera / Vivaldi / Arc / Brave 可从 GitHub 下载签名 CRX 侧载。我们把”维护者账号转让”当作已知的浏览器扩展供应链风险——EditThisCookie 就是教科书案例——并用公开的维护者身份和可复现构建来对冲,而不是让用户去信任一个不透明的发布者。这类转手事件在中文开发者圈也不陌生（早期部分国产浏览器扩展被商业化收购后投毒）。

Manifest 版本与寿命

简而言之：EditThisCookie 是 Manifest V2——Chrome 正在主动禁用的废弃扩展平台。CookieVault 原生 Manifest V3,建立在 Chrome 未来支持的 service worker 架构上。

EditThisCookie 建立在 Manifest V2 上,这是 Google 自 2019 年起就开始退役的扩展平台¹。Chrome 公布的迁移时间表会在稳定版禁用 MV2 扩展,没有为未重写的扩展提供自动升级路径²。即便从未发生账号转让事件,EditThisCookie 也会被这次退役打破,因为它的架构依赖长驻 background page 和 MV3 移除的若干 API。

CookieVault 从头就是 Manifest V3:用临时 service worker 而非长驻 background page,所有读写走官方 chrome.cookies API。你可以自己打开扩展的 manifest.json 看 "manifest_version": 3 验证。这就是”下次 Chrome 更新后还能加载”和”加载不了”的区别。

许可证与可审计性

简而言之：两个项目都发布过源码,但只有 CookieVault 提供可复现构建,证明上架二进制与源码一致。“发布了源码”和”二进制可验证”之间的缺口,恰恰是坑了 EditThisCookie 用户的地方。

EditThisCookie 的源码当年挂在 GitHub 的开源许可证下,社区分支至今可见。问题从来不在源码——而在于经 Chrome 应用商店分发的转让后构建无法对照源码验证。读者没有任何密码学手段确认运行的二进制是否就是那份公开代码。

CookieVault 用可复现构建堵这个缺口:每个 Chrome 应用商店版本都能从某个 git tag 字节级复现,独立审计者可以重新构建并确认与用户下载的完全一致。整个栈——Editor、Guardian、同步服务端、本网站——都是 MIT 许可证。开源是信任的必要条件但不充分;可复现性才是真正防住那个搞掉 EditThisCookie 的攻击类别的部分。

逐项功能对比

简而言之：在核心 Cookie 编辑面上两者接近,CookieVault 对齐了 EditThisCookie 的弹窗工作流。CookieVault 再加上 EditThisCookie 从未有过的加密同步、档案、历史和现代 MV3 兼容。

下表按一个老 EditThisCookie 用户真正会评估的维度对比。凡 EditThisCookie 有真实优势处,我们如实说。

诚实结论:在基础弹窗工作流上,当年的 EditThisCookie 完全够用,CookieVault 刻意镜像它而非另起炉灶。决定性差异在于可用性、Manifest 版本、构建可验证性,以及加密同步功能集。

什么情况下 EditThisCookie 是更好的选择

我们不假装永远没有理由偏好旧工具,但诚实的清单很短:

• 你在一台冻结、离线、锁定旧 Chrome 版本、装不了任何新东西、且现有 EditThisCookie 还能加载的机器上。
• 你只需要一次性导出已有的 Cookie,而本地二进制还能撑到产出这次导出。
• 你对 EditThisCookie 精确的键盘流有特定肌肉记忆依赖,并愿意接受它终将停止工作。

以上每一种情况,推荐动作仍然一样:用还能跑的拷贝导出数据,然后迁移——因为 Chrome 的 MV2 禁用让本地拷贝成了一个不断贬值的资产。

什么情况下 CookieVault 是更好的选择

几乎所有面向未来的场景里,CookieVault 都是更好的选择:

• 你想要一个今天就能在当前浏览器上真正装上的 Cookie 编辑器。
• 你想要弹窗工作流在下次 Chrome 更新后继续工作,而不是随 MV2 退役而坏掉。
• 你在意上架二进制能对照开源验证,而不只是源码存在于某处。
• 你想通过端到端加密同步在第二台设备上访问 Cookie。
• 你管理多个环境,想要命名档案或带撤销的 Cookie 历史。
• 在见识过不透明所有权转让对 EditThisCookie 做了什么之后,你想要一个有公开维护者、商业模式透明的工具。

如何在两分钟内切换

如果你的 EditThisCookie 拷贝还能跑,迁移很快。有序清单:

1. 趁 EditThisCookie 弹窗还能打开,选 Export → JSON,保存文件。
2. 从 Chrome 应用商店装 CookieVault Editor（或 Edge / Firefox 附加组件站;Opera / Vivaldi / Arc / Brave 侧载签名 CRX）。
3. 打开 CookieVault 弹窗,进设置 → Import → EditThisCookie JSON,选中文件。
4. 确认 Cookie 列表已填充,域名、值、过期时间正确。
5. 访问一个登录态依赖刚导入 Cookie 的网站,验证会话有效。
6. 在 chrome://extensions 卸载 EditThisCookie。
7. 可选:在设置 → 同步启用端到端加密同步,让 Cookie 在另一台设备可用。
8. 安全删除导出的 JSON——明文 Cookie 留在磁盘上是凭证泄漏风险。

另见

• EditThisCookie 替代品 —— 完整迁移指南
• CookieVault 对比 Cookie-Editor
• Cookie-Editor 替代品
• CookieVault Editor
• 如何在 Chrome 中编辑 Cookie
• 如何把 Cookie 导出为 JSON