Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fingerprinting 2.0: User Agent - follow up to #12097 #12638

Closed
srirambv opened this issue Nov 11, 2020 · 18 comments · Fixed by brave/brave-core#7200
Closed

Fingerprinting 2.0: User Agent - follow up to #12097 #12638

srirambv opened this issue Nov 11, 2020 · 18 comments · Fixed by brave/brave-core#7200
Assignees
Labels
feature/shields/fingerprint The fingerprinting (aka: "device recognition") protection provided in Shields OS/Android Fixes related to Android browser functionality privacy privacy-pod Feature work for the Privacy & Web Compatibility pod QA Pass - Android ARM QA Pass - Android Tab QA/Yes release-notes/include

Comments

@srirambv
Copy link
Contributor

Description

[Follow up to #12097]

Test plan for both Desktop and Android (per #9190 (comment)):

per @pes10k comment:
i've added a user-agent row to https://dev-pages.brave.software/farbling.html

Things to check:

  1. using an android device, hit the "generate fingerprints" button, then click on one of the hash values in that row and make sure that in the popup it says "android device" and not any particular device model
  2. in "strict" blocking, you should get different fingerprints across top-level origins and sessions (there aren't a huge number of possible random values here, so if you see an identical fingerprint (for the user-agent row only), its worth checking on the sibling page or on another session to see if you get another fingerprint then)

Original issue description

This is a sub-issue of the larger fingerprint defense reorganization issue: #8787

User Agent String

NavigatorID.userAgent

default protections:

  • for devices with OS version numbers, always report MAX(current minor version number, latest version number as of build)
  • (only for android) don't report device name in UA, only return "android device" (same as what DDG browser does)

max protections:

  • return chrome default UA for each platform
  • At end of UA, add [0, 5] additional whitespace characters, as determined by eTLD+1 seed (only for JS reflected value)

(other notes for future consideration)
In default mode, we could probably get by safely with adding [0, 5] additional whitespace characters, as determined by eTLD+1 seed (only for JS reflected value), but for the first time out, lets be very very conservative with the UA and not make any "clever" changes like that.

Also, we could probably get by with adding [0, 3] additional whitespace characters between UA segments, but again, for the first change, lets be conservative.

@srirambv
Copy link
Contributor Author

srirambv commented Jan 26, 2021

Verification passed on OnePlus 6T with Android 10 running 1.20.85 x64 Beta Build


Verification passed on Samsung Tab A with Android 10 running 1.20.85 x64 Beta Build

@ristein
Copy link

ristein commented Feb 4, 2021

could someone name an ETA for the UA not containing device name anymore in playstore version?
This issue is around for so long and doesn't fit at all to a privacy focused browser.

@pes10k
Copy link
Contributor

pes10k commented Feb 4, 2021

It'll be in release 1.20, which is the current beta release, and the next stable release

@ristein
Copy link

ristein commented Feb 14, 2021

Hey, I just installed the new Version and it works very well. Thank you very much.
No more sending device model in UA

@tjm00
Copy link

tjm00 commented Mar 9, 2021

I just checked my user agent via DDG and it is reporting my exact device. I am using version 1.21.74 on Android from the Play store..

@pes10k
Copy link
Contributor

pes10k commented Mar 9, 2021

@pilgrim-brave @anthonypkeane did we he hit a bug and mobile / android UA stuff regressed?

@ristein
Copy link

ristein commented Mar 12, 2021

I just updated to Version 1.21.76 and my device model is back in the user agent, unlike to how it was on versions 1.20

@pes10k
Copy link
Contributor

pes10k commented Mar 15, 2021

Thanks for the comment @ristein @tjm00 . I've captured it in a follow up issue here that we'll get sorted out ASAP. Thank you all again for letting us know!

@ristein
Copy link

ristein commented Mar 20, 2021

update to 1.21.77 doesnt resolve this issue...

@tjm00
Copy link

tjm00 commented Mar 21, 2021

The issue that was opened is #14740. It doesn't appear that there has been any work on it yet.

@pes10k
Copy link
Contributor

pes10k commented Mar 21, 2021

Yes, we are tracking the issue, and will get it fixed as soon as we finish up the current round of features / development

@GrahamboJangles
Copy link

GrahamboJangles commented Jul 16, 2022

So what happened to this issue? It is still a problem.

@pes10k
Copy link
Contributor

pes10k commented Jul 16, 2022

The issue was fixed in this PR brave/brave-core#8320

@GrahamboJangles
Copy link

GrahamboJangles commented Jul 18, 2022

@pes10k The issue of unique User Agents still persists. Visit amiunique.org, the user agent and content language are incredibly identifying, everything I've tried results in a unique fingerprint.

@pes10k
Copy link
Contributor

pes10k commented Jul 22, 2022

I appreciate the concern, but these are not in practice threats to your privacy, for three reasons

  1. The user agent value is identifying as an artifact of how the site calculates the similarity %. Since the user agent will always be changing for all browsers (bc version numbers increase), any particular UA is going to be a very small % of all user agent strings the site has seen over the entire history of the project. For a more useful measurement here, it would be better if the site just calculated the similarity % over recently submitted UAs (since this is who fingerprinters would be trying to match you against).

  2. for the content language header, we intentionally randomize this, which (by design) will make you look unique. The important part is that it will make you look differently unique to different sites. You can find more informaiton about this here: https://brave.com/privacy-updates/17-language-fingerprinting/

  3. As with all fingerprinting measurements, what matters in practice is not any specific attribute, but the combination of many different attributes. Here again Brave provides extremely strong (and in most cases, best in class) protections, because of how we randomize a large number of inputs to the browser fingerprint. More info here https://brave.com/privacy-updates/4-fingerprinting-defenses-2.0/

For other, more accurate measures of how fingerprintable you are, I recommend the excellent creepjs site (https://abrahamjuliot.github.io/creepjs/). As you'll see, they report they are able to fingerprint brave with 0% confidence (the "trust score"), despite the sophistication and breath of the fingerprinting techniques they use. The EFF's CoverYourTrack's project also gives an accurate measurement of how fingerprintable Brave is in practice (https://coveryourtracks.eff.org/)

Hope this helps

@GrahamboJangles
Copy link

@pes10k why go through all the trouble of randomizing the content language header and possibly even the agent string when you could just make every Brave users content language header and agent string the same? That is the ultimate anonymity, appearing as everyone else.

@pes10k
Copy link
Contributor

pes10k commented Jul 26, 2022

We randomize because every attribute we randomize (without breaking things) provides some umbrella protection over the fingerprinting inputs we can't randomize (w/o breaking things). The blog posts i linked to above explains the rational in more detail.

Also as those blog posts note, if we can get a fingerprint to consume a randomized (or "poisoned") input, then that provides much stronger protections than a "make everyone look the same" approach, since it means we can force a different fingerprint on each site and / or session. Again the blog post says more.

Finally, for these specific inputs (content language and user agent string), we can't make these specific values the same for everyone without breaking some sites for users; there are sites that use those values for user serving purposes too. Even though we can't make them fixed values, we can (in some cases) add just enough randomness to break the fingerprinter scripts (by rotating fingerprints) but also maintain the user-benefical distinguishing information in the inputs

@GrahamboJangles
Copy link

@pes10k I see. Thank you for your responses and your effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature/shields/fingerprint The fingerprinting (aka: "device recognition") protection provided in Shields OS/Android Fixes related to Android browser functionality privacy privacy-pod Feature work for the Privacy & Web Compatibility pod QA Pass - Android ARM QA Pass - Android Tab QA/Yes release-notes/include
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants