权限 - fang5566/uBlock GitHub Wiki
uBO 需要获取的权限和 Privacy Badger 一样，但 Privacy Badger 还需要多获取一个 cookies 权限。下面是 uBO 需要获取的权限：
"permissions": [
"contextMenus",
"dns",
"privacy",
"storage",
"tabs",
"unlimitedStorage",
"webNavigation",
"webRequest",
"webRequestBlocking",
"http://*/*",
"https://*/*"
],
"privacy" 是 0.9.8.2 版本唯一新获取的权限，其他权限从 uBO 初次发布开始就需要获取了（其中 "contextMenus" 是在某个时候获取的，为了支持从右键菜单屏蔽元素）。
uBO 获取 privacy 权限是为了能禁用“预读取资源以便更快载入页面”这个选项。这么做是确保被屏蔽的请求不会建立任何 TCP 连接：为的是保护你的隐私。
下面是 Privacy Badger 需要获取的权限：
"permissions": [
"contextMenus",
"cookies",
"privacy",
"storage",
"tabs",
"unlimitedStorage",
"webNavigation",
"webRequest",
"webRequestBlocking",
"http://*/*",
"https://*/*"
],
从初始版本开始获取。
- 能够查看所有网络请求，必要时可以取消这些请求。
- 只针对
http和https打头的 URL 地址。
代码参见：
从初始版本开始获取。
在执行以下操作时需要获取此权限：
- 新建标签页（用以当你点击某个规则列表时查看内容）
- 新建或关闭一个标签页时检测：
- 更新图标显示的数字
- 按内存中的内部数据结构刷新数据
- 找到当前处于活动状态的标签页（填写弹出菜单中相关的统计和设置信息）
- 插入元素选择器的脚本
- 实现弹出窗口屏蔽功能
代码参见：
相关权限：dns
从 1.25.0 版本（仅支持 Firefox 60+） 开始获取。
该提示由 dns 权限触发，启用后可使用 browser.dns API，目的是允许 uBO 获得显示主机别名规范名（CNAME，canonical name of aliased hostnames）的能力。
注意即便没有该权限，uBO 也可以查看 IP 地址和主机名信息，它是通过 browser.webRequest API 这个 uBO 已获取的权限实现的。
**重要事项：**这里说的 “IP 地址”指的是你浏览器所连接的服务器 IP地址，而非你设定的 IP 地址。uBO 不访问（也没必要知道）你设定的 IP 地址。
这里有一个 open Firefox issue 讨论该权限的容易混淆的字眼。新版本的 Firefox 不再提示获取该权限。
相关权限：unlimitedStorage。
从初始版本开始获取。
这是允许 uBO 使用 5 MB 以上存储空间的必要权限。uBO 使用客户端存储空间以便保存从远端服务器下载的资源（规则列表和其他资源），这些资源的编译后版本以及各种资源（有足够的启动时间）的快照。uBO 所使用的存储空间信息显示在控制面板的 设置 面板底部。没有该权限 uBO 就无法使用 5MB 以上的存储空间，也就无法保证 uBO 能够正常使用。
从 0.9.8.2 版本（发布说明）开始获取。
在执行以下操作时需要获取此权限：
- 禁用 “预读取资源以便更快载入页面 ”
- 这么做是确保被屏蔽的请求不会建立任何 TCP 连接：为的是保护你自己的隐私[1]。
- 对于包含大量被屏蔽请求的页面，这么做实际上使得页面载入不产生额外开销（如果你事先没有禁用此设置的话）。
- uBO 屏蔽一条网络请求时，我们希望它是完全屏蔽了连接，所以这条新增的权限对 uBO 真正实现屏蔽来说是必要的。
- 禁用 hyperlink auditing/beacon (0.9.8.5)
uBO 主要是用来屏蔽网络连接，而不仅仅是阻止数据传输。只阻止数据传输却不屏蔽连接意味着 uBO 在对用户撒谎，所以这条权限今后需要继续被获取，对于那些不了解 uBO 需要此权限才能完整运作这个事实的用户，我只能表示遗憾[2]。无法彻底阻止连接的过滤工具不是一个真正的过滤工具。
Privacy Badger 也需要获取相同的权限。我希望 uBO 也能首先服务于关心隐私的用户。
如果 预读取 的选项默认是禁用的，uBO 就不需要获取这条新权限，但很遗憾_预读取_ 选项默认是开启的，而且在 Privacy 的 "advanced settings" 下面，这个选项默认不显示。关于这点，你甚至应该去仔细了解一下预读取的负面影响（相关站点：Deceptive Design）。
而且 预读取 带来的帮助基本很有限，有了过滤工具，它甚至会带来负面影响，因为这些本已被浏览器视为不再允许并加以丢弃的无用连接又被建立了起来。所以不要一直纠结于我在别处听说的 "损失重要的性能提升" 的说法，这种说法既愚蠢又毫无根据。
作者注： 实际上预读取功能比我一开始认为的更糟糕，我测试时本来认为它只是连接方面的问题，但实际是 [原来 Google 说过的]((https://web.archive.org/web/20150905193636/https://support.google.com/chrome/answer/1385029)这样：
如果你在 Chrome 里打开该选项，所有被预渲染或预读取的网站（以及任何内嵌的资源）都可能会设置和读取它们自身的 cookies 就好像你之前访问过这些网页 -- 即使你根本没有访问过它们。
或者看看 Mozilla 的说法：
虽然浏览器的页面预读取服务加快了网页载入，但也消耗了额外的带宽。此外，被预载入的网页及其内嵌的内容也可以设置并读取它们的 cookies，就像是它们已经被打开过，尽管它们没被打开过。
代码参见：
[1] 建立一条 TCP 连接只会将你的 IP 地址泄露给远端服务器 -- 这有悖于此类扩展完全阻止连接远端服务器的初衷。例如，你可以看看连接建立时有哪些东西泄露了出来（IP、操作系统信息、IP 地址的位置）。
[2] 我在 0.9.8.3 版本添加了重新启用预读取功能的设置，但默认还是禁止预读取。