Hide web accessible resources from websites
Created by: 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.
Merge request reports
Activity
Created by: 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).@gorhill
Math.random()
isn't cryptographically secure, you should useCrypto.getRandomValues()
instead https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getRandomValuesPardon 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.
Edited by EC·O·DEHi @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 theirCSPs
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 restrictXHR
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 useCrypto.getRandomValues()
[...]Unless there are any solid reasons to stick to
Math.random()
, switching toCrypto.getRandomValues()
sounds like a very good idea. All target browsers implement theCrypto
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 (closed), instead.