Helping ensure privacy + security

[Chris Antaki]

Have you heard of EFF's Panopticlick project? It uses various methods to identify your browser, then shows you how unique its footprint is.

It turns out that the ability to enumerate plugins and mimetypes is actually one of the largest sources of uniquely identifiable information it collects. Of course, every piece of information adds up.

Inspired by the Panopticlick project, I built a Firefox addon that currently has 2,199 users (https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-plugins-mimety/). By preventing enumeration of plugins and mimetypes, it made fingerprinting browsers more difficult.

Sadly the addon was broken with Firefox 41, due to this update https://bugzilla.mozilla.org/show_bug.cgi?id=1169945.

Now I understand how the plugins.enumerable_names was broken for certain uses. However, when using it in a Binary way, that is either setting the default value or setting "" for an empty whitelist, it actually worked great.

I'm wondering if we could bring back a simplified version of the feature. And furthermore, what other steps can we take to empower privacy-conscious Firefox users?

[Chris Peterson]

Post by Chris Antaki
Have you heard of EFF's Panopticlick project? It uses various methods to identify your browser, then shows you how unique its footprint is.
It turns out that the ability to enumerate plugins and mimetypes is actually one of the largest sources of uniquely identifiable information it collects. Of course, every piece of information adds up.
Inspired by the Panopticlick project, I built a Firefox addon that currently has 2,199 users (https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-plugins-mimety/). By preventing enumeration of plugins and mimetypes, it made fingerprinting browsers more difficult.
Sadly the addon was broken with Firefox 41, due to this update https://bugzilla.mozilla.org/show_bug.cgi?id=1169945.
Now I understand how the plugins.enumerable_names was broken for certain uses. However, when using it in a Binary way, that is either setting the default value or setting "" for an empty whitelist, it actually worked great.
I'm wondering if we could bring back a simplified version of the feature. And furthermore, what other steps can we take to empower privacy-conscious Firefox users?

To provide some background context for others, here is an excerpt from
our discussion in bug 1169945:

I wrote the plugins.enumerable_names feature (in bug 757726) and removed
it (in bug 1169945).

The plugins.enumerable_names whitelist was incomplete fingerprinting
protection and broke a lot of websites. The whitelist breaks on nearly
all websites that depend on a plugin not exposed in the
plugins.enumerable_names pref. Tech evangelism bug 934107 has some
examples of sites that were broken, contacted by Mozilla, and still have
not fixed their plugin detection. For every website reported, there are
likely 100x more broken but not reported.

But the big hole is that "hidden" plugins are still visible to tracking
websites because they can query navigator.plugins using a long list of
known plugin names. A better solution is to configure your plugins to
"Never Activate" by default and them allow individual plugins on on the
websites that use them. That will protect you from both plugin
fingerprinting and plugin vulnerability exploits on random websites or
ad networks.

We could make that per-site UI easier. Bug 1186948 would make per-site
enumeration opt-in easier by hiding click-to-play ("Ask to Activate")
plugins from websites enumerating navigator.plugins until the user
clicks the click-to-play button.

[Chris Antaki]

Post by Chris Peterson
We could make that per-site UI easier. Bug 1186948 would make per-site
enumeration opt-in easier by hiding click-to-play ("Ask to Activate")
plugins from websites enumerating navigator.plugins until the user
clicks the click-to-play button.

If the plugin was hidden on pageload, prior to click-to-play, is it possible many sites would still break in the same way?

Also, to take a step back, I have some questions about the 'plugins.enumerable_names' feature. For the 2,199+ people who were using my plugin, which prevented plugin & mimetype enumeration entirely by setting the value to "", do you think their decision to accept poorly written JavaScript to break, as it does, was valid? Do you think they should be able to make that decision, assuming they might value their privacy over the functionality of some websites?

[Chris Antaki]

Also, do you think disabling plugin enumeration makes generating unique browser footprints more expensive/difficult? For instance, someone might be using a rare plugin, one that wouldn't be on even a well kept list of plugins to specifically search for. Perhaps it's something they made for themselves and a small group of their friends, team members, etc. In a situation like that, wouldn't disabling plugin enumeration add value?

I like your Click-to-play idea too! I think it could coexist with an option to disable plugin enumeration entirely too.

[Chris Peterson]

Post by Chris Antaki
Also, do you think disabling plugin enumeration makes generating unique browser footprints more expensive/difficult? For instance, someone might be using a rare plugin, one that wouldn't be on even a well kept list of plugins to specifically search for. Perhaps it's something they made for themselves and a small group of their friends, team members, etc. In a situation like that, wouldn't disabling plugin enumeration add value?

