Default-deny is an awesome blocking mode for whoever agrees that in general most 3rd-party resources from web pages:
- are not really all required
- increase privacy exposure
Strictly speaking, default-deny means to block everything and let the user choose what should not be blocked. This strictest mode of default-deny is impractical though, as this means that most web pages would be broken, and more than likely most users would not make use if it.
With uBlock it is possible to use more relax (and thus practical) versions of default-deny: default-deny 3rd-party resources (stricter), or default-deny 3rd-party scripts/frames (more relax).
default-deny 3rd-party will result in more remote resources being blocked, as anything which is 3rd-party to the current site will be blocked by default. This means a higher likelihood that web pages won't render or behave properly:
Default-deny anything 3rd-party: more likely to break, this will need fixing by the user.
A more friendly approach is to use default-deny only for 3rd-party scripts/frames. In such case the likelihood of page breakage is much lower than when blocking anything which is 3rd-party, and yet most of the benefits are still felt:
Default-deny 3rd-party scripts/frames: less breakage, yet most 3rd-party resources are blocked as seen in the picture.
The 3rd-party status of a network request is determined as follow: if the domain of a network request does not match the domain of the web page from which it originates, the network request is deemed 3rd-party. The domain information is extracted as per the official Public Suffix List.
The benefits of using default-deny are plenty:
- Faster page load
- Reduction of bandwidth consumption
- Reduction of privacy exposure
- Increase browser security
- Easier on your browser's memory and CPU footprint
The advantages do not come for free. Often, default-deny will require a bit of work the first time you visit a web site. Using The Guardian as our current example:
As seen in the picture above, a few 3rd-party domains related to theguardian.com
had to be un-blocked for the page to display and behave properly. Notice that noop
rules (dark gray) were used to un-block the domains.
A noop
rule is different than an allow
rule (green): an allow
rule will cause all block filters from static filtering to be bypassed, while a noop
rule will just disengage dynamic filtering and keep static filtering engaged.
Keep in mind that all rules are permanent as soon as they are set (or unset). As of v0.8.8.0, you need to click the padlock to save your rules: all rules are now temporary by default. This allows users to fiddle with rules without worries about polluting their good ruleset. When you want to keep rules for a specific site, click the padlock. The padlock appears if and only if there is at least one temporary rules in the pane.
You can disengage default-deny for the current site with one click: set the "3rd-party" local setting to noop
if you prefer to work this way:
Default-deny cancelled locally. Notice that the blocking of 3rd-party frames is still in effect: cells with higher precedence won't have their rules overriden by cells with lower precedence.
This results in default-deny being disengaged for the current site (The Guardian in our example), while keeping engaged static filtering (EasyList, EasyPrivacy, etc.). In this particular example, as can be seen in the picture, 3rd-party frames will still be blocked (usually a good thing privacy- and security-wise).
This is an important aspect of uBlock's dynamic filtering compared to uMatrix, RequestPolicy, Policeman: in uBlock, rules are ternary, not binary.
working on it.. topic to cover:
no need to use malware domain lists since all 3rd-parties are blocked by default = leaner uBlock
ubiquitous servers blocked by default, i.e. no need to pre-emptively block facebook, google, twitter, linkdin, etc. to prevent tracking by these
provide many real-life examples of how easy it is to un-break websites
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
- 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
- Overview of uBlock's network filtering engine: details
- Does uBlock Origin block ads or just hide them?
- Doesn't uBlock Origin add overhead to page load?
- About "Why uBlock Origin works so much better than Pi‑hole does?"
- 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
uBlock Origin - An efficient blocker for Chromium and Firefox. Fast and lean.