Browser fingerprint protection

General discussion and chat (archived)
Kudalufi

Browser fingerprint protection

Unread post by Kudalufi » 2014-05-03, 19:11

I would like to know what could be done to prevent, or at least mitigate browser fingerprinting. For those that don't know, Javascript is able to read and report back to a web site what plugins you have installed (and in what order they were installed), what system fonts, and other settings like whether or not cookies are enabled, what time zone you are in, user agent, etc. When put together, all this information can almost without fail uniquely identify your computer even if cookies are turned off. Web sites can track you quite easily like this. The list of plugins (with versions and order of installation) and system fonts are especially good ways to identify you. Almost everyone has installed software that adds fonts or added fonts themselves. I have some elvish script fonts that make my computer stick out like a sore thumb. Check out the link above to see how unique your installation is.

I would like to suggest some sort of fingerprint countermeasure mode. Perhaps integrated with private browsing. But since private browsing is generally for the protection against traces on your computer of where you have browsed, not for reducing the trackability of your browser online, I would suggest a separate mode. Anonymous mode. Where the plugin list and system fonts reported by Javascript are normalized, where the user agent string is set to something more generic. For plugins, it will be difficult to normalize the list without breaking Javascript in some cases. But perhaps the plugin list can be sorted alphabetically before Javascript is allowed to iterate it. That way the order of plugin installation cannot be used to identify you. Some plugin identifiers, like the Java ones, give out a lot of system information in them. Perhaps this can be normalized to look more generic in a way that doesn't break things too badly. The system fonts installed can be normalized with little impact. A list of fonts that pretty much every Windows user has can be supplied. Web sites most likely won't be looking for esoteric fonts.

Plugins like Noscript can be used to reduce Javascript's ability to run, but this is a pretty wide scatter shot. I had previously used Noscript for some time and found it hugely intrussive and annoying. Perhaps some less drastic methods can be integrated into the browser?

Supernova

Re: Browser fingerprint protection

Unread post by Supernova » 2014-05-03, 19:31

Firefox 29+ changed the behavior of navigator.plugins to disallow full enumeration of plugins, but instead the website have to ask if a specific plugin is here. While far from solving everything, this is a little progress, and from what I understood Moonchild will back-port this in a later version.
For other measures, well there are progress which may be done but I don't know what are the plans regarding this.

dark_moon

Re: Browser fingerprint protection

Unread post by dark_moon » 2014-05-03, 22:10

The Electronic Frontier Foundation (EFF) plans to stop this fingerprinting with their own (Privacy Badger) addon

Kudalufi

Re: Browser fingerprint protection

Unread post by Kudalufi » 2014-05-03, 23:14

dark_moon wrote:The Electronic Frontier Foundation (EFF) plans to stop this fingerprinting with their own (Privacy Badger) addon
I'm not sure an extension can do effective fingerprint mitigation. I'm not an extension developer, but I don't think an extension can modify the internals of the way javascript iterates fonts, for example. I think browser hardcode support is needed for that.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Browser fingerprint protection

Unread post by Moonchild » 2014-05-04, 00:21

An extension, when properly programmed, will have full control over what is communicated to servers, including HTTP header contents and the likes. It can most certainly be used to tightly control browser-information entropy.

Looking at the impact of removing enumeration (and potential breakage of a lot of websites), I don't want to do this until I'm sure it won't somehow break website plugin detection for a large group of Pale Moon users. Privacy protection is important, but it should not break people's browsing.

Instead, I'll probably add a Durstenfeld shuffle to the plugin list which will randomize the list of enumerated plugins, which, although not mitigating fingerprinting based on exotic plugins, will most definitely throw a spanner in the works for trackers; the fingerprinted list will no longer be uniquely and statically ordered which will make fingerprinting a lot less useful for trackers and will likely count multiple visits from the same browser as unique (breaking the tracking chain and bloating tracking databases with useless data); and at the very least make it impossible to separate individual users from others with the same plugins (they would need to aggregate to counter this measure; I prefer shuffle over sorting, because with sorting you are doing that work for them, and make it easier for them to determine which browsers have mitigated with this method).
Note that this will likely have an adverse effect on "fingerprint checking websites" like panoptick, because the random ordering will make your visit more unique - but a repeat visit will not provide the same fingerprint as your last one. So you keep giving random, new and different fingerprints to websites, and they are left with the task to sift through it. Even if it's not as far reaching as hiding the data, it will definitely make life hell for trackers ;)
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Supernova

