-
Notifications
You must be signed in to change notification settings - Fork 81
About the required 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.
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:
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:
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".
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.
Edit: actually, prefetching is worst than I first thought, I had tested that it was just a connection issue, but as per Google:
If you turn this setting on in Chrome, websites (and any of their embedded resources) that are prerendered or prefetched may set and read their own cookies as if you had visited them before -- even if you don’t visit the prerendered or prefetched pages after all.
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. For instance, see what can be found with a just that connection being established (IP, OS Fingerprinting, IP Address Location).
[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
- About the Wiki documentation
- Permissions
- Privacy policy
- Info:
- The toolbar icon
- The popup user interface
- The context menu
-
Dashboard
- Settings pane
- Filter lists pane
- My filters pane
- My rules pane
- Trusted sites pane
- Keyboard shortcuts
- The logger
- Element picker
- Element zapper
-
Blocking mode
- Very easy mode
- Easy mode (default)
- Medium mode (optimal for advanced users)
- Hard mode
- Nightmare mode
- Strict blocking
- Few words about re-design of uBO's user interface
- Reference answers to various topics seen in the wild
- Overview of uBlock's network filtering engine
- uBlock's blocking and protection effectiveness:
- uBlock's resource usage and efficiency:
- Memory footprint: what happens inside uBlock after installation
- uBlock vs. ABP: efficiency compared
- Counterpoint: Who cares about efficiency, I have 8 GB RAM and|or a quad core CPU
- Debunking "uBlock Origin is less efficient than Adguard" claims
- Myth: uBlock consumes over 80MB
- Myth: uBlock is just slightly less resource intensive than Adblock Plus
- Myth: uBlock consumes several or several dozen GB of RAM
- Various videos showing side by side comparison of the load speed of complex sites
- Own memory usage: benchmarks over time
- Contributed memory usage: benchmarks over time
- Can uBO crash a browser?
- Tools, tests
- Deploying uBlock Origin
- Proposal for integration/unit testing
- uBlock Origin Core (Node.js):
- Troubleshooting:
- Good external guides:
- Scientific papers