mirror of https://github.com/gorhill/uBlock.git
Revert f722ac1c052eedbdfae3fc2f9f48e8d2418ba22b...3dc21c1a1c9feb41d56d8fec9d1f56261169c827
gwarser
parent
3dc21c1a1c
commit
62ecb96551
|
|
@ -0,0 +1,3 @@
|
|||
[TO DO]
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
[TO DO]
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
[Back to _Blocking mode_](https://github.com/gorhill/uBlock/wiki/Blocking-mode)
|
||||
|
||||
***
|
||||
|
||||
<p align="center"><img src="https://cloud.githubusercontent.com/assets/585534/9136321/b78c227e-3ce3-11e5-9949-76e87e7e87e8.png" /><br><sup>3rd-party <iframe> tags blocked by default for all sites.</sup></p>
|
||||
|
||||
### Malware protection
|
||||
|
||||
`iframe` tags are very often used by malware code on compromised web sites -- using 3rd-party-sourced `<iframe>` to inject exploit on a user's computer is quite a common technique:
|
||||
|
||||
- [_"Kovter Group malvertising campaign exposes millions to potential ad fraud malware infections"_](https://www.proofpoint.com/us/threat-insight/post/kovter-group-malvertising-campaign-exposes-millions-potential-ad-fraud-malware)
|
||||
- [_"Massive AdGholas Malvertising Campaigns Use Steganography and File Whitelisting to Hide in Plain Sight"_](https://www.proofpoint.com/us/threat-insight/post/massive-adgholas-malvertising-campaigns-use-steganography-and-file-whitelisting-to-hide-in-plain-sight)
|
||||
- [_"Prince of pop trash PerezHilton pwned, visitors hit with cryptxxx"_](http://www.theregister.co.uk/2016/05/10/pop_prince_perezhilton_pwned_pours_cryptxxx/)
|
||||
- [_"CBS-affiliated Television Stations Expose Visitors to Angler Exploit Kit"_](https://blog.malwarebytes.org/threat-analysis/2016/05/cbs-affiliated-television-stations-expose-visitors-to-angler-exploit-kit/)
|
||||
- [_"Big-name sites hit by rash of malicious ads spreading crypto ransomware"_](http://arstechnica.com/security/2016/03/big-name-sites-hit-by-rash-of-malicious-ads-spreading-crypto-ransomware/)
|
||||
- [_"Massive Admedia/Adverting iFrame Infection"_](https://blog.sucuri.net/2016/02/massive-admedia-iframe-javascript-infection.html?utm_campaign=Massive%20Admedia%20Adverting%20iFrame%20Infection%20blogpost&utm_medium=social&utm_source=twitter)
|
||||
- [_"MSN Home Page Drops More Malware Via Malvertising"_](https://blog.malwarebytes.org/malvertising-2/2016/01/msn-home-page-drops-more-malware-via-malvertising/)
|
||||
- [_"Malvertising Hits DailyMotion, Serves Up Angler EK"_](https://blog.malwarebytes.org/malvertising-2/2015/12/malvertising-hits-dailymotion-serves-up-angler-ek/)
|
||||
- [_"Angler Exploit Kit Blasts Daily Mail Visitors Via Malvertising"_](https://blog.malwarebytes.org/malvertising-2/2015/10/angler-exploit-kit-blasts-daily-mail-visitors-via-malvertising/)
|
||||
- [_"Malware With Your News? Forbes Website Victim of Malvertising Attack"_](https://www.fireeye.com/blog/threat-research/2015/09/malvertising_attack.html)
|
||||
- [_"Malvertising Hits Online Dating Site PlentyOfFish"_](https://blog.malwarebytes.org/malvertising-2/2015/08/malvertising-hits-online-dating-site-plentyoffish/)
|
||||
- [_"Firefox exploit found in the wild"_](https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/)
|
||||
- [_"Advert Strikes Out Via Copycat Gaming Site"_](https://blog.malwarebytes.org/malvertising-2/2015/07/advert-strikes-out-via-copycat-gaming-site/)
|
||||
- [_"Celebrity chef Jamie Oliver’s website hacked, redirects to exploit kit"_](https://blog.malwarebytes.org/exploits-2/2015/02/celebrity-chef-jamie-olivers-website-hacked-redirects-to-exploit-kit/)
|
||||
- [_"Malicious advertisements served via Yahoo"_](http://blog.fox-it.com/2014/01/03/malicious-advertisements-served-via-yahoo/)
|
||||
- [_"jQuery.com Confirms Website Compromise"_](http://www.riskiq.com/blog/business/post/jquerycom-confirms-website-compromise)
|
||||
- [_"Democracy in Hong Kong Under Attack"_](http://www.volexity.com/blog/?p=33)
|
||||
- [_"Yet another case of malvertising on The Pirate Bay"_](https://blog.malwarebytes.org/exploits-2/2014/09/malvertising-on-the-pirate-bay/)
|
||||
- [_"Hackers compromise official PHP website, infect visitors with malware"_](http://arstechnica.com/security/2013/10/hackers-compromise-official-php-website-infect-visitors-with-malware/).
|
||||
- [_"Feds Are Suspects in New Malware That Attacks Tor Anonymity"_](http://www.wired.com/2013/08/freedom-hosting/)
|
||||
- [_"willysy.com Mass Injection ongoing, over 8 million infected pages, targets osCommerce sites"_](http://blog.armorize.com/2011/07/willysycom-mass-injection-ongoing.html)
|
||||
- And so on.
|
||||
|
||||
<p align="center"><img src="https://cloud.githubusercontent.com/assets/585534/9136475/d8ba8bf6-3ce4-11e5-807c-5346e33c971a.png" /><br><sub><a href="http://www.volexity.com/blog/?p=33">"Compromised Pro-Democratic Hong Kong Websites"</a>, volexity.com.</sub><br><sup>uBlock Origin shown just as a reminder on how to block 3rd-party <iframe> tags.</sup></p>
|
||||
|
||||
**Simply blocking 3rd-party `<iframe>` by default foils such exploit.**
|
||||
|
||||
Blocking 3rd-party scripts is generally even better, as the malicious code would have been prevented from executing in the first place. But for users with low tolerance to site breakage, blocking 3rd-party `<iframe>` tags by default (i.e. on all sites by default) is really the best solution.
|
||||
|
||||
Blocking 3rd-party `iframe` tags will typically cause little web page breakage, far less than the more thorough alternative of blocking 3rd-party javascript, so blocking 3rd-party `iframe` tags is an approach that can work even for less advanced users.
|
||||
|
||||
Ultimately, if a site breaks because it really does need legitimate 3rd-party `<iframe>`, then un-blocking `<iframe>` for a specific site is only one click away:
|
||||
|
||||
<p align="center"><img src="https://cloud.githubusercontent.com/assets/585534/9136522/4455038c-3ce5-11e5-9e91-e8843f15c143.png" /><br><sup>3rd-party <iframe> tags blocked by default for all sites,<br><b>except</b> for the current site (this was for github.com) -- <b>using a noop rule</b>.</sup></p>
|
||||
|
||||
But even in this case, the best advice would be to actually find from which specific hostname `iframe` tags are required, and to create a *local* `noop` rule *only* for this hostname, rather than unblock all 3rd-party `iframe` tags on the site -- though this approach is better suited to advanced users.
|
||||
|
||||
### Tracking protection
|
||||
|
||||
Remember the article [ProPublica's _"Meet the Online Tracking Device That is Virtually Impossible to Block"_](http://www.propublica.org/article/meet-the-online-tracking-device-that-is-virtually-impossible-to-block)?
|
||||
|
||||
The title is obviously an exaggeration (the tracking _can_ be blocked).
|
||||
|
||||
The particular `addthis.com` javascript code which attempts to fingerprint your browser executes from within a 3rd-party `iframe`.
|
||||
|
||||
Contrary to what Adblock Plus has been claiming on [its blog](https://adblockplus.org/blog/adblock-plus-and-the-canvas-fingerprinting-threat) and the [media](http://news.yahoo.com/adblock-plus-stop-canvas-fingerprinting-unstoppable-browser-tracking-191541979.html), using _EasyPrivacy_ does **not** prevent AddThis from fingerprinting your browser. This is something I verified and re-verified back then, and I just re-verified again (2014-10-09):
|
||||
|
||||
When you visit <http://www.ibtimes.com/>, the following `<iframe>` is dynamically created:
|
||||
|
||||
<iframe id="_atssh478" title="AddThis utility frame" src="//ct1.addthis.com/static/r07/sh175.html#iit=1412897324950&tmr=load%3D1412897319899%26core%3D1412897320635%26main%3D1412897324941%26ifr%3D1412897324955&cb=0&cdn=1&chr=UTF-8&kw=headline%20news%2Cdaily%20news%2Cbreaking%20news%2Cbusiness%20news%2Cpolitical%20news%2Csports%20news%2Ccurrent%20news%2Ceurope%20news%2Cworld%20news%2Casian%20news%2Ccomputer%20news%2Cairline%20news%2Cbanking%20news%2Cconsumer%20news%2Chealth%20news&ab=-&dh=www.ibtimes.com&dr=&du=http%3A%2F%2Fwww.ibtimes.com%2F&dt=International%20Business%20Times%20-%20International%20Business%20News%2C%20Financial%20News%2C%20Market%20News%2C%20Politics%2C%20Forex%2C%20Commodities&dbg=0&md=0&cap=tc%3D0%26ab%3D0&inst=1&vcl=1&jsl=143585&prod=undefined&lng=en-GB&ogt=title&pc=flw%2Ctbx&pub=ra-4fd117ff2700b0d1&ssl=0&sid=54371a28bc1109db&srpl=1&srcs=1&srd=1&srf=1&srx=1&ver=300&xck=0&xtr=0&og=title%3DAmerican%2520Horror%2520Story&aa=0&csi=undefined&rev=6.2&ct=1&xld=1&xd=1" style="height: 1px; width: 1px; position: absolute; z-index: 100000; border: 0px; left: 0px; top: 0px;"></iframe>
|
||||
|
||||
And within it, the fingerprinting will take place, and result reported to AddThis servers:
|
||||
|
||||
- **Request URL:** `http://ct1.addthis.com/static/r07/sh175.html`
|
||||
- **Cookie:** `uid=54371180c23c9d63; __atuvc=1%7C41; uit=1; km_ai=543717496fd011.83307994`
|
||||
- **Host:** `ct1.addthis.com`
|
||||
- **Referer:** `http://www.ibtimes.com/`
|
||||
|
||||
The above occurred with Adblock Plus with _EasyList_ + _EasyPrivacy_ enabled. Note that the cookie header which contains the fingerprinting information will be stripped if you set your browser to block 3rd-party cookies and site data (preventing 3rd-party cookies is what protects you in this particular case, not ABP + _EasyPrivacy_).
|
||||
|
||||
AddThis and many other 3rd-parties which purpose is to data-mine you will be foiled by blocking 3rd-party `<iframe>` tags (even more so if blocking 3rd-party `<script>` tags).
|
||||
|
||||
By blocking 3rd-party `<iframe>` tags, you don't have to [ask them permission to opt-out](http://www.addthis.com/privacy/opt-out) of something you did not opt-in in the first place. ("Opting out" is a joke anyways, see [_"The web never forgets"_ (PDF)](https://securehomes.esat.kuleuven.be/~gacar/persistent/the_web_never_forgets.pdf), section 6.2)
|
||||
|
||||
In any case, keep in mind that your IP address is as good as fingerprinting if you are assigned a long-lasting one, so blocking 3rd-party `<iframe>` tags goes a long way in foiling trackers out there (and 3rd-party `<script>` tags even better though more site breakage to expect).
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
### Import external filter lists
|
||||
|
||||
You can import external filter lists by clicking the _Import_ checkbox in the _Custom_ section in _"Filter lists"_ pane in the dashboard and pasting the URL address of a filter list into the text area below:
|
||||
|
||||
|
||||
|
||||
### Resources
|
||||
|
||||
See [FilterLists](https://filterlists.com/) for a comprehensive list of filter lists from all over the web (click the _Subscribe_ link of a filter list to import that list into uBO).
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
### uBlock's required (Chromium) permissions
|
||||
|
||||
uBlock's required permissions are the same as those of [Privacy Badger](https://www.eff.org/privacybadger), except that Privacy Badger requires one extra permission, `cookies`. These are uBlock's required permissions:
|
||||
|
||||
"permissions": [
|
||||
"contextMenus",
|
||||
"privacy",
|
||||
"storage",
|
||||
"tabs",
|
||||
"unlimitedStorage",
|
||||
"webNavigation",
|
||||
"webRequest",
|
||||
"webRequestBlocking",
|
||||
"http://*/*",
|
||||
"https://*/*"
|
||||
],
|
||||
|
||||
[`"privacy"`](https://developer.chrome.com/extensions/privacy) is the only permission added in [version 0.9.8.2](https://github.com/gorhill/uBlock/releases/tag/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).
|
||||
|
||||
The `privacy` permission is needed for uBlock to be able to disable the setting "Prefetch resources to load pages more quickly". This will ensure no connection is opened at all for blocked requests: It's for your own protection privacy-wise.
|
||||
|
||||
This is Privacy Badger required permissions:
|
||||
|
||||
"permissions": [
|
||||
"contextMenus",
|
||||
"cookies",
|
||||
"privacy",
|
||||
"storage",
|
||||
"tabs",
|
||||
"unlimitedStorage",
|
||||
"webNavigation",
|
||||
"webRequest",
|
||||
"webRequestBlocking",
|
||||
"http://*/*",
|
||||
"https://*/*"
|
||||
],
|
||||
|
||||
### "Access your data on all web sites"
|
||||
|
||||
Since [first version](https://github.com/gorhill/uBlock/blob/b5fdac90539b19a0db8f36ea537bd150edb4d9c8/manifest.json).
|
||||
|
||||
- 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:
|
||||
|
||||
- [chrome.webRequest](https://github.com/gorhill/uBlock/search?q=%22chrome.webRequest%22&type=Code)
|
||||
|
||||
### "Access your tabs and browsing activity"
|
||||
|
||||
Since [first version](https://github.com/gorhill/uBlock/blob/b5fdac90539b19a0db8f36ea537bd150edb4d9c8/manifest.json).
|
||||
|
||||
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:
|
||||
|
||||
- [chrome.tabs](https://github.com/gorhill/uBlock/search?q=%22chrome.tabs%22&type=Code)
|
||||
- [chrome.webNavigation](https://github.com/gorhill/uBlock/search?q=%22chrome.webNavigation%22&type=Code)
|
||||
|
||||
### "Change your privacy-related settings"
|
||||
|
||||
Since [version 0.9.8.2](https://github.com/gorhill/uBlock/commit/e65c2939757f09db646d277b82da8690aaf3adbc) ([release notes](https://github.com/gorhill/uBlock/releases/tag/0.9.8.2)).
|
||||
|
||||
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.**<sup>[1]</sup>
|
||||
- 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.
|
||||
- Disable [hyperlink auditing/beacon](http://www.wilderssecurity.com/threads/hyperlink-auditing-aka-a-ping-and-beacon-aka-navigator-sendbeacon.364904/) (0.9.8.5)
|
||||
|
||||
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<sup>[2]</sup>. 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"_, and even at this point, you would still have to dig to find out the [negative side effects of prefetching](https://wikipedia.org/wiki/Link_prefetching#Issues_and_criticisms) (related: [dark patterns](http://darkpatterns.org/)).
|
||||
|
||||
|
||||
|
||||
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](https://support.google.com/chrome/answer/1385029):
|
||||
|
||||
> 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:
|
||||
|
||||
- [chrome.privacy.network](https://github.com/gorhill/uBlock/commit/e65c2939757f09db646d277b82da8690aaf3adbc)
|
||||
|
||||
<sub>[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](https://www.browserleaks.com/whois) with a just that connection being established (IP, OS Fingerprinting, IP Address Location).</sub>
|
||||
|
||||
<sub>[2] In version 0.9.8.3, there will be [a setting to allow re-enabling prefetching](https://github.com/gorhill/uBlock/issues/274), default will still be to disable it though.
|
||||
</sub>
|
||||
|
|
@ -0,0 +1,117 @@
|
|||
[Back to Wiki home](https://github.com/gorhill/uBlock/wiki)
|
||||
|
||||
***
|
||||
|
||||
- [The large power button](#the-large-power-button)
|
||||
- [The number of requests blocked](#the-number-of-requests-blocked)
|
||||
- [The tools](#the-tools)
|
||||
- [The number of domains connected](#the-number-of-domains-connected)
|
||||
- [The overview panel](#the-overview-panel)
|
||||
- [The per-site switches](#the-per-site-switches)
|
||||
|
||||
***
|
||||
|
||||
This is uBlock's popup UI when you click on uBlock's icon in the toolbar:
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
### The large power button
|
||||
|
||||
|
||||
|
||||
Click the large power button to turn off uBlock **for the current site** (a.k.a. _whitelist_ the current site). This will be remembered the next time you visit the site.
|
||||
|
||||
Alternatively, you can also <kbd>Ctrl</kbd>-click to turn off uBlock only for the current page (<kbd>command ⌘</kbd>-click on Mac).
|
||||
|
||||
For more advanced whitelisting control, see ["How to whitelist a web site"](https://github.com/gorhill/uBlock/wiki/How-to-whitelist-a-web-site).
|
||||
|
||||
***
|
||||
|
||||
### The tools
|
||||
|
||||
|
||||
|
||||
#### Zap an element on the current page
|
||||
|
||||
Click the _flash_ icon to enter [element zapper mode](https://github.com/gorhill/uBlock/wiki/Element-zapper), which allows you to interactively remove one or more elements on the current page. Removing an element is always temporary, i.e. the removed elements will be back when the page is reloaded.
|
||||
|
||||
#### Create a filter for the current site
|
||||
|
||||
Click the _eye-dropper_ icon to enter [element picker mode](https://github.com/gorhill/uBlock/wiki/Element-picker), which allows you to create a filter by interactively picking an element on a page, thus permanently removing it from the page.
|
||||
|
||||
#### Open the logger
|
||||
|
||||
Click the _list_ icon to open the [logger](https://github.com/gorhill/uBlock/wiki/The-logger) in a separate tab. This allows you to inspect real-time network traffic within the browser.
|
||||
|
||||
Tip: press the <kbd>Shift</kbd> key while clicking the icon to toggle between opening the logger in a separate window or separate tab. uBO will remember that setting when you open the logger without the <kbd>Shift</kbd> key.
|
||||
|
||||
#### Open the dashboard
|
||||
|
||||
Click the _sliders_ icon to open uBlock's dashboard.
|
||||
|
||||
***
|
||||
|
||||
### The number of requests blocked
|
||||
|
||||
|
||||
|
||||
This shows the number of network requests uBlock blocked on the current page. Also, less useful (but people like this kind of thing), the number of network requests uBlock blocked since you installed it. The percentage figure tells you how many requests were blocked out of all the requests made.
|
||||
|
||||
***
|
||||
|
||||
### The number of domains connected
|
||||
|
||||
|
||||
|
||||
The number of **distinct** domains with which a network connection was established, out of all connections (established + blocked). The domains are derived using the official [Public Suffix List](https://publicsuffix.org/).
|
||||
|
||||
In general, it must be assumed that each distinct domain is managed by a distinct administrative authority. In practice, it is not uncommon to have a multiple distinct domains which are under the same administrative authority (example 1: `google.com`, `ajax.googleapis.com` and `gstatic.com`, example 2: `wikipedia.org` and `wikimedia.org`).
|
||||
|
||||
That said, this statistic may be seen this way: the more distinct domains your browser connects to, the greater the privacy exposure.
|
||||
|
||||
In a best-case scenario, the number of distinct domains to which a web page connects should be **only one**: that of the remote server from which the web page was fetched.
|
||||
|
||||
**The higher the number, the higher you are exposing yourself privacy-wise.**
|
||||
|
||||
There is a good correlation between the _domains connected_ count and: unneeded page bloat, high privacy exposure, increased likelihood of being the target of data mining.
|
||||
|
||||
Example: the web page on <http://www.ibtimes.com/> (which can be read fine in all cases, by the way):
|
||||
|
||||
uBlock's mode | turned off | default settings | [default-deny](https://github.com/gorhill/uBlock/wiki/Blocking-mode:-medium-mode)
|
||||
--- | --- | --- | ---
|
||||
domains connected |  |  | 
|
||||
privacy exposure | very high | medium | very low
|
||||
bloat | ridiculously high | medium | very low
|
||||
|
||||
And I had click-to-play enabled in all cases, so it could have been worse (except for default-deny)...
|
||||
|
||||
***
|
||||
|
||||
### The overview panel
|
||||
|
||||
When you click on either the _"requests blocked"_ or _"domains connected"_ label, uBO's popup UI will expand<sup>__*__</sup> to show you more details about requests blocked and domains connected:
|
||||
|
||||
<br><sup>Click the `all` cell at the top to toggle on/off subdomain-level details.</sup>
|
||||
|
||||
The pluses and minuses denote network requests which were either allowed (not blocked) or blocked, respectively for the specific domain/hostname aside which they appear. The number of pluses and minuses are proportional to the number of requests allowed or blocked:
|
||||
- `+`, `-`: under 10 network requests were allowed, blocked.
|
||||
- `++`, `--`: under 100 network requests were allowed, blocked.
|
||||
- `+++`, `---`: 100 or more network requests were allowed, blocked.
|
||||
|
||||
To hide that panel, just click again on either the _"requests blocked"_ or _"domains connected"_ label.
|
||||
|
||||
Unless you are in "advanced user" mode, this panel is read-only and available only for informational purpose.
|
||||
|
||||
In ["advanced user"](https://github.com/gorhill/uBlock/wiki/Advanced-user-features) mode, the panel is fully interactive and can be used for advanced filtering control.
|
||||
|
||||
<sub>__*__ The panel will also be expanded when you enable "advanced user" mode -- this is only for convenience -- it will not close automatically when "advanced user" will be disabled.</sub>
|
||||
|
||||
***
|
||||
|
||||
### The per-site switches
|
||||
|
||||
|
||||
|
||||
The per-site switches allow you to control some settings on a per-site basis. See [detailed documentation about per-site switches](https://github.com/gorhill/uBlock/wiki/Per-site-switches).
|
||||
Loading…
Reference in New Issue