Yes, hiding unique plugins definitely reduces browser fingerprinting.
That's why I was motivated to write the plugin-hiding feature in the
first place. :-)

However, there are much easier ways to track users than fingerprinting
uncommon plugins. For example, supercookies use multiple tracking
methods to make deleting a cookie very difficult. And, as shown on
Panopticlick, Flash allows trackers to fingerprint all your system fonts
(which may be hundreds), which exposes at least as much user entropy as
the fingerprinting a dozen common and uncommon plugins.

Hiding plugins does reduce the amount of fingerprinting information
available to trackers, but it is a small hole in a big bucket. And the
C++ code to hide plugins added extra complexity to Firefox's already
ugly plugin handling code.

[Chris Antaki]

Sites would break, but the patch in bug 1186948 would show Firefox's click-to-play notification. If the user allowed the plugin, Firefox would refresh the page and then expose the plugin in navigator.plugins so the site could properly detect it.

That sounds awesome, actually.

I suspect that many of your users didn't use sites that required plugins other than Flash or Silverlight (which were whitelisted in plugins.enumerable_names).

In the description of the plugin, I actually recommend people install FlashBlock. "I also recommend installing FlashBlock, since it prevents your fonts from being harvested." Personally though, I disabled Flash entirely, in Firefox and Chrome. And for what it's worth, I used to be a Flash developer primarily.

Your add-on would effectively make all other plugins undetectable, as if they had been disabled in the Add-ons Manager.

Well, wasn't my plugin just preventing enumeration of the `navigator.mimeTypes` and `navigator.plugins` objects? My understanding was that the plugins could still be queried for directly, which would be a more efficient method O(1), and more respectful of user privacy.

Actually, installing your add-on is easier than manually disabling each plugin one by one. :-)

That gets to the core of the issue, I think. You suggested a method earlier, where a user would disable every plugin by hand, and then enable them per site, also by hand. This method is functionally excellent. It also takes a lot of effort and time. If we can make privacy and security easy, that's when a *much* larger group of people will start enjoying it.

Yes, hiding unique plugins definitely reduces browser fingerprinting. That's why I was motivated to write the plugin-hiding feature in the first place. :-)

For sure, and even leaving them to be accessible by a direct O(1) query, but not a O(N) comprehensive query would reduce browser fingerprinting, right? And thanks by the way, for adding the feature in the first place!

However, there are much easier ways to track users than fingerprinting uncommon plugins. For example, supercookies use multiple tracking methods to make deleting a cookie very difficult. And, as shown on Panopticlick, Flash allows trackers to fingerprint all your system fonts (which may be hundreds), which exposes at least as much user entropy as the fingerprinting a dozen common and uncommon plugins.

Totally agree. The system fonts are a much stronger identifier than plugin names & versions. Both are significant, but the fonts tend to expose more, especially for anyone who has delved into design. I hope most of the users of my plugin installed FlashBlock, as I recommended in the description. Or hey, maybe some of them took it a step further, like myself, and just disabled Flash altogether. I used to develop Flash, and really loved it, but honestly in this day and age the innovation it channels are zero-day exploits. Those worry me more than font harvesting.

Hiding plugins does reduce the amount of fingerprinting information available to trackers, but it is a small hole in a big bucket. And the C++ code to hide plugins added extra complexity to Firefox's already ugly plugin handling code.

It can be a large hole too. If a user has an uncommon plugin, or even an uncommon version of a popular plugin, enumeration allows that data to be easily crawler.

I understand there's asymmetry when we discuss this issue. It's easy for me to ask for more security features, when I don't have to write the C++. I'd just hope that you, and other developers involved in this, keep in mind that security is one of Firefox's key advantages over Chrome. If not the most important one. While it might be challenging, maybe it's a challenge that only a company like Firefox, a non-profit whose business model isn't based around surveillance, can take on?

[Chris Peterson]

Post by Chris Antaki

Your add-on would effectively make all other plugins undetectable, as if they had been disabled in the Add-ons Manager.

Well, wasn't my plugin just preventing enumeration of the `navigator.mimeTypes` and `navigator.plugins` objects? My understanding was that the plugins could still be queried for directly, which would be a more efficient method O(1), and more respectful of user privacy.

The plugins can still be queried directly, but convincing each and every
website to rewrite their plugin detection code is a "boil the ocean"
problem. It's never going to be complete and there will always be
unmaintained websites that expect a plugin but won't work in Firefox.

Support for all NPAPI plugins (except Flash) will be removed next year,
so plugin fingerprinting will no longer be a problem. (However,
fingerprinting system fonts using Flash will still be a problem.)

