HN Weekly 中文
← #790

安装每一个* Firefox 扩展

查看原文 HN 讨论

文章摘要

作者出于纯粹的好奇心，启动了一项几乎荒诞的实验：把 Firefox Add-ons 商店上所有 84,194 个扩展一次性装进一台浏览器，看看会发生什么。整个项目包括数据抓取、分析与多轮逐步放大的安装尝试，最终以一台 24GB 统一内存的虚拟机完成了全部扩展的安装。

抓取阶段使用 Mozilla 官方 API（无需认证、无速率限制）。初始分页只能拿到 30,000 条，于是作者采用多种绕过策略——切换排序参数（推荐、创建时间、评分、热度、更新时间）、按类别跨 600 页遍历、利用 exclude_addons 参数跳出分页限制，最后用日期范围精确枚举，总共得到 84,235 个唯一扩展，合计约 49.3 GB，平均 584.9 KB/个。最大体积的扩展包括 dmitlichess（196.3 MB，含 2000+ 音效文件）、ReactBot Web（184.9 MB）和 Eric’s Thumbnail Seasoning（146.6 MB）。

数据分析揭示了不少暗面：一些钓鱼扩展利用西里尔字母同形字伪装成知名加密货币钱包；Innover Online Group 名下”Custom Web Search”系列 PUA 扩展累计用户超过 70 万；扩展主页里大量 SEO 垃圾链接绕过 nofollow 约束；34.3% 的扩展日活为零，只有 0.7% 日活超过 10,000。作者”Dr. B”以发布 84 个扩展成为数据集中最高产的开发者。

安装实验从失败到成功经历了 11 次尝试：早期因内存不足和 Firefox 卡死完全失败；中期成功在 6,000 个扩展时还能用，但过 4,000 个后性能急剧下降；直到第 11 次使用串行下载流程（耗时 1 小时 43 分）全部装进一个 24GB 内存的 VM，才勉强跑起来。结果相当荒诞：峰值内存占用 32-37 GB；extensions.json 从典型的 336 KB 膨胀至 189 MB；about:addons 页面需要 6 小时才能完整加载；example.com 24 小时没能打开；新标签页完全无法渲染。核心瓶颈在于 Firefox 的 extensions.json 每次修改都会以 20ms 防抖重写整个文件——这套机制显然是为”普通用户 15 个扩展”的典型场景设计的。

HN 评论精华

  1. 文笔和 meme 感备受称赞：最受欢迎的评论并不聚焦技术问题，而是称赞作者的写作——”这文章读起来太愉快了”，尤其是开启崩溃报告那一段和突然插入的金属管敲击音效梗，让很多人一边看一边笑。

  2. extensions.json 的老问题再次暴露：技术党挖出一个关键细节——Firefox 每 20 毫秒重写一次 extensions.json 的整个文件。15 个扩展时毫无问题，到 84,000 个就彻底崩溃。有评论指出 13 年前 Firefox 其实曾用 SQLite 承担这份元数据，后来的改动让这个组件回退成了扁平 JSON，可扩展性大打折扣。

  3. 32GB 内存占用的震撼数字：对”实验消耗 32GB RAM”这条事实，很多读者表达了既惊叹又好笑的反应。有人打趣说这比他们整台开发机的总内存还多，也有人感慨”终于找到用完 64GB 内存的合理场景了”。

  4. 发现真实的恶意扩展：作者在实验中意外发现一个使用西里尔字母伪装的恶意扩展——它从一个 NocoDB 电子表格拉取钓鱼 URL，更惊人的是作者对这个表格居然还有写权限，于是他直接清空了数据。评论者称这是整篇文章”最有公共价值”的一段，远超实验本身的趣味。

  5. 对 Firefox 生态的延伸思考：一部分讨论延伸到 Firefox 扩展文化本身——有人类比 Windows XP 时代的 IE 工具栏大战，有人好奇”Chrome 能不能扛住同样的实验”，也有人注意到部分扩展会注入伪造的 UI 元素，在大规模安装下会形成彼此混淆的视觉噪音，很容易掉进钓鱼陷阱。