Skip to content

About the required permissions

Jump to bottom
Raymond Hill edited this page Jun 1, 2015 · 58 revisions

uBlock's required (Chromium) permissions

uBlock's required permissions are the same as those of Privacy Badger, except that Privacy Badger requires one extra permission, cookies. This is uBlock's required permissions:

"permissions": [
    "contextMenus",
    "privacy",
    "storage",
    "tabs",
    "unlimitedStorage",
    "webNavigation",
    "webRequest",
    "webRequestBlocking",
    "http://*/*",
    "https://*/*"
],

"privacy" is the only permission added in version 0.9.8.2. All the others were there since when uBlock was first published (except for "contextMenus" which was added at some point, to support blocking element from within the context menu).

This is Privacy Badger required permissions:

"permissions": [
    "contextMenus",
    "cookies",
    "privacy",
    "storage",
    "tabs",
    "unlimitedStorage",
    "webNavigation",
    "webRequest",
    "webRequestBlocking",
    "http://*/*",
    "https://*/*"
],

It should come as no surprise that privacy-minded extensions require the privacy permission.

"Access your data on all web sites"

Since first version.

  • To be able to inspect all net requests so that they can be cancelled if needed.
    • Only on http- and https-based URL addresses.

See code:

"Access your tabs and browsing activity"

Since first version.

This is necessary to be able to:

  • Create new tabs (when you click on a filter list, to see its content)
  • To detect when a tab is added or removed:
  • To update badge
  • To flush from memory internal data structures
  • To find out which tab is currently active (to fill popup menu with associated stats/settings)
  • To be able to inject the element picker script
  • To implement the popup-blocker

See code:

"Change your privacy-related settings"

Since version 0.9.8.2 (release notes).

This is necessary to be able to:

  • Disable "Prefetch resources to load pages more quickly"
    • This will ensure no TCP connection is opened at all for blocked requests: It's for your own protection privacy-wise.[1]
    • For pages with lots for blocked requests, this will actually remove overhead from page load (if you did not have the setting already disabled).
    • When uBlock blocks a network request, the expectation is that it blocks completely the connection, hence the new permission is necessary for uBlock to do truthfully what it says it does.

uBlock's primary purpose is to block network connections, not just data transfer. Not blocking the connection while just blocking the data transfer would mean uBlock is lying to users. So this permission will stay, and sorry for those who do not understand that it actually allows uBlock to do its intended job more thoroughly[2]. A blocker which does not thoroughly prevent connections is not a real blocker.

Privacy Badger also requires exactly the same permissions. I want uBlock to also serve privacy-minded users first.

If prefetching had been disabled by default, this new permission would not be needed, but prefetching is unfortunately enabled by default, and under Privacy heading, which is itself hidden by default under "advanced settings".

c

Also, the benefits of prefetching are probably marginal, and in the context of a blocker, the benefits could be negative, since a lot of useless connections would be made, just to be discarded after the browser find out the requests won't be made anyway. So do not fall for the "lost of major performance boost" claim I read elsewhere, this is just a silly and baseless claim.

See code:

[1] Merely opening a TCP connection leaks your IP address to the remote server -- this is incompatible with an extension which primary purpose is to completely prevent connections to remove server, not just merely prevent the transfer of data.

[2] In version 0.9.8.3, there will be a setting to allow re-enabling prefetching, default will still be to disable it though.

Wiki home

Clone this wiki locally