Cloaking plugin names to limit browser fingerprinting in Firefox

Web analytics software often tracks people using a “fingerprint” of their browsers’ unique characteristics. Bumper stickers are a good analogy. If you see a blue Volkswagen with the same uncommon bumper stickers as a blue Volkswagen you saw yesterday, there is a very good chance it is the same person driving the same car. If you don’t want people to recognize your car, you can remove your bumper stickers or display the same bumper stickers seen on many other cars. The list of plugins and fonts installed on your computer are like bumper stickers on your browser.

For more technical details of fingerprinting, see Mozilla’s Fingerprinting wiki, the EFF’s Panopticlick demo, or the HTML Standard’s “hidden plugins” description.

I landed a fix for bug 757726 so Firefox 28 will “cloak” uncommon plugin names from navigator.plugins[] enumeration. This change does not disable any plugins; it just hides some plugin names.

If you find that a website no longer recognize your installed plugin when running Firefox 28, this is likely a side effect of bug 757726. Please file a new bug blocking bug 757726 so we can fix our whitelist of uncloaked plugin names or have a web compatibility evangelist reach out to the website author to fix their code.

This code change will reduce browser uniqueness by “cloaking” uncommon plugin names from navigator.plugins[] enumeration. If a website does not use the “Adobe Acrobat NPAPI Plug-in, Version 11.0.02″ plugin, why does it need to know that the “Adobe Acrobat NPAPI Plug-in, Version 11.0.02″ plugin is installed? If a website does need to know whether the plugin is installed or meets minimum version requirements, it can still check navigator.plugins["Adobe Acrobat NPAPI Plug-in, Version 11.0.02"] or navigator.mimeTypes["application/vnd.fdf"].enabledPlugin (to workaround problem plugins that short-sightedly include version numbers in their names).

For example, the following JavaScript reveals my installed plugins:

for (plugin of navigator.plugins) console.log(plugin.name);
“Shockwave Flash”
“QuickTime Plug-in 7.7.3″
“Default Browser Helper”
“Unity Player”
“Google Earth Plug-in”
“Silverlight Plug-In”
“Java Applet Plug-in”
“Adobe Acrobat NPAPI Plug-in, Version 11.0.02″
“WacomTabletPlugin”

navigator.plugins["Unity Player"].name // get cloaked plugin by name
“Unity Player”

But with plugin cloaking, the same JavaScript will not reveal as much personally-identifying information about my browser:

for (plugin of navigator.plugins) console.log(plugin.name);
“Shockwave Flash”
“QuickTime Plug-in 7.7.3″
“Java Applet Plug-in”

navigator.plugins["Unity Player"].name // get cloaked plugin by name
“Unity Player”

In theory, all plugin names could be cloaked because web content can query navigator.plugins[] by plugin name. Unfortunately, we could not cloak all plugin names because many popular websites check for Flash or QuickTime by enumerating navigator.plugins[] and comparing plugin names one by one, instead of just asking for navigator.plugins["Shockwave Flash"] by name. These websites should be fixed.

The policy of which plugin names are uncloaked can be changed in the about:config pref “plugins.enumerable_names”. The pref’s value is a comma-separated list of plugin name prefixes (so the prefix “QuickTime” will match both “QuickTime Plug-in 6.4″ and “QuickTime Plug-in 7.7.3″). The default pref cloaks all plugin names except Flash, Shockwave (Director), Java, and QuickTime. To cloak all plugin names, set the pref to the empty string “”. To cloak no plugin names, set the pref to magic value “*”.

I started hacking on this patch in my spare time 13 months ago. I finally found some time to complete it. :)

3 thoughts on “Cloaking plugin names to limit browser fingerprinting in Firefox

  1. Hi Chris,

    Thanks for the great post!
    I have been thinking about this during my time at Mozilla last summer. I have one extra thought. Can we enhance the privacy by “lying” about the plugins we have. I am working on novel uses of “deception” to enhance the security and privacy.
    To make my point a little clearer, I was thinking if we can have a wrapper over the plugin API that randomly sends a number of available plugins when asked. This will make the fingerprinting almost impossible if we intertwine known and unknown plugins. Surely I see a challenge if you advertise for a plugin then get content the browser doesn’t understand (can’t we simply drop such content!). Another challenge is not advertising for something you have (to address that we might just start with only adding some plugins).
    Interested in hearing your thoughts.

    Cheers,
    Mohammed

  2. hi Mohammed, that’s an interesting idea. Are you suggesting that navigator.plugins[] randomly include real-but-not-installed plugin names or just fake plugin names? Announcing that we have a plugin installed that we don’t actually have could break some web content.

    I proposed bug 793978 to randomly shuffle the order of the navigator.plugins[] array. Currently, navigator.plugins[] is ordered by plugin install time. So even users with the same plugins installed can still have unique fingerprints because it is unlikely that they installed their plugins in the same order. Smart tracking software would need to sort the shuffled plugin array to generate stable fingerprints, throwing away identifying information. Naive tracking software may think every random shuffle order is a new user. :)

  3. “Are you suggesting that navigator.plugins[] randomly include real-but-not-installed plugin names or just fake plugin names?”

    The things I had in mind was the former, however, the latter is also interesting (sure the website must not be able to distinguish a fake one from a real one).

    “Announcing that we have a plugin installed that we don’t actually have could break some web content.”

    Yes! This is a main concern. Would there be any way around it? I would interested to know if the there is a way to advertise for a plugin and simply ignore any content that uses that plugin? Not sure if this even possible.

    “So even users with the same plugins installed can still have unique fingerprints because it is unlikely that they installed their plugins in the same order.”

    Can we also fake the install date? This should not have any impact on the usability while, possibly, significantly reduce the entropy of the fingerprint. We might even fake the dates for every case and reshuffle every time.
    —-
    The main goal I am trying to reach here is to significantly reduce the entropy such that uniquely fingerprinting because far less effective by simply using the browser-sent data.

Comments are closed.