When using a website, can a website tell which plugins/addons/extensions are installed in a web browser? If so, is it possible to hide that, or randomize the name/identification?
Asked
Active
Viewed 2,731 times
1
-
There isn't a way. Only if the addon exposes something to the public then yes. For instance some may have content accessible resources. So you can use this trick - I can't find it right now, will edit it in. – Noitidart Sep 04 '16 at 20:39
-
@Noitidart so they can't? for example, Google and Ad blocker? I read about Chrome here: http://stackoverflow.com/questions/6293498/check-whether-user-has-a-chrome-extension-installed – User Sep 05 '16 at 22:37
-
@User, The question/answer you linked is about an add-on explicitly being programed to allow a webpage to detect that it is installed. That is easy, and available for all add-on types. Doing so is code that has to be intentionally placed in the add-on. That is a **very** different situation than the question which you asked, which is how to generally determine what add-ons are installed without such detection capability being specifically written into the add-on. – Makyen Sep 06 '16 at 21:22
-
This question is off-topic and has nothing to do with actual programming. As soon as the bounty period expires, it should be closed. – code_dredd Sep 13 '16 at 17:15
3 Answers
3
Add-ons/extensions in general
In general, no:
A web page can not determine a general list of add-ons which are installed in the Firefox browser/profile.
However, you may be able to detect with a high probability that a specific add-on is installed based on the effects that add-on has on the environment, DOM, and, potentially, the operation of your scripts. What those effects are is strictly on an add-on by add-on basis.
URI resource leakage:
As the8472's answer states, one of the effects on the environment which some add-ons may have is leaking web-accessible URIs. You can test for the validity of those which you know are leaked/made available by specific add-ons. Some of the possible URIs include the schemes: about:, moz-extension:, and resource:. As with testing to see what webpages exist on the internet, the combinations of possible URIs is vast, making it unreasonable to search exhaustively. For some specific extensions, you can test for exact known resources.
DOM/computed style changes:
You can test for changes to the DOM, or applied CSS. If you know the effects which a specific add-on has on the DOM (insertions, removals, etc.) or computed style for specific elements, you can test explicitly for those effects. You can also test generally for changes that are ones which you don't expect to see. While testing generally for unexpected changes may tell you that it is likely that an add-on has affected your page, without knowing specific expected changes made by known add-ons and being able to compare the actual changes with the expected changes, you will not be able to say which add-on performed such changes.
Changes to global scope:
You can also test for changes that have been made to your environment. An add-on might prevent resources from loading which you expect, make changes to those resources, or add/inject additional resources/properties/variables/functions. You can test to see if there are any new, missing, or changed properties. As with DOM/CSS changes, you can only state that it was probably a specific add-on if you know the effects that add-on has on your environment. As with DOM changes, you can make a general comparison against what you expect to see in each browser (and version). Again, this can tell you that something was changed, but without comparing it to known changes you will not be able to say it was a specific add-on (or just a new version of Firefox).
Detecting a specific add-on:
You have to determine what effects any particular add-on has which can be detected by your page. This can be determined by experimentation and/or looking at the add-on's source code. For the vast majority of add-ons, the add-on is primarily written in JavaScript. The source code for which is in the install package (usually a .xpi file, which is a zip format file with the extension name changed to .xpi).
Not 100% guaranteed any detection is an exact add-on:
You will only ever know that some changes happened. You might be able to identify the changes you see to be what you expect to be made by a particular add-on, but that does not mean the changes were not made by another add-on. In such a case, it can be very likely that the change was the add-on you are attempting to identify, but it is not 100% guaranteed.
Plugins
The text of your question asks a distinctly different question from the title of your question. Plugins are one type of add-on which provide "shared libraries that users can install to display content that the browser can't display natively." These are, very specifically, intended to provide functionality which is available to webpages. You definately can detect what plugins are available in the browser. You can do so using window.navigator.plugins which provides a PluginArray of Plugin objects describing the plugins which are installed.
Makyen
- 31,849
- 12
- 86
- 121
2
Depends on the type of addon and which URI schemes they use.
Webextensions need to opt-in to expose their moz-extension: resources to the web and iirc they currently randomize their UUIDs on a per-install basis, which makes probing their resources very hard.
Other extension types, especially SDK addons, may register resource:, about: or similarly web-accessible URIs, which are detectable by web content unless blocked by a content policy. For example the no resource URI leak addon and various content blockers do that.
the8472
- 40,999
- 5
- 70
- 122