566423 - Consider standardizing/normalizing navigator.plugins (browser fingerprinting)

Status: RESOLVED DUPLICATE of bug 757726

(Core Graveyard :: Plug-ins, defect)

Description

[WulfTheSaxon [:Wulf]]

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

Comment 1

[(no longer active)]

Johnathan, what do you think?

Comment 2

[Matthias Versen [:Matti]]

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.

Comment 3

[Johnathan Nightingale [:johnath]]

(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...

Comment 4

[WulfTheSaxon [:Wulf]]

(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.

Comment 5

[(no longer active)]

(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.

Comment 6

[Jed Leahy]

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

Comment 7

[obsolete.fax]

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.

Comment 8

[obsolete.fax]

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

Comment 9

[Matthias Versen [:Matti]]

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.

Comment 10

[WulfTheSaxon [:Wulf]]

(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.

Comment 11

[Gervase Markham [:gerv]]

(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

Comment 12

[Johnny Stenback (:jst)]

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.

Comment 13

[gionnico]

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.

Comment 14

[obsolete.fax]

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

Comment 15

[Robert Kaiser]

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.

Comment 16

[Benjamin Smedberg]

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.

Comment 17

[Steffen Wilberg]

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

Comment 18

[obsolete.fax]

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

Comment 19

[obsolete.fax]

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.

Comment 20

[obsolete.fax]

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.

Comment 21

[Chris Peterson [:cpeterson]]

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

Comment 22

[scientes]

dup of bug 757726

Comment 24

[John Schoenick [:johns]]

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.

Comment 25

[scientes]

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.

Comment 26

[John Schoenick [:johns]]

(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)