Re: Browser fingerprint protection

Unread post by Supernova » 2014-05-04, 00:41

Actually the plugins information transmitted include very precise micro-version number which tend to make configuration unique.

The EFF algorithm sorted the plugins and so lost the order of plugins information, and didn't exploit various holes (outside of plugins) which could have make their algorithm more powerful (because they were unaware of the method or lacked time to implement it), and yet was able to not only identify efficiently people, but to efficiently re-identify them when their fingerprint slightly changed. i.e. ; shuffling plugins order will probably be better than not, however it certainly won't "make life hell for trackers". Sadly.

About enumerate, I understand you may want to avoid functionality break. However with IE which already did that, and with FF29 which now do to, a good chunk of used browser will behave like this so websites will likely have to adapt.

Btw, "allow all cookies" is the default instead of "disable 3rd party cookies" for the same reason of potential functionality break ? Didn't notice any since I changed that but I won't pretend having a representative web usage.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Browser fingerprint protection

Unread post by Moonchild » 2014-05-04, 08:08

You have to understand how fingerprinting works on the server side. It relies on a fingerprint - i.e. something that will not change.
Shuffling the order randomly will not only create new fingerprints and bloat their databases with new entries, it may also invalidate existing fingerprint databases if enough people do this, because it won't be clear which are randomized and which are not, in turn helping everyone else who has been tracked, because the trackers need to use a courser grain.

Sorting, on the other hand, creates patterns that can be used to filter: when you find a sorted list, you know with great certainty the list was sorted as a countermeasure, because nobody will manually install their plugins in a sorted order. Randomized, however, well, good luck trying to figure out which are genuinely installed in that order. Also, sorted lists reduce the number of occurrences of list orders, and randomized increases this number. Randomized definitely makes it a lot more difficult to manage the collected data as a result. You have to make data collection as inconvenient as possible; sorted lists don't (actually the opposite).

So, this does, significantly, mitigate part of the fingerprinting problem (note: part of). I don't understand how others (including EFF?) don't see this. If EFF intends to implement sorting in their badger (it's in Alpha right now?) then they need to get this feedback and consider randomization instead.

Pale Moon will implement this basic mitigation on the short term - if you feel you need more profiling protection, you can extend this with an add-on of your choice. Once impact of empty enumeration tables has been addressed by the vast majority of impacted sites (this may take at least several months if not more), I'll add the necessary code to remove enumeration, if it's still an issue at that time. For now I'll opt to not break websites.

As for MSIE/FF29 parity:
  • FF29 is brand new, meaning this lack of enumeration hasn't been present until now in any Gecko browser. It will need the evangelism team to poke webmasters of now-broken sites. bug #934107
  • MSIE uses a different plugin approach to begin with (AX) and every webmaster is already painfully aware it needs "special treatment" (including those of tracking/profiling websites). I'm not sure if it exposes the plugins a different way or not or if it can be fingerprinted with different parameters.
EDIT: Understand that this is an arms race. Whichever mitigation is used, the trackers will adapt. Even without any useful information from the browser at all, you can still be fingerprinted whenever you connect to the 'net. The thing you need to do is make it difficult (preferably with minimal effort from your side and with minimal impact on usability). Making it impossible is an unrealistic goal.
Instead of trying to reduce unique data, my approach is to increase it, but with the side note that that uniqueness is not reproducible. Compare it with inflatable tanks ;)
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

joiwind

Re: Browser fingerprint protection

Unread post by joiwind » 2014-05-04, 14:56

(Got my Panopticlick result down to one in 16,928 browsers :D )

Supernova

Re: Browser fingerprint protection

Unread post by Supernova » 2014-05-04, 15:11

