User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100516 Minefield/3.7a5pre Build Identifier: The results of an EFF study about browser fingerprinting have just been released, and they show that it's a very powerful technique. One of the suggested mitigation strategies is to standardize/normalize various fields that can be used for fingerprinting when in Private Browsing mode. Reproducible: Always

Johnathan, what do you think?

the UA case is a dupe of bug 57555 Using a special UA/font list/installed Plugins in the private browsing mode would be bad because the website should not know if your are in the Private Browsing mode. normalizing navigator.plugins would break pages (plugin detection). btw: this report should be splitted should be 3 bugs and not an all in one bug.

(In reply to comment #1) > Johnathan, what do you think? Beyond Matti's concerns, or maybe by way of aggregating them, I think we need to understand which of these pieces actually CAN be "normalized", and what bustage that might cause. It's certainly the case that *any* change in site-visible behaviour could let a site know you were in private browsing mode, but let's put that aside for a minute. Can we actually normalize user agent? I haven't read the EFF's report yet, but how many bits of uniqueness does that contribute, and are any of the uniqueness bits ones we could eliminate? Hurting navigator.plugins would likely break some things, not sure how much we care or how severe the breakage would be. Pretty sure we can't screw with system fonts, since that's something flash leaks, not us, aiui. This needs some specific cost/benefit analysis on the various pieces. Maybe that's also in the EFF report? I should really get to that...

(In reply to comment #2) >the website should not know if your are in the Private Browsing mode I think the lack of a disk cache in Private Browsing mode probably already results in some easy timing attacks. Why would it matter if sites could tell if you're in Private Browsing mode anyway? > btw: this report should be splitted should be 3 bugs and not an all in one bug. Yeah, this is intended primarily as a meta bug. Thanks for pointing out bug 57555; marking as dependent.

(In reply to comment #4) > (In reply to comment #2) > > >the website should not know if your are in the Private Browsing mode > I think the lack of a disk cache in Private Browsing mode probably already > results in some easy timing attacks. Why would it matter if sites could tell if > you're in Private Browsing mode anyway? In order to better serve user's privacy. It's true that we can't make 100% sure that websites can't tell the difference, but we're not going to make it obvious for web sites how they can tell whether the user is in private browsing mode. > > btw: this report should be splitted should be 3 bugs and not an all in one bug. > Yeah, this is intended primarily as a meta bug. Thanks for pointing out bug > 57555; marking as dependent. Of the three parts of this bug, first one is bug 57555, and the third one is not something which can be fixed in Firefox. So, I'm removing the dependency and morphing this to only cover navigator.plugins.

def. love to see this, should go a long way towards "dimming" finger printing

Why only in Private Browsing mode? This should be default as most people don't bother using Private Browsing mode. http://www.theregister.co.uk/2010/05/17/browser_fingerprint/ Ran test on http://panopticlick.eff.org/ to find out my browser leaves a unique fingerprint in 900,000+ samples they have received so far.

Their paper: http://panopticlick.eff.org/browser-uniqueness.pdf states: "The obvious solution to this problem would be to make the version numbers less precise. Why report Java 1.6.0 17 rather than just Java 1.6, or DivX Web Player 1.4.0.233 rather than just DivX Web Player 1.4?"

Then start a java applet or flash applet and get the exact version string from this applet. With this applet you can get the font list as well with both java and flash and I bet you can do the same with Silverlight. That would help only for dumb plugins that don't have a scripting language. And such a simple change would break pages with their dumb detection scripts. We would need a page like http://geckoisgecko.info/ for such a change. Use http://browserspy.dk/ if you want to know what is possible. in short what you can use for a fingerprint. - Browser (via UA or from many other info that you get with JS) - Browser Version (via UA or from implemented features like html5) - installed fonts (via flash/java maybe silverlight) - OS (from the UA or parse it from the fonts) - OS Version (from the UA or parse it from the fonts) - Installed extensions that modify the UA (like .net) - some addons like adblock or Google Gears, noscript (via probing) - installed Plugins (via JS/navigator.plugins or probing) - exact Plugin Version (via navigator.plugins or from scriptable plugins) - screen resolution (via JS) - used language (from UA or from the accept header) - exact local time on the users system (via js and only if NTP isn't used) and I'm sure that is not all.

(In reply to comment #9) > - Installed extensions that modify the UA (like .net) Sounds like it might be a good idea to stop extensions from doing that, or at least sic the evangelism team on Microsoft.

(In reply to comment #8) > "The obvious solution to this problem would be to make the version numbers > less precise. Why report Java 1.6.0 17 rather than just Java 1.6, or DivX Web > Player 1.4.0.233 rather than just DivX Web Player 1.4?" Because that would break our plugin update checker, which is doing great work keeping people more secure by encouraging them to update plugins with security holes in. If the version info wasn't available, the attacks would not stop. However, the only way the plugin checker could then find out if the user was vulnerable would be to try and exploit the hole! I'm not convinced that this would be a wise thing. As Johnath says, we need a cost-benefit analysis (ideally in a wiki, so people can add to it) for each of the different pieces that the paper is using for fingerprinting. If someone undertakes that work, we would shower them with praise and thanks. And without it, I very much doubt we would make any changes "blind". Gerv

Not blocking on this bug alone. If we decide to block on this issue, we should block on the bigger issue which goes way beyond just installed plugins and their versions, but fixing this bug alone isn't going to help significantly.

Gervase: but WHAT attacks? Really if you don't know where to shoot it's only a waste of bullets. And it's usually not about attacks but about invisible information gathering. To get your fingerprint.

Cost Benefit Analysis? How about asking the User to give Permission, like it is currently done with Geolocation in Firefox, for giving exact version of the Plugin information? If User gives the Permission, for example, the webpage of Firefox Plugin Detector will get all the subversion information like "DivX Web Player 1.4.0.233" If User Refuses, the plugin information will be standardized to 1 decimal place. Like "DivX Web Player 1.4" Geolocation: http://www.mozilla.com/en-US/firefox/geolocation/ (In reply to comment #3) > (In reply to comment #1) > > Johnathan, what do you think? > > Beyond Matti's concerns, or maybe by way of aggregating them, I think we need > to understand which of these pieces actually CAN be "normalized", and what > bustage that might cause. > > It's certainly the case that *any* change in site-visible behaviour could let a > site know you were in private browsing mode, but let's put that aside for a > minute. Can we actually normalize user agent? I haven't read the EFF's report > yet, but how many bits of uniqueness does that contribute, and are any of the > uniqueness bits ones we could eliminate? Hurting navigator.plugins would likely > break some things, not sure how much we care or how severe the breakage would > be. Pretty sure we can't screw with system fonts, since that's something flash > leaks, not us, aiui. > > This needs some specific cost/benefit analysis on the various pieces. Maybe > that's also in the EFF report? I should really get to that...

IMHO, any website access to navigator.plugins should need explicit opt-in from the user, as even the list of installed plugins helps fingerprinting more than any of our default UA strings would.

OTOH, since it's a synchronous API, it's very difficult to implement an opt-in UI, and many major websites would break if navigator.plugins were suddenly undefined.

The plugins check will be incorporated into the Addons manager, see https://wiki.mozilla.org/Firefox/Projects/Extension_Manager_Redesign/design#Plugin_Updates. Once that happens, we don't need need to expose full plugin version information to web content just because of the plugins check. Note that the version is usually part of the name ("QuickTime Plug-in 7.6.6") or description ("Shockwave Flash 10.1 r53"). In addition to that, bug 427744 added navigator.plugins[i].version ...

(In reply to comment #17) > The plugins check will be incorporated into the Addons manager, see > https://wiki.mozilla.org/Firefox/Projects/Extension_Manager_Redesign/design#Plugin_Updates. > Once that happens, we don't need need to expose full plugin version information > to web content just because of the plugins check. > > Note that the version is usually part of the name ("QuickTime Plug-in 7.6.6") > or description ("Shockwave Flash 10.1 r53"). In addition to that, bug 427744 > added navigator.plugins[i].version ... Has the plugins check been incorporated into the Addons manager, for Firefox 4.0 Beta 12? I can see the new UI of the Addons manager in Firefox 4.0 Beta 12, but not sure if the plugins check been incorporated?

This depends upon Bug 613305 - Integrate Plugin Check with installed plugins in the add-ons manager Once Bug 613305 is done, we don't need need to expose full plugin version information to web content just because of the plugins check.

This depends upon Bug 602795 - Add-ons manager should find and install updates for plugins Once Bug 602795 is done, we don't need need to expose full plugin version information to web content just because of the plugins check.

I opened bug 793978 (randomly shuffle navigator.plugins array) as a possible interim fix for plugin fingerprinting.

dup of bug 757726

Is this really a dupe of bug 757726? As per bug 757726 comment 16, this is only a small step against fingerprinting with navigator.plugins.

bug 757726 goes alot of the way. to go beyond that we could allow plugins to only be visible on certain domains, which would certainly apply to many plugins, such add Google talk plugin, and gnome shell extension market plugin.

(In reply to scientes from comment #25) > bug 757726 goes alot of the way. I have to disagree - none of my systems have a plugin that is not extremely common (flash, java, google talk..) and yet http://panopticlick.eff.org/ reports my exact plugin fingerprint has only been seen once before, nearly unique. I would guess that a simple list of the top 20 plugin types / mime types would let you get 100% of this data from the vast majority of users, even without being able to enumerate navigator.plugins. > to go beyond that we could allow plugins to > only be visible on certain domains, which would certainly apply to many > plugins, such add Google talk plugin, and gnome shell extension market > plugin. There's no easy fix for sure. Most of my plugins have extremely specific version numbers, perhaps we could look into "normalizing" those to some extent (or evangelizing for plugin authors to do so)