793978 - Sort navigator.plugins array to avoid exposing user-identifying plugin file order

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Chris Peterson [:cpeterson]]

Attachment: shuffle-plugin-array.patch

User-tracking software can fingerprint users based on the set of plugins they have installed, among other characteristics. As detailed in Jonathan Mayer's thesis [1] (page 32), Gecko and WebKit sort the navigator.plugins array by the plugins' "last modified" time. Users with the same plugins installed can still have unique fingerprints because it is extremely unlikely that they installed their plugins in the same order.

My patch randomly shuffles the navigator.plugins array (and, as a convenient side effect, navigator.mimeTypes, too). This avoids exposing a unique, stable ordering to web content. Tracking software will need to sort the plugin array to generate stable fingerprints, throwing away lots of identifying data. Naive tracking software may think every random shuffle order is a new user.

This patch ONLY affects the navigator.plugins API and does NOT change nsPluginHost's internal plugin ordering. This patch is just a band-aid fix until enumeration of the navigator.plugins array is disallowed (bug 757726).

[1] https://www.stanford.edu/~jmayer/papers/thesis09.pdf

Comment 1

[scientes]

I opened the bug about disallowing enumeration, and I do not find the rationale behind this patch sufficient. Why do something half-ass when there exists examples of the full implementation (such as internet explorer), and the route to that implementation is straight-forward and relatively short?

Not that doing a shuffle doesn't theoretically reduce measurable entropy, its just that having esoteric plugins is in itself a vastly larger entropy leak, and I think makes this suggested patch insignificant in comparison. (it is also not complementary)

Comment 2

[Ben Bucksch (:BenB)]

Chris, good thinking/idea, and impl, appreciated. But like scientes, I see no reason to not just fix bug 566423 now. Just one plugin on an uncommon platform together with other factors can be enough to single out a user.

Comment 3

[Benjamin Smedberg]

The additional entropy from the ordering by last-modified is interesting, but I don't think it's worth the additional complexity here.

Comment 4

[Chris Peterson [:cpeterson]]

Comment on attachment 664382 [details] [diff] [review]
shuffle-plugin-array.patch

Thanks for the feedback. That's a fair assessment.

I proposed this as an interim fix because bug 757726 has a number of dependencies that may take a while to solve (like plugincheck). Today, even users with non-esoteric plugins can be divided into N! subgroups by their plugin ordering.

Comment 5

[Chris Peterson [:cpeterson]]

Attachment: shuffle-plugin-array-v2.patch

bsmedberg: since disallowing plugin enumeration (bug 757726) is not practical, would you reconsider this patch to randomize the enumeration order of navigator.plugins?

Comment 6

[Dave Garrett]

Randomization is overkill. Just alphabetizing the list is enough to get rid of this entropy.

Comment 7

[Chris Peterson [:cpeterson]]

Shuffling the list is O(n). Alphabetizing the list is O(n log(n)). Also, if a tracker doesn't sort the plugin list itself, each random permutation of the list will produce a different fingerprint hash.

Comment 8

[Dave Garrett]

(In reply to Chris Peterson (:cpeterson) from comment #7)
> Shuffling the list is O(n). Alphabetizing the list is O(n log(n)).

True, but there aren't going to be enough plugins to worry about perf here, even on mobile (which isn't going to have many plugins).

> Also, if a tracker doesn't sort the plugin list itself, each random
> permutation of the list will produce a different fingerprint hash.

That's actually bad. This means that navigator.plugins will have a unique fingerprint for each Firefox session. Each users' different randomization could identify it just as easily as their natively ordered list, at least within the session. You would need to randomize on every single navigator.plugins call to fully fix the issue. nsPluginArray::EnsurePlugins() just returns early if mPlugins is non-empty, so you're only randomizing once in the current patch. If you alphabetize instead, you get rid of the entropy issue without having to do any further rearranging. With alphabetization, all users with the same plugin set have the same navigator.plugins.

Comment 9

[Dave Garrett]

(correction: not necessarily unique fingerprint w/ low number of plugins, of course, but more identifying than would be the case otherwise)

Comment 10

[Chris Peterson [:cpeterson]]

(In reply to Dave Garrett from comment #8)
> > Also, if a tracker doesn't sort the plugin list itself, each random
> > permutation of the list will produce a different fingerprint hash.
> 
> That's actually bad. This means that navigator.plugins will have a unique
> fingerprint for each Firefox session. Each users' different randomization
> could identify it just as easily as their natively ordered list, at least
> within the session.

That is a good point. The current patch has a different (but stable) random order for each tab.

Comment 11

[Dave Garrett]

(In reply to Chris Peterson (:cpeterson) from comment #10)
> That is a good point. The current patch has a different (but stable) random
> order for each tab.

Ah, it looks like a whole new nsPluginArray & Navigator created for every nsGlobalWindow. (took me a bit to follow up the code path all the way up to the window itself) If so, then that does work. Sorting in the plugin host would avoid the need to reorder for each created nsPluginArray, but as I said, perf shouldn't be a problem here. In that case, I still say this route is overkill, however I don't see it introducing its own entropy then. (unless nsGlobalWindow aren't guaranteed to be created for every new page)

Comment 12

[Dave Garrett]

Well, to be pedantic there's fingerprintability within the context of the current content window, but it's not a problem as obviously any script there should be able to identify its own context by whatever values it sets already.

(sorry for the excessive comment number; when attempting to talk about entropy I find you really need to be precise to avoid confusing yourself and others ;)

Comment 13

[Chris Peterson [:cpeterson]]

Attachment: alphabetize-plugin-array.patch

Alphabetize navigator.plugins array by name, as recommended by Dave Garrett.

Comment 14

[Chris Peterson [:cpeterson]]

Attachment: alphabetize-plugin-array-v2.patch

Alphabetize both navigator.plugins and navigator.mimeTypes.

(Sorry for all the review bugmail spam!)

Comment 15

[Benjamin Smedberg]

Comment on attachment 8474276 [details] [diff] [review]
alphabetize-plugin-array-v2.patch

It's weird having global operator< for a nsRefPtr type, but writing a Comparator class is a PITA so I think this is ok.

Comment 16

[Chris Peterson [:cpeterson]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c9d1c9fb5ee6

Comment 17

[Georg Fritzsche [:gfritzsche]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #15)
> It's weird having global operator< for a nsRefPtr type, but writing a
> Comparator class is a PITA so I think this is ok.

It's just a trivial class with a LessThan() and Equals() method [0], or am i missing something here?
Is there something usability-wise that should be fixed? The requirement for an Equals() method could be trivially dropped.

[0] http://hg.mozilla.org/mozilla-central/annotate/111a1da2a95d/xpcom/glue/nsTArray.h#l1540

Comment 18

[Benjamin Smedberg]

It just reeks of Java, that's all.

Comment 19

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c9d1c9fb5ee6