https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

[Chris Antaki]

Regarding the big change next year, that's great news!

The plugins can still be queried directly, but convincing each and every website to rewrite their plugin detection code is a "boil the ocean" problem. It's never going to be complete and there will always be unmaintained websites that expect a plugin but won't work in Firefox.

I agree, convincing every website to rewrite their detection would be like boiling the ocean. Perhaps a little easier, and better for the environment, but essentially impossible.

As a user though, I would love the option, just the option that existed until very recently, to prevent a website from enumerating plugins. If that causes a website's code to break, it's fine. I see it as a protest of sorts. And of course, more importantly, it makes mass surveillance more expensive. And I mean, protesting and making mass surveillance more expensive, isn't that really all we can do, much of the time?

[Chris Antaki]

Is there any way we could just revert the recent change, until the big change next year? :)

[Chris Peterson]

Post by Chris Antaki
Is there any way we could just revert the recent change, until the big change next year? :)

I think a better solution would be an add-on that disabled all plugins
by default and then provided an easy user interface to configure the
per-site settings for each plugin. All these per-site settings are
available in the about:permissions page, but it is not user-friendly. A
simple tab with a list of sites and their allowed plugins would be much
easier to use.

[Chris Antaki]

Thanks for sharing your knowledge, Chris. I really like your suggestion to disable all plugins by default. As an added bonus, it also works in Chrome.

[Chris Peterson]

Post by Chris Antaki
Thanks for sharing your knowledge, Chris. I really like your suggestion to disable all plugins by default. As an added bonus, it also works in Chrome.

I really like that idea. The best UI is no UI: your add-on could disable
all plugins by default, but instead of including UI to maintain a plugin
whitelist, the add-on could include its own curated whitelist of which
plugins should be allowed on which websites. For example:

* Silverlight could be disabled by default but whitelisted to be allowed
on netflix.com and amazon.com (and some of the other video-on-demand
sites that use Silverlight).

* QuickTime could be disabled by default but whitelisted to be allowed
on for apple.com (where it is used for movie trailers and product demos).

Flash is so ubiquitous, you would probably need to allow it everywhere.

To expand the add-on's plugin/website whitelist, users could send you
lists of plugin websites they use. Or the whitelist could be maintained
on GitHub so users can submit pull requests to update list more easily.


chris

[Chris Peterson]

Post by Chris Antaki

Post by Chris Peterson
We could make that per-site UI easier. Bug 1186948 would make per-site
enumeration opt-in easier by hiding click-to-play ("Ask to Activate")
plugins from websites enumerating navigator.plugins until the user
clicks the click-to-play button.

If the plugin was hidden on pageload, prior to click-to-play, is it possible many sites would still break in the same way?

Sites would break, but the patch in bug 1186948 would show Firefox's
click-to-play notification. If the user allowed the plugin, Firefox
would refresh the page and then expose the plugin in navigator.plugins
so the site could properly detect it.

Post by Chris Antaki
Also, to take a step back, I have some questions about the 'plugins.enumerable_names' feature. For the 2,199+ people who were using my plugin, which prevented plugin & mimetype enumeration entirely by setting the value to "", do you think their decision to accept poorly written JavaScript to break, as it does, was valid? Do you think they should be able to make that decision, assuming they might value their privacy over the functionality of some websites?

I suspect that many of your users didn't use sites that required plugins
other than Flash or Silverlight (which were whitelisted in
plugins.enumerable_names). Your add-on would effectively make all other
plugins undetectable, as if they had been disabled in the Add-ons
Manager. Actually, installing your add-on is easier than manually
disabling each plugin one by one. :-)

[PluginUser]

As a user of the plugin and supporter of the concept that I do not want to expose information, the logic of this thread puzzles me.

The root scenario for me is this: I do not want websites to be able to query information about my browser, what plugins I have running, or anything else - except when I approve that information. This is not "disable the plugin" but have the plugin run and yet not be reported.

What I see is that a valid plugin that provided exactly this feature has been disabled by recent design changes. Not because it was problematic, but just because. (If there was a technical reason that I failed to see, please do point it out.)

When called on this de-featuring, what I see as a response is basically: all of this is going away in a future release, when we also expect to alienate most of our users, so we won't bother reverting this.

The other argument I see raised is this: there are thousands of other points of attack, why bother with this one? The obvious answer is that you have to start somewhere, and this was a vector that was closed, until a code change took away this ability to close the vector. The underlying argument here boils down to this: we might as well all go back to FTP and Telnet, because the Internet is insecure, and it's too hard to fix all the holes.

