Has webpage access to list of installed add-ons? #1327

https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-sanchez-rola.pdf
- https://www.ghacks.net/2017/08/30/firefox-webextensions-may-identify-you-on-the-internet/
- https://usn.ubuntu.com/usn/usn-3391-3/

* https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-sanchez-rola.pdf * https://www.ghacks.net/2017/08/30/firefox-webextensions-may-identify-you-on-the-internet/ * https://usn.ubuntu.com/usn/usn-3391-3/

We don't support WebExtensions, so any privacy issue with them would be N/A.

Read the pdf link, legacy firefox extensions also have leaking problems.
https://www.ghacks.net/2017/08/29/browsers-leak-installed-extensions-to-sites/

Read the pdf link, legacy firefox extensions also have leaking problems. https://www.ghacks.net/2017/08/29/browsers-leak-installed-extensions-to-sites/

I've checked the PDF, and what you are talking about is just not something that can be avoided.

As I already explained on the forum when talking about the "resource leak" BMO bug :

As far as resource:// "leaks" is concerned, no matter what kind of barrier is installed like in that BMO bug, any extension that needs resources from itself accessible to content-injected elements after this lands in Firefox can still be detected by web pages, because it's not possible to make a distinction between native page scripts and injected extension scripts. So the "solution" is very much only a partial band-aid, despite a discussion and offering different patches that has surpassed 200 comments.

Even so, none of this {sic: "leaking" of data} will disclose any private information, since only static information will ever be available from resource:// URIs.

Also, the barrier installed in that bug precludes the use of "legacy" extensions that need this access, which is exactly why it won't be introduced in Firefox until 57.

===

User data (user-specific data/profile data/passwords/history/etc.) will never be accessible this way, despite the fear-mongering statement in the introduction of the PDF, unless an extension explicitly makes this data available to content (in which case the extension would be malicious, but that is a different matter altogether).

Note: There is a way that I know of that can be implemented to completely block any and all content access to resource:// URIs (similar to the blocking of chrome:// addresses) for people who are overly concerned, but it will break many extensions (and preclude any extension-injected content, limiting extensions to only communicating with the browser UI and internals, and not page content -- this barrier can only work in both directions or it will be incomplete and bypassable) and will also break a few browser internals that use content-class pages (e.g. top-level images and media, that by design can't really be rewritten as chrome documents because they will include foreign content which must be content-access restricted to keep the browser secure). As such it is considered a terrible footgun and I don't see a reason to do that.

There is an extension to help with this, already, as well (no-resource-uri-leak). If anything, that will be more complete, can be made site-specific, and provide fine granularity to the user if designed properly -- something a browser core feature cannot without adding massive complexity.

I've checked the PDF, and what you are talking about is just not something that can be avoided. As I already explained on the forum when talking about the "resource leak" [BMO bug](https://bugzilla.mozilla.org/show_bug.cgi?id=863246) : As far as `resource://` "leaks" is concerned, no matter what kind of barrier is installed like in that BMO bug, **any extension that needs resources from itself accessible to content**-injected elements after this lands in Firefox **can still be detected by web pages**, because it's not possible to make a distinction between native page scripts and injected extension scripts. So the "solution" is very much only a partial band-aid, despite a discussion and offering different patches that has surpassed 200 comments. Even so, none of this {sic: "leaking" of data} will disclose any private information, since only **static** information will ever be available from `resource://` URIs. Also, the barrier installed in that bug precludes the use of "legacy" extensions that need this access, which is exactly why it won't be introduced in Firefox until 57. === User data (user-specific data/profile data/passwords/history/etc.) will never be accessible this way, despite the fear-mongering statement in the introduction of the PDF, unless an extension explicitly makes this data available to content (in which case the extension would be malicious, but that is a different matter altogether). **Note:** There _is_ a way that I know of that can be implemented to **completely** block any and all content access to `resource://` URIs (similar to the blocking of `chrome://` addresses) for people who are overly concerned, but it **will** break many extensions (and preclude any extension-injected content, limiting extensions to only communicating with the browser UI and internals, and not page content -- this barrier can only work in both directions or it will be incomplete and bypassable) and will also break a few browser internals that use content-class pages (e.g. top-level images and media, that by design can't really be rewritten as chrome documents because they will include foreign content which _must_ be content-access restricted to keep the browser secure). As such it is considered a terrible footgun and I don't see a reason to do that. There is an extension to help with this, already, as well ([no-resource-uri-leak](https://addons.mozilla.org/en-US/firefox/addon/no-resource-uri-leak/)). If anything, that will be more complete, can be made site-specific, and provide fine granularity to the user if designed properly -- something a browser core feature cannot without adding massive complexity.

Labels Milestones

Has webpage access to list of installed add-ons? #1327