> 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?