Browser fingerprint is unique

[sidstamm]

I know it's early, but this might be a good time to think about uniqueness of browser fingerprint. I ran brave through http://panopticlick.eff.org and it came up very unique. The user agent was most identifying. It would be really cool if we could reduce the entropy here.

Raw copy/paste from the web site (sorry it is not tabular):
Browser Characteristic bits of identifying information one in x browsers have this value value
Limited supercookie test
0.83
1.77
DOM localStorage: Yes, DOM sessionStorage: Yes, IE userData: No
Hash of canvas fingerprint
N/A
N/A
9e8a7569169de5fc7a07a3637e6d8d8a
Screen Size and Color Depth
3.45
10.96
1920x1080x24
Browser Plugin Details
3.17
8.98
undefined
Time Zone
3.69
12.9
300
DNT Header Enabled?
N/A
N/A
False
HTTP_ACCEPT Headers
N/A
N/A
text/html, /; q=0.01 gzip, deflate en-US
Hash of WebGL fingerprint
N/A
N/A
2494f33d4be800b9f6d5032548ac0d2c
Language
N/A
N/A
en-US
System Fonts
N/A
N/A
Arial, Courier, Courier New, Helvetica, Times, Times New Roman, Wingdings 2, Wingdings 3 (via javascript)
Platform
N/A
N/A
Linux x86_64
User Agent
21.6
3189530.5
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) brave/0.7.7 Chrome/47.0.2526.73 Electron/0.36.2 Safari/537.36
Touch Support
N/A
N/A
Max touchpoints: 0; TouchEvent supported: false; onTouchStart supported: false
Are Cookies Enabled?
0.42
1.34
Yes

[sidstamm]

cc @diracdeltas

[diracdeltas]

@sidstamm great catch, thanks for checking. putting the easy-to-reduce parts of this fingerprinting surface on my 0.8 list.

[illuzen]

Came here to post this. +1

[Hainish]

👍

[diracdeltas]

What happens if we take Brave out of the user-agent for 0.8 while our user set is small enough to be highly identifiable? Any thoughts @bbondy?

[bbondy]

I'd be fine with that, maybe a very temporary problem though? (hopefully?:))

[diracdeltas]

I tried taking Brave out of the UA in https://github.com/brave/browser-laptop/tree/fix/fingerprinting; however, that change made the browser more fingerprintable according to panopticlick, not less.

Before:

After:

This may be because Electron is using an outdated/unusual version of Chrome. My regular Chrome UA string is Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 vs Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.110 Safari/537.36 for Brave.

[diracdeltas]

Now that we updated to Chrome 49, 327fcc7 reduces the entropy score by a few bits. There are several other ways we can reach fingerprint parity with chrome which i'll work on

we are already winning on Browser Plugins because we don't have any plugins, yay.

[diracdeltas]

Good news, we now score better than Chrome latest stable (in a fresh browser profile, default settings, incognito mode) on the Panopticlick fingerprinting test. Probably in part due to me doing the Panopticlick test repeatedly in Brave. ;)

Chrome:

Brave:

[sidstamm]

This is great, thanks for taking this on! Since the UA fix requires one of two things: Lots of Brave users with the same UA string, or other browsers to reduce bits in the UA... I think that's probably not easily reducible in the short term.

I wonder if reducing the canvas hash uniqueness is a particularly difficult fix (I haven't looked into anything about it, though seems like a potential zero-sum perf/privacy tradeoff).

[weems]

Seems at this time Brave 0.8.3 is completely unique ("Your browser fingerprint appears to be unique among the 137,149 tested so far."). I would like to learn more about how this is exploited. System Fonts in Chrome 49 reveals 17.07 bits of information, in Brave 0.8.3 for System Fonts the test states 13.74 bits of information is exfiltrated by the browser fingerprinting exploit. Interesting that as of 0.8.3 we already show less font info than Chrome, it should be increased, but limiting the UA will definitely make Brave more secure relative to the agents of other browsers. But the goal seems to be security in obscurity, right? I am also interested in why we reveal Mozilla, Chrome, and Safari? Perhaps the Safari is there because I am on MacIntel.

[diracdeltas]

This is great, thanks for taking this on! Since the UA fix requires one of two things: Lots of Brave users with the same UA string, or other browsers to reduce bits in the UA... I think that's probably not easily reducible in the short term.

The UA fix as currently implemented in 0.9.0 makes us look like a somewhat out-of-date chrome user. However, brian is working on updating the chromium point release, so we will hopefully just look like a regular chrome user.

Re: canvas fix, i hope to block 3rd party canvas writes with sufficiently-high entropy and prompt for permission on first-party canvas writes like tor browser does.

[diracdeltas]

Here are the results with #1354 applied. Note that the WebGL fingerprint is 'undetermined', which is apparently not a common value (so the entropy count goes up). But at least all Brave users will have the same value.

[bbondy]

Maybe we should close in favour of more specific tasks now that we have canvas and webgl fingerprint blocking and the same UA as Chrome?

[illuzen]

Yeah I wouldn't over-index on this.

As far as "security thru obscurity" goes, the relevant keywords here are "anonymity set". Maximal entropy is attained with the uniform distribution, which is perfectly symmetric. I think the overall goal should be to make Brave users look very similar to each other, not to make them look similar to Chrome users. Plan for success.

[diracdeltas]

Agree on closing this, even though panopticlick will still sometimes show our users as "unique" depending on their system until there are a lot more Brave users who are testing themselves on panopticlick. Specific follow-up tasks like #260 are welcome.

[luixxiul]

On Tor browser you get a273d6a847f0e2a57fa0161158f12fed, whose score seems to be better than ours.

On Tor browser:

On Brave:

Should we update ours?