某天打开Firefox，发现一直在用的某新标签页拓展挂了，具体表现为其发出的网络连接全部被浏览器在网络层拦截，开发人员工具中显示“已阻止有害附加组件”，无法正常使用。
各处搜索一番后，初步判断该附加组件被拦截属于误伤。考虑到Mozilla官方识别并解除封禁（如果会的话）需要一段时间，我决定手动尝试恢复该附加组件的功能。
首先是查明Firefox是如何识别它认为“有害”的附加组件的。Firefox的附加组件有一个ID，位于附加组件包的manifest.json中，是该附加组件的唯一识别码。我初步的思路是修改并重新打包该附加组件，上传至AMO平台自签名并使用。这个过程理论上不会经过人工审核，应当可以奏效。
花费大量时间让修改后的附加组件通过了AMO自动化验证，再次试用却发现仍被拦截。此时，我猜测识别方式可能包括了附加组件标题，因此批量替换了源码和资源文件中所有特征字段，再次打包上传，拦截依旧。
此次失败后我着实手足无措了一阵子，后来忽然想到，如果Firefox是通过附加组件本身的特征进行识别，为何不在安装和激活环节就拦截，而非要在网络层下手？但当我直接在地址栏输入该附加组件相关域名时，却能够正常访问。
我通过检索工具搜索Firefox目录下所有文件，试图从中找到相关的日志记录，结合搜索到的关键字和一些网络结果，可以确定Firefox在本地单独维护着一个列表，记录了有害附加组件的相关域名，并在附加组件进行联网时进行过滤。和该列表直接相关的是存储在本地的两个加密文件：harmful-addon-block-digest256.sbstore和harmful-addon-block-digest256.vlpset，利用安全软件进行访问控制后，附加组件恢复正常。
然而，此举会造成Firefox频繁尝试读取或修改这些文件，影响暂时未知。