Hide web accessible resources from websites

[gorhill]

With Chromium-based browsers, web pages can access directly Decentraleyes' web accessible resources, and thus detect whether Decentraleyes is used by a visitor.

This potentially adds one bit of information to fingerprinting.

See: "Discovering Browser Extensions via Web Accessible Resources" www.cse.chalmers.se/~andrei/codaspy17.pdf

Proof-of-concept: https://jsfiddle.net/fuqrudcs/

The change here is to use a secret when accessing a web accessible resource. If the secret is not present when the resource is fetched by the browser, the behavior will be the same as if the resource is not web accessible.

When Decentraleyes redirects a request to one of its web accessible resources, the secret is appended at the end of the local URL as a query parameter.

The secret is generated at runtime when Decentraleyes is launched.

[gorhill]

Note: I noticed that you do not filter by request type for the onBeforeRequest listener responsible for redirection. Is there a reason for not listening only to requests of type script?

With the change here, the solution would be worse than the problem it's trying to solve because the secret token would leak to the outside world if a request of type xmlhttprequest is redirected to a local resource (though one can imagine a fancier solution by generating one unique secret token per redirection).

[ghost]

@gorhill Math.random() isn't cryptographically secure, you should use Crypto.getRandomValues() instead https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValues

[EC-O-DE]

Pardon tad off topic: could uMatrix and/or Decentraleyes have up to date list available of resources that are local by Decentraleyes - meaning the list - if possible - be within reach in uMatrix? In a tab? Maybe just a thick in the tab and Decentras list would appear right so in uMx's rules table? In return also Decentra could - if possible - have a tab(?) - shining light towards uMatrix and how these two exts (not forgetting uBo) are perfect match! <3

Could that type of ~ or similar ~ serve the privacy community in best interest?

Might as well add also this: I'm interested if a bunch of ext devs could get together and would engage to use those libraries through Decentra rather than packing them local or cloud. This is a much of granular before if could get going. It's also possible to reach Chromium/etc devs with requests in mind.

[Synzvato]

Hi @gorhill, and many thanks for contributing your solution.

[...] use a secret when accessing a web accessible resource. If [...] not present when the resource is fetched by the browser, the behavior will be the same as if the resource is not web accessible.

I have been planning to take this approach ever since I read this related comment of yours. So, it was actually quite nice to see this land as a Pull Request. Not only does this help to fight fingerprinting, but it will also fix a Chromium-specific issue, where pages can bypass their CSPs to run bundled scripts.

CSP Vulnerability PoC: https://decentraleyes.org/proof-of-concepts/f1f0c9c0791b3d3b/

I noticed that you do not filter by [...] type for the onBeforeRequest listener responsible for redirection. Is there a reason for not listening only to requests of type script?

Those who enable "Block requests for missing resources", commonly expect requests for unsupported resources (such as fonts and style sheets) to be blocked as well. So, this choice was made to prevent any confusion in that respect. That said, handling all request types (including XHR) is not necessary.

So, ignoring requests of type xmlHttpRequest is absolutely possible. Doing so would break the testing utility, but that's obviously a good sign. Since said utility is pretty popular amongst users, it's probably best to restrict XHR handling to a single, trusted, domain. There do not seem to be any other caveats.

Test Breakage PoC: https://decentraleyes.org/proof-of-concepts/514ef21c8eac1ece/

Math.random() isn't cryptographically secure, you should use Crypto.getRandomValues() [...]

Unless there are any solid reasons to stick to Math.random(), switching to Crypto.getRandomValues() sounds like a very good idea. All target browsers implement the Crypto interface, so compatibility should not be an issue. Also, this runs once per session, so performance should not be a deciding factor.

Pardon tad off topic: could uMatrix and/or Decentraleyes have up to date list available of resources that are local by Decentraleyes - meaning the list - if possible - be within reach in uMatrix?

@EC-O-DE This is off-topic indeed. Feel free to add any additional details to issue #235, instead.