Asking users to manually enable/disable plugins per-website is not likely to scale - particularly as more sites use third-parties to provide key content and infrastructure, so the "active" list will have to keep evolving even for established websites. It also doesn't address my desired outcome: no website should have the right to ask me for information I do not want to provide. The default answer should be null, not everything under the sun.

Could this conversation be turned back around to the original purpose?

* Why was the feature removed on technical grounds?
* Why do you not want to re-introduce the feature on technical grounds?

[Chris Peterson]

Post by PluginUser
The root scenario for me is this: I do not want websites to be able to query information about my browser, what plugins I have running, or anything else - except when I approve that information. This is not "disable the plugin" but have the plugin run and yet not be reported.

Do you have examples of websites that use NPAPI plugins successfully
even when the plugin names are hidden? Which plugins do the websites
use? We had lots of broken websites reported and only a couple websites
actually fixed their plugin detection.


chris

[Chris Antaki]

Disabling plugin enumeration made it more difficult to grab every enabled plugin in one fell loop. In my opinion, it made Firefox more secure, even if it wasn't perfect. It still made mass surveillance more difficult and expensive, which is realistically one of the strongest courses of action we have as privacy activists.

I wish Firefox had kept the setting. It was removed because it caused poorly coded sites to break, and wasn't a perfect feature. I worry that the *exact* same logic could be used to remove the ability to disable cookies and WebRTC in Firefox.

Chris P's suggestion to disable all plugins works in both Chrome and Firefox though, which is kind of amazing.

Without the differentiation in privacy standards, I've switched to using Chrome in the past few weeks. There's definitely a difference in performance! I think Firefox still offers a lot of value, but perhaps in a modified form, like how it's being extended in the Tor browser-bundle.

[Chris Antaki]

If you can live without plugins, I think disabling them all is the way to go. Like Chris P pointed out, it prevents them from even being queried directly, which was possible even when the enumeration was disabled.

Disabling Flash and Java in-browser is a huge privacy and security win too. Flash allows for font-harvesting and supercookies. Both plugins are popular channels for 0-day exploits.

[Chris Peterson]

Post by Chris Antaki
Disabling plugin enumeration made it more difficult to grab every enabled plugin in one fell loop. In my opinion, it made Firefox more secure, even if it wasn't perfect. It still made mass surveillance more difficult and expensive, which is realistically one of the strongest courses of action we have as privacy activists.
I wish Firefox had kept the setting. It was removed because it caused poorly coded sites to break, and wasn't a perfect feature. I worry that the*exact* same logic could be used to remove the ability to disable cookies and WebRTC in Firefox.
Chris P's suggestion to disable all plugins works in both Chrome and Firefox though, which is kind of amazing.

I still feel that hiding the plugin names is untenable because you can't
fix all the websites and the plugin names are still visible to trackers
that query them using a list of known plugin names. In contrast,
disabling plugins by default and selectively allow plugins on the
websites you care about is more private and doesn't break websites.

For example, assume you want to use the Google Earth plugin. If plugin
enumeration is disabled, then you must whitelist the Google Earth
plugin, thus exposing the plugin to ALL websites and trackers. If you
instead selectively plugins only on the websites that need them, then
you only need to expose Google Earth plugin to google.com.


chris p.

[Chris Antaki]

Post by Chris Peterson
I still feel that hiding the plugin names is untenable because you can't
fix all the websites and the plugin names are still visible to trackers
that query them using a list of known plugin names. In contrast,
disabling plugins by default and selectively allow plugins on the
websites you care about is more private and doesn't break websites.

Totally! It sounds like we agree that disabling plugins is a safer solution. We just disagree in our value assessments of disabling plugin enumeration and whether users should be empowered to make that choice.

[Josh]

So . . . the argument is basically that "some websites might break with this field changed" regardless of how it is changed.

So we can expect the next release of Firefox to prevent users from altering the User Agent string, then? After all, changing that to a different value (or null) can and will break many websites.

I use this example as an extreme case to show the logically inconsistent stance taken. Users want the ability to limit information or otherwise alter the behavior of their browser. Chris' plugin, the "FireGloves" plugin, and many others do this.

What I am seeing is a lack of a technical argument for why the defeaturing took place. It's simply because one person doesn't think people should do this . . . really? There are thousands of plugin users that disagree.

As for sites breaking - as with the User Agent string - that's between the user and the extension developer. Maybe something else will need to be added. But this is such a niche area at the moment, the "nanny mode" mindset should be thrown out, and users should be expected as competent and aware of the risks.

This kind of behavior is what led to Gnome 3 having such a massive fork and split of the userbase.

