user.js: FYI: web_accessible_resources & UUID [Bug 1372288, 1405971]

Update:

The manifest key web_accessible_resources is now declared in the dev build of uBO (1.15.7b0+).

This is the only solution for the following uBO’s issues:

• https://github.com/gorhill/uBlock/issues/3474
• https://github.com/gorhill/uBlock/issues/2823

And this will also be the only solution to fix:

• https://github.com/gorhill/uBlock/issues/3497

Firefox

These web accessible resources are never exposed to the DOM – hence uBO’s unique extension id on Firefox cannot be seen by web pages (just as with Decentraleyes).

Chromium

uBlock Origin (or any extension) on Chromium is not assigned a unique extension id, it is assigned a static extension id, used by all installations of uBO. This means that a web page could try to fetch a resource known to be “web accessible” in order to directly find out that uBO is installed – hence more information for fingerprinting (see http://singularity.be/public/papers/extensions.pdf).

This is essentially that leakage of information that prevented me from using web_accessible_resources to solve the above listed issues – that is until the solution described below has been implemented.

uBO foils such information leak by requiring that the fetching of any web accessible resource be done using a secret, which secret is randomly generated at launch time. Without the secret, known only to uBO, the fetch will fail as if the resource does not exist, as if web_accessible_resources is not declared.

Demonstration of such direct detection which is foiled by uBO:

• Install AdBlock from the Chrome store: https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkbiglidom
• Open a new tab to any web page, say https://news.ycombinator.com/
• Open dev console of the web page (press F12)
• Paste the following in the console and hit Enter:
  

  var xhr = new XMLHttpRequest(); xhr.open(‘get’, ‘chrome-extension://gighmmpiobklfepjocnamgkkbiglidom/adblock-jquery-ui.custom.css’); xhr.onload = xhr.onerror = function(response) { console.log(‘AdBlock:’, (this.status===200 ? ‘DETECTED’ : ‘NOT detected’)); }; xhr.send();

• Result if AdBlock is installed and enabled: AdBlock: DETECTED Result if AdBlock is not installed and enabled: AdBlock: NOT detected

However the above won’t work with uBO despite it now declaring web_accessible_resources:

• Install uBO dev build from the Chrome store: https://chrome.google.com/webstore/detail/ublock-origin-dev-build/cgbcahbpdhpcegmbfconppldiemgcoii
• Open a new tab to any web page, say https://news.ycombinator.com/
• Open dev console of the web page (press F12)
• Paste the following in the console and hit Enter:
  

  var xhr = new XMLHttpRequest(); xhr.open(‘get’, ‘chrome-extension://cgbcahbpdhpcegmbfconppldiemgcoii/web_accessible_resources/to-import.txt’); xhr.onload = xhr.onerror = function(response) { console.log(‘uBO:’, (this.status===200 ? ‘DETECTED’ : ‘NOT detected’)); }; xhr.send();

• Result if uBO dev build is installed and enabled: uBO: NOT detected Result if uBO dev build is not installed and enabled: uBO: NOT detected

---

Addendum (2018-02-17):

I experimented further with the case of XMLHttpRequest, which can expose the URL resulting from redirection (through responseURL, as noted by @Synzvato above), and I confirm that redirecting to “web accessible resources” for network requests of type xmlhttprequest will expose the extension id on both Firefox and Chromium.

As a result, I modified the code such that no redirection to web accessible resources will take place when dealing with xmlhttprequest – uBO will fall back to use data: URI in such case (uBO 1.15.7b2+). Redirecting to data: URI is currently broken on Firefox Nightly, but this is being addressed in https://bugzilla.mozilla.org/show_bug.cgi?id=1434357 (there is only a very few instances of such filter in uBO).

Does someone know of another way to extract them?

@earthlng: Let me know. https://github.com/Theemim/GeckoScratchpadSnippets/blob/master/GeckoZipReader.js

@Theemim holy shit man, you’re a fucking god! Thanks mate!! 👍 👍 👍 https://bugzilla.mozilla.org/show_bug.cgi?id=1352595 - it looks like, hopefully, for the time being it will only be used for nightly. Also found this: https://github.com/mcmilk/7-Zip-zstd/issues/26 (aaaaahhhhh shit, now I’ve cross-referenced it again! DOH!)

Same with uMatrix, no web_accessible_resources, neither resource://.

lets make sure it doesn’t leak UUIDs

uBO does not declare web_accessible_resources (webext), and neither expose resource:// (legacy) to outside world.

In Link Cleaner’s case, it doesn’t inject anything into web pages and doesn’t have any web_accessible_resources, so it shouldn’t be affected.

The system addons that came with nightly 57 can no longer be extracted with Windows Explorer on Win7. Do I really need to use a linux VM whenever I want to extract one of those bastards?! Does someone know of another way to extract them? Are there maybe even plans to pack normal addons in the same way in the future?! WTH mozilla, was that really necessary?!?