mirror of
https://github.com/gorhill/uBlock.git
synced 2024-11-16 23:42:39 +01:00
Grammar fixes and rewording, minor code formatting and structuring fixes
parent
6f392ba46a
commit
649b98a927
@ -2,44 +2,46 @@ This document explains why uBO works best in Firefox.
|
||||
|
||||
### CNAME-uncloaking
|
||||
|
||||
Ability to uncloak 3rd-party servers disguised as 1st-party through the use of [CNAME record](https://en.wikipedia.org/wiki/CNAME_record). The effect of this is to make uBO on Firefox the most efficient at blocking 3rd-party trackers relative to other other browser/blocker pairs:
|
||||
Ability to uncloak 3rd-party servers disguised as 1st-party through [CNAME record](https://en.wikipedia.org/wiki/CNAME_record). The effect of this is to make uBO on Firefox the most efficient at blocking 3rd-party trackers relative to other browser/blocker pairs:
|
||||
|
||||
![c](https://user-images.githubusercontent.com/585534/103416937-b623c400-4b56-11eb-8e94-b4851a2248b7.png)
|
||||
<br>The dark green/red bars are uBO before/after it gained ability to uncloak CNAMEs on Firefox.<br>Source: [_"Characterizing CNAME Cloaking-Based Tracking
|
||||
on the Web"_](https://blog.apnic.net/2020/08/04/characterizing-cname-cloaking-based-tracking/) at [Asia Pacific Network Information Centre](https://www.apnic.net/about-apnic/), August 2020.
|
||||
|
||||
The dark green/red bars are uBO before/after it gained the ability to uncloak CNAMEs on Firefox.
|
||||
|
||||
Source: [_"Characterizing CNAME Cloaking-Based Tracking on the Web"_](https://blog.apnic.net/2020/08/04/characterizing-cname-cloaking-based-tracking/) at [Asia Pacific Network Information Centre](https://www.apnic.net/about-apnic/), August 2020.
|
||||
|
||||
### HTML filtering
|
||||
|
||||
[HTML filtering](https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#html-filters) is the ability to filter the response body of HTML documents _before_ it is parsed by the browser.
|
||||
[HTML filtering](https://github.com/gorhill/uBlock/wiki/Static-filter-syntax#html-filters) is the ability to filter the response body of HTML documents _before_before parsing them by the browser.
|
||||
|
||||
For example, this allows the removal of specific tags in HTML documents before they are parsed and executed by the browser, something not possible in a reliable manner in other browsers. This feature requires the [`webRequest.filterResponseData()`](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/filterResponseData) API, currently only available in Firefox.
|
||||
|
||||
### Browser launch
|
||||
|
||||
At browser launch, Firefox will wait for uBO to be up and ready before network requests are fired from already opened tab(s).
|
||||
Firefox will wait for uBO to be ready before sending network requests from already opened tab(s) at browser launch.
|
||||
|
||||
This is not the case with Chromium-based browsers, i.e. tracker/advertisement payloads may find their way into already opened tabs before uBO is up and ready in Chromium-based browsers, while these are properly filtered in Firefox.
|
||||
In Chromium-based browsers, this is not the case. Tracker/advertisement payloads may find their way into already opened tabs before uBO is ready, while Firefox will properly filter these.
|
||||
|
||||
Reliably blocking at browser launch is especially important for whoever uses default-deny mode for 3rd-party resources and/or JavaScript.
|
||||
Reliably blocking at browser launch is especially important for whoever uses default-deny mode for 3rd-party resources or JavaScript.
|
||||
|
||||
There is a setting available to tentatively mitigate this issue in Chromium-based browsers (disabled by default), see [_Suspend network activity until all filter lists are loaded_](https://github.com/gorhill/uBlock/wiki/Dashboard:-Filter-lists#suspend-network-activity-until-all-filter-lists-are-loaded).
|
||||
A [setting](https://github.com/gorhill/uBlock/wiki/Dashboard:-Filter-lists#suspend-network-activity-until-all-filter-lists-are-loaded) is available, disabled by default, to mitigate this issue in Chromium-based browsers. This setting does not cover 100% of all use cases, and some exceptions may apply.
|
||||
|
||||
### Pre-fetching
|
||||
|
||||
Pre-fetching, which is disabled by default in uBO, is reliably prevented in Firefox, while this is not the case in Chromium-based browsers.
|
||||
Pre-fetching, disabled by default in uBO, is reliably prevented in Firefox, while this is not the case in Chromium-based browsers.
|
||||
|
||||
Chromium-based browsers give precedence to websites over user settings when it comes to decide whether pre-fetching is disabled or not.
|
||||
Chromium-based browsers give precedence to websites over user settings when it comes to deciding whether pre-fetching is disabled or not.
|
||||
|
||||
See [documentation for _"Disable pre-fetching"_ ](https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#disable-prefetching).
|
||||
Reference: [Disable prefetching](https://github.com/gorhill/uBlock/wiki/Dashboard:-Settings#disable-prefetching)
|
||||
|
||||
### WebAssembly
|
||||
|
||||
The Firefox version of uBO makes use of WebAssembly code for core filtering code paths. This is not the case with Chromium-based browsers because this would require an extra permission in the extension manifest which could cause friction when publishing the extension in the Chrome Web Store.
|
||||
The Firefox version of uBO uses WebAssembly code for core filtering code paths. With Chromium-based browsers, this is not the case because this would require an extra permission in the extension manifest that could cause friction when publishing the extension in the Chrome Web Store.
|
||||
|
||||
For more about this, see: <https://github.com/WebAssembly/content-security-policy/issues/7#issuecomment-441259729>.
|
||||
More Information: https://github.com/WebAssembly/content-security-policy/issues/7#issuecomment-441259729
|
||||
|
||||
### Storage compression
|
||||
|
||||
The Firefox version of uBO use LZ4 compression by default to store raw filter lists, compiled list data, and memory snapshots to disk storage.
|
||||
The Firefox version of uBO uses LZ4 compression by default to store raw filter lists, compiled list data, and memory snapshots to disk storage.
|
||||
|
||||
LZ4 compression requires the use of [`IndexedDB`](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API), which is problematic with Chromium-based browsers in incognito mode -- where instances of `IndexedDB` are always reset, causing uBO to always launch inefficiently and with out of date filter lists (see [#399](https://github.com/uBlockOrigin/uBlock-issues/issues/399)). An `IndexedDB` instance is required because it supports storing [`Blob`](https://developer.mozilla.org/en-US/docs/Web/API/Blob)-based data, a capability not available to [`browser.storage.local` API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local).
|
||||
LZ4 compression requires the use of [`IndexedDB`](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API), which is problematic with Chromium-based browsers in the incognito mode where instances of `IndexedDB` get reset, causing uBO to launch inefficiently and with out-of-date filter lists (see [#399](https://github.com/uBlockOrigin/uBlock-issues/issues/399)). `IndexedDB` is required because it supports storing [`Blob`](https://developer.mozilla.org/en-US/docs/Web/API/Blob)-based data, a capability unavailable to [`browser.storage.local` API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local).
|
Loading…
Reference in New Issue
Block a user