[Chris Peterson]

Post by Josh
So . . . the argument is basically that "some websites might break with this field changed" regardless of how it is changed.
So we can expect the next release of Firefox to prevent users from altering the User Agent string, then? After all, changing that to a different value (or null) can and will break many websites.

Customization of the User Agent string will not be removed because it is
useful for improving compatibility with some websites and for testing.

Post by Josh
I use this example as an extreme case to show the logically inconsistent stance taken. Users want the ability to limit information or otherwise alter the behavior of their browser. Chris' plugin, the "FireGloves" plugin, and many others do this.
What I am seeing is a lack of a technical argument for why the defeaturing took place. It's simply because one person doesn't think people should do this . . . really? There are thousands of plugin users that disagree.

Please read the rest of this thread. I implemented this feature, so I am
clearly sympathetic to the privacy aspects. I am also the "one person"
who removed it. It is an all-around worse solution than disabling
plugins by default and selectively enabling them for websites you need.

This feature could never be enabled by default because it broke too many
websites. And there was no value in leaving this code dormant because,
if someone enabled the pref on their machine, it would break websites.

I have asked for, and no one has yet provided, one example of a website
that uses an NPAPI plugin successfully when plugin names are hidden.

[Chris Antaki]

Post by Josh
As for sites breaking - as with the User Agent string - that's between the user and the extension developer. Maybe something else will need to be added. But this is such a niche area at the moment, the "nanny mode" mindset should be thrown out, and users should be expected as competent and aware of the risks.

Well said!

[t***@gmail.com]

i need add-on Disables enumeration of mimeTypes & plugins. for my work..pls share me file addon..i can add for firefox Manual

[Chris Peterson]

Post by t***@gmail.com
i need add-on Disables enumeration of mimeTypes & plugins. for my work..pls share me file addon..i can add for firefox Manual

If you are concerned about websites knowing which plugins you have
installed, the safest method is to disable all the plugins in the
Add-ons Manager ("Never Activate" setting) and then manually allow the
each plugin you need when you visit a website.

[Chris Antaki]

The more I've thought about your decision to remove the enumerable option, the more it makes sense. The method you just outlined is solid.

[Chris Peterson]

Post by Chris Antaki
The more I've thought about your decision to remove the enumerable option, the more it makes sense. The method you just outlined is solid.

There is a missing piece in my recommendation, though: the UI for
whitelisting a disabled plugin for individual websites you trust is not
easy to use (i.e. a checkbox buried in the Page Info dialog box). A
browser extension (hint hint ;) could add a toolbar button that can
allow or block plugins from a simple dropdown menu with check boxes.
That extension functionality would be useful in both Firefox and Chrome.

[l***@gmail.com]

This thread is chasing its tail and not getting anywhere.

The suggestion of manually enable and disable plugins is micro-management. You can see it as a form of nagging.

I've seen this sort of technique used to annoy users in to not doing it at all because for some reason the company don't want users to do it. Usually it boils don't to money.

Basically it's a form of manipulation technique.

One form of this is Chrome's nagging message when you have custom extensions enabled. Google say it's for "security reasons" but that's just bullshit. They want to control extensions development via their web store. Whatever their hidden reason for it, it's bad.

Excuse the half-rant.

Lets avoid more circular argumentation and wasting of time.
Let me blunt. It's simple, either you revert the change or say you will refuse to do it. So we can move on.

To say you removed it because of "extra complexity" is a weak excuse. After all will not the code be removed anyway when the big change happens, if I understand it correctly. So why the hurry of removing that code now?
I fail to see a valid point here based on this thread.

Excuse my maybe somewhat harsh direct tone.

[Chris Peterson]

Post by l***@gmail.com
To say you removed it because of "extra complexity" is a weak excuse. After all will not the code be removed anyway when the big change happens, if I understand it correctly. So why the hurry of removing that code now?
I fail to see a valid point here based on this thread.

I removed the feature (which I originally implemented) because:

1. It broke real websites.
2. It provided very little privacy benefit.
3. It provided zero security benefit against plugin vulnerabilities
(because the hidden plugins are still enabled and accessible to any
website).
4. The code added extra complexity required to manage multiple lists of
plugins (hidden and visible) even though the feature was disabled (see
#1) and could not be re-enabled.

Yes, Firefox's NPAPI code will eventually be removed, but that's more
than a year away. Even after NPAPI support is removed, Firefox must
retain some of that code to continue supporting Flash.

I do not plan to spend any more time on this feature. It is a dead end.
But you are welcome to submit patches for someone else to review. My
original patches are still accessible in Bugzilla.

chris