This is the official support thread for No Resource URI Leak (Git repository).
Why this add-on was created
(Brief) History of chrome resources
- Traditionally all browser and add-on resources were accessible from the Web.
- But this was very insecure.
- So unflagged resources with
chrome://URIs were made inaccessible within content.
- However, there were no restrictions about
resource://URIs. There are less privileged, but it was still a big problem.
- Now, content can’t use XMLHTTPRequest (Fetch) or
<link rel="stylesheet" href> and
<script src> tags can be used to load browser or add-on resources under
resource:// URIs. This makes for an easy add-on detection method. You can also use the fact to extract information from an executed script.
Detect installed add-ons
- Event handlers work on
resource://resources on a content page.
computedStylesmay also leak information.
- Scripts on the page can communicate with scripts loaded from
resource://URIs. These scripts run with the content principal but can be used for fingerprinting, vulnerability detection or other problematic purposes.
What this means
- You can’t really fake your browser locale or OS. These true values can be obtained with the
- Web sites will look for installed extensions on the user’s browser. This is terrible for privacy.
- Larger attack surface in case of an exploit.
- Even specially hardened browsers like Tor Browser are affected.
The problem should really be fixed in
mozilla-central. But we can mitigate it with an add-on in the meantime. This is an add-on just for that. It uses
nsIContentPolicy to selectively filter
resource:// access. It does not restrict loading
resource:// files directory into a tab, or access from a privileged context.
We hope everyone to know about the problem. Especially, if you have an ad blocker, or a privacy add-on, or many add-ons installed, you are really strongly encouraged to try this add-on to protect your privacy.
- Some add-ons that load files into Web pages may break.