Consider standardizing/normalizing navigator.plugins (browser fingerprinting)

RESOLVED DUPLICATE of bug 757726

Status

()

RESOLVED DUPLICATE of bug 757726
9 years ago
5 years ago

People

(Reporter: Wulf, Unassigned)

Tracking

({privacy})

unspecified
privacy
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(URL)

(Reporter)

Description

9 years ago
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

9 years ago
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...
(Reporter)

Comment 4

9 years ago
(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.
(Reporter)

Updated

9 years ago
Depends on: 57555

Comment 5

9 years ago
(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.
No longer depends on: 57555
Summary: Consider standardizing/normalizing User Agent, navigator.plugins and font lists when in Private Browsing mode (browser fingerprinting) → Consider standardizing/normalizing navigator.plugins when in Private Browsing mode (browser fingerprinting)

Comment 6

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

Comment 7

9 years ago
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

9 years ago
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.
(Reporter)

Comment 10

9 years ago
(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

Updated

9 years ago
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
Component: Private Browsing → Build Config
QA Contact: private.browsing → build.config
Summary: Consider standardizing/normalizing navigator.plugins when in Private Browsing mode (browser fingerprinting) → Consider standardizing/normalizing navigator.plugins (browser fingerprinting)

Updated

9 years ago
Keywords: privacy
Component: Build Config → Plug-ins
Product: Firefox → Core
QA Contact: build.config → plugins

Updated

9 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

9 years ago
blocking1.9.1: ? → ---
blocking1.9.2: ? → ---
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.
blocking2.0: ? → -

Comment 13

9 years ago
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

9 years ago
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

9 years ago
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.

Comment 17

9 years ago
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

8 years ago
(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

8 years ago
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

8 years ago
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.
Depends on: 602795, 613305
I opened bug 793978 (randomly shuffle navigator.plugins array) as a possible interim fix for plugin fingerprinting.
Depends on: 793978

Comment 22

6 years ago
dup of bug 757726

Updated

6 years ago
Depends on: 757726
Status: NEW → RESOLVED
Last Resolved: 6 years ago
No longer depends on: 757726
Resolution: --- → DUPLICATE
Duplicate 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.

Comment 25

6 years ago
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)
You need to log in before you can comment on or make changes to this bug.