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 年起就开始退役的扩展平台1。Chrome 公布的迁移时间表会在稳定版禁用 MV2 扩展,没有为未重写的扩展提供自动升级路径2。即便从未发生账号转让事件,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 有真实优势处,我们如实说。

评估项CookieVault EditorEditThisCookie
Chrome 应用商店可用性在架,维护中2024-09-28 已移除
Manifest 版本V3（当前）V2（已废弃）
许可证MIT（开源）源码开源,构建不透明
商店构建可复现是否
维护者身份公开是已转让 / 不明
按站点 Cookie 编辑弹窗是是
增 / 改 / 删 Cookie是是
批量 JSON 导出是是
导入 EditThisCookie JSON是不适用（原生格式）
搜索 / 过滤 Cookie是是
端到端加密同步是（Pro）否
多账号档案是（Pro）否
Cookie 历史 / 撤销是（Pro）否
遥测 SDK无转让后构建中存在
Firefox 构建是（MV3）否
Edge / Brave / Opera / Vivaldi / Arc是仅 Chromium,现已无法安装

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

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

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

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

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

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

如何在两分钟内切换

如果你的 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 留在磁盘上是凭证泄漏风险。

另见

Footnotes

  1. Chrome 的 Manifest V3 迁移概览与时间表发布在 developer.chrome.com/docs/extensions/develop/migrate,记录了 Manifest V2 的废弃及其移除的 API。 ↩

  2. Manifest V2 扩展在稳定版的禁用时间表见 developer.chrome.com/blog/resuming-the-transition-to-mv3。 ↩