Moonchild wrote:So, this does, significantly, mitigate part of the fingerprinting problem (note: part of). I don't understand how others (including EFF?) don't see this. If EFF intends to implement sorting in their badger (it's in Alpha right now?) then they need to get this feedback and consider randomization instead.
I think you misunderstood my statement about what EFF did.
It was their fingerprinting algorithm which sorted, i.e. the one who try to identify you when you test yourself on their website. Not any sort of protection user-side.

User avatar
somdcomputerguy
Lunatic
Lunatic
Posts: 381
Joined: 2014-02-23, 17:25
Location: Greenbrier County, West Virginia
Contact:

Re: Browser fingerprint protection

Unread post by somdcomputerguy » 2014-05-04, 16:54

Kudalufi wrote:..Javascript is able to read and report back..
AFAIK, and I'm almost positive, J/S can't 'report' anything back to a server. Maybe with AJAX or something.. But here you are confusing JavaScript with Java, which are two totally separate things.
:cool: -bruce /* somdcomputerguy.com */
'If you change the way you look at things, the things you look at change.'

Supernova

Re: Browser fingerprint protection

Unread post by Supernova » 2014-05-04, 17:37

It's AJAX yes.
Note that there are still way to get info on say fonts without flash or java.

Kudalufi

Re: Browser fingerprint protection

Unread post by Kudalufi » 2014-05-04, 21:33

I was unaware EFF was sorting their list already. In an aside, I did notice certain things were interesting about the list they returned, like the fact that certain plugins (ie Adobe reader) were enumerated twice. In investigating this I learned to my surprise that PM/FF both actively reach out and look for plugins in a bunch of software installation folders, and the fact that PM saw two copies of the Adobe reader plugin in two different subfolders meant it was in the plugin list it sent out twice. Even though they were identical copies of the same dll. For the record, I think actively looking in the directories belonging to other pieces of software for plugins is a really Bad Idea™. This makes it so much harder for users to uninstall a plugin without uninstalling the software the plugin is for. Only plugins registered in the registry should be used.

As far as randomizing the sort order, all the end web site has to do is sort the plugin list themselves. But I like the approach. I had focused on ways to remove entropy in order to make the browsers all the same, but your idea to add more entropy is an excellent approach. Rather than randomizing the sort order, perhaps a bunch of random fake plugins could be added to the list. Also a bunch of random fake fonts. I can't see how this will break legitimate web sites, who will only be looking at installed plugins in order to find whether you have a particular one. They will ignore plugins they don't recognize. The sites that want to use the list of plugins or system fonts you have installed to fingerprint you will have a much tougher time filtering out randomly added fake plugins. It's still not foolproof. If this idea gets implemented and gains traction, then they can simply build lists of valid plugins and fonts and filter out anything it doesn't recognize. But it makes them have to work a lot harder, and is a first step.

I still think the best way to go in the end is a combination approach. Make the real information bland, and the fake information salty. Take a bland list of standard fonts, add in a bunch of random fake fonts, and serve that up. Looking at the Panopticlick test site, though, it seems that they are getting the font information from flash. Which will make it hard for the browser to intervene. And plugins are still troublesome.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Browser fingerprint protection

Unread post by Moonchild » 2014-05-04, 23:15

Kudalufi wrote:As far as randomizing the sort order, all the end web site has to do is sort the plugin list themselves.
Of course they can do that if they wish, but maybe an example makes it clearer.

Say, you have 4 browsers, A, B, C and D. They all have 5 plugins installed, 1 through 5.
With an untouched list, the plugins are presented in the order they were installed in. For example:
A: 1 2 4 3 5
B: 1 4 5 3 2
C: 5 1 2 3 4
D: 1 4 5 3 2
This order is presented the same way each visit. (note that 1 2 3 4 5 is very unlikely to happen)
For a tracker, this means there are 3 plugin fingerprints, A, B+D and C.

If they were to be sorted client-side, then all 4 would have the same fingerprint. This means it's harder to track which is which, so trackers will NOT do this sorting on their end, even if they could; they want as much entropy as possible to pinpoint individuals as accurately as possible, by recording the unique installation order alongside the list of plugins (since most people only use the same small collection of plugins, the order is a very valuable commodity to record).

Playing on this, randomizing the list will serve a dual purpose: by presenting a different order each time, it's unknown which browser is which because A may look like B, and B will no longer look like D. This results in the same "making all 4 look the same" by making the order useless (the same result as if the client would sort the list before presenting it and removing entropy that way).
The second thing it does is make the tracker record entries for every possible combination of 1 through 5 (5! = 120 combinations, if I remember how this works correctly -- it's been 20 years since I did combinations and probability calculation) instead of just 3 in this example, with randomly cross-linked visits of different browsers (A looks like B) and collisions with browsers that do not randomize (always presenting the same list and order), making not only the randomized browser data order useless, but also poisoning recorded data of other browsers that don't mitigate this way. Conversely, presenting a sorted list from the client will immediately pool all "1 2 3 4 5" browsers together, but will not stop trackers from still tracking other browsers that don't mitigate this way and are still "unique". Bloating their databases by a factor 40 (and exponentially more as the number of plugins increases) is a nice bonus ;)
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

opera1215b1748

Re: Browser fingerprint protection

Unread post by opera1215b1748 » 2014-05-05, 06:44

Moonchild wrote:...I'll probably add a Durstenfeld shuffle to the plugin list which will randomize the list of enumerated plugins, which, although not mitigating fingerprinting based on exotic plugins, will most definitely throw a spanner in the works for trackers...
+1

opera1215b1748

Re: Browser fingerprint protection

Unread post by opera1215b1748 » 2014-05-05, 06:52

Moonchild wrote: ...Pale Moon will implement this basic mitigation on the short term - if you feel you need more profiling protection, you can extend this with an add-on of your choice.
+1
It would be nice to have a list of all/many plug-ins to throw at them - 99.999% of that number to be dummy plug-ins/add-ons (not actually present).
A user should be able to trim the number of dummy plug-ins to hide his real ones among them.
(i.e. to show an "x plugins from the total of y theoretically existing". The "x'" number could also be randomly varying - between the actual number of installed add-ons and some ceiling value.)

MIT_kendal

Re: Browser fingerprint protection

Unread post by MIT_kendal » 2014-09-16, 11:51

@opera1215b1748 - that's a great idea. Get a list of a 10,000 font names and 1000 plugins, and, each time we visit a site that is fingerprinting us we throw at them some random subset of that list in arbitrary order. That will surely increase their storage requirements.
opera1215b1748 wrote:
Moonchild wrote: ...Pale Moon will implement this basic mitigation on the short term - if you feel you need more profiling protection, you can extend this with an add-on of your choice.
+1
It would be nice to have a list of all/many plug-ins to throw at them - 99.999% of that number to be dummy plug-ins/add-ons (not actually present).
A user should be able to trim the number of dummy plug-ins to hide his real ones among them.
(i.e. to show an "x plugins from the total of y theoretically existing". The "x'" number could also be randomly varying - between the actual number of installed add-ons and some ceiling value.)

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35476
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Browser fingerprint protection

Unread post by Moonchild » 2014-09-16, 21:10

You know this is the kind of thing that's perfect to put into an extension ;)
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

MIT_kendal

Re: Browser fingerprint protection

Unread post by MIT_kendal » 2014-09-16, 22:09

Moonchild wrote:You know this is the kind of thing that's perfect to put into an extension ;)
Do you know of an open source extension that's already talking to the right bits of the Pale Moon API? that would be very helpful. Also - I didn't know extensions have permission to modify http headers on packets not originating from them.

User avatar
Antonius32
Add-ons Team
Add-ons Team
Posts: 695
Joined: 2014-05-25, 11:18
Location: Netherlands

Re: Browser fingerprint protection

Unread post by Antonius32 » 2014-10-11, 21:30

Just a quick question: does browser fingerprinting apply to plugins only, or does it apply to extensions, themes, dictionaries and language packs as well?

Supernova

Re: Browser fingerprint protection

Unread post by Supernova » 2014-10-11, 21:49

Only plugins version are reported when a website ask enumeration.
Some addons may be detected by the website you visit if they directly interact with it (think to adblockers, which leaded to counter scripts and counter counter scripts), but it remains unlikely and they won't know directly what you use - they'll just be able to try a guess. In general, apart the addons who need to contact another website to work, and so allow that 3rd party to track you (I think to some translate addons, there are certainly other cases), and the ones with malicious code, there should be no tracking issue for using an extension.

Locked