On Fingerprinting

At the Mozilla Summit, there was a discussion on browser fingerprinting. After the initial talk given by the session leader, I made the first contribution from the floor; I said “we’re doomed!”.

People are currently arguing for a reduction in the specificity of the information the browser gives out regarding its own version identification (e.g. Gecko date, Gecko revision, Firefox sub-version level.) This information is present in (at least) two places – the User Agent, and various JS properties.

Jesse makes the point that there is a difference between server-side sniffing (done on the basis of the HTTP request) and client-side (done with the benefit of Flash, Java, JS properties and all the other client side info). If the sniffing is done client-side, you can at least see it’s going on by examining the code.

My point: there is no purpose in restricting the client-side availability of detailed version information.

Here’s why. That’s a list of the changes made from Firefox 3.6.5 to 3.6.7. All I have to do to differentiate between these two Firefox versions is to find one of those bugs whose difference in behaviour can be detected by a web page, and write a test. In fact, the Mozilla project may have already done so for me, because code checkins are supposed to come with tests which fail without the patch and pass with it.

There may be a case for restricting what we send to the server to allow it to do server-side sniffing, but there is no point at all in restricting client-side version information. The very nature of different versions means that it’s fairly easy to produce tests which give you exactly the same information.

7 thoughts on “On Fingerprinting

  1. I think there is a difference between capability and broswer version detection and fingerprinting. Yes, tests are available, but if the only bits of information we reveal are ones that determine the point release of the browser, we’ve only released one bit of information. We shouldn’t volunteer huge amounts of information in bundles, as we do presently through mechanisms like the UA. I think your point is valid, but restructuring the UA puts us in a far better position to limit fingerprinting.

    Next up: putting a lid on Flash!

  2. It may not have a purpose to remove some information for fingerprinting but I think making harder to find those kind of information client-side is useful. If it’s hard to detect, it will teach people not to use user agent sniffing to detect functionality.

  3. Also note that as soon as this info is available client-side, those sites that want it server-side will run with an entry page that gets the info from the client side, sends it to the server side to “enter the site” and throw people out of “the site” to the entry page when the info is missing (sessions expiring, JS disabled, etc.).

    I’m not sure that more or less encouraging this behavior makes the web a better place, which we ultimately want, right?

  4. http://panopticlick.eff.org/ has a nice fingerprinting test.

    Looking at the results, I can be singled out of 1,120,656 browsers just because of plugin information, which includes the name, description, version, filename, and mime types.

    As long as we don’t plug that giant hole (bug 566423), the discussion about the user agent is a side issue…

  5. Rik: I think you underestimate people’s ingenuity. If it’s there, they’ll find it. And so if it’s there somewhere, why make it harder to find? And that’s without considering the effect on web compat.

  6. I’m not saying they won’t find a way. But if it’s harder to do UA sniffing, they will use the easier feature checking.

  7. > if it’s harder to do UA sniffing, they will use the easier feature checking

    I’m not sure that’s really relevant to the question of fingerprinting.

    However, there’s a point in the user’s favor that I think may be getting missed.

    Just a moment ago I went through the panopticlick test again, and it told me my browser is totally unique in all the browsers they’ve checked. I know I’ve been through that test before, just a few weeks ago, with this browser. Something changed, I don’t even know what, and as far as they know I’m a different person. My browser version didn’t change at all, but because their fingerprinting goes into insane levels of detail, something *else* that it looks at changed. I do get OS updates from time to time, so it’s possible a plugin got updated that way. Or maybe I installed a font, I don’t remember. Who knows? Could be anything. The fingerprint looks at so much stuff.

    I’m probably not exactly typical, but IMO it raises an interesting point: if a user does upgrades or customizations of any kind, their system’s fingerprint can change. Anyone who does updates or customization regularly will have a constantly changing fingerprint. Even automatic updates can change the fingerprint, and very possibly several different data points at once.

    Users who *don’t* do any upgrades or customizations won’t have a print that’s anywhere near unique in the first place, since their system will still have whatever it had when they bought it. Tracking them by IP address would be more reliable.

    So unless I’m missing something, the fingerprinting is basically only useful for tracking people who do upgrades and customization occasionally but not often.