Fingerprinting 2.0: User Agent

[pes10k]

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.

[Madis0]

The easiest and most private way to do this would be simply enabling chrome://flags/#freeze-user-agent for everyone (no toggle needed), because Google is already working on this.
See:

• https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/-2JIRNMWJ7s/yHe4tQNLCgAJ
• https://bugs.chromium.org/p/chromium/issues/detail?id=955620
• https://www.chromestatus.com/feature/5704553745874944

[pes10k]

@Madis0 yep, thats referenced in the max protections section. But we'll break sites if we turn that on (UA stuff is shockingly fickle), especially w/ mobile. So we need to wait for Chrome to nudge everyone to not be dependent on UA for us before we can switch over, and just need something in the meantime.

Also, once that ships, well need to move these changes into CH-UA fields, which are going to mirror most of the same info

[Madis0]

Fair enough, reporting old version of Chrome (like the flag does on M81 and before) might not be the best and reporting major with zeroes (like the flag does on M83 and up) might not be the best yet, as most Chrome versions don't have zeroes on minor versions.

But in terms of mobile, least Brave can do is report all devices to be not "android device", as it seems quite uncommon, but rather Linux; Android 9; Unspecified Device as seen from the flag.

[Miyayes]

+1 https://www.reddit.com/r/brave_browser/comments/hyzpab/brave_should_not_provide_our_exact_phone_model_to/

Brave should not provide our exact phone model to every website we visit. OS version is more than enough.
Honestly, why isn't this part of fingerprinting protection?

Instead of giving the user agent - 'Pixel 2XL on Android 10' just give the website 'Android 10'

[gpdevsoft]

@Madis0 yep, thats referenced in the max protections section. But we'll break sites if we turn that on (UA stuff is shockingly fickle), especially w/ mobile. So we need to wait for Chrome to nudge everyone to not be dependent on UA for us before we can switch over, and just need something in the meantime.

Also, once that ships, well need to move these changes into CH-UA fields, which are going to mirror most of the same info

i have enabled chrome://flags/#freeze-user-agent in brave 1.11.105 for android (stable version) and brave 1.11.104 desktop (stable version) i haven't any problems yet...

[LaurenWags]

@pes10k @pilgrim-brave could you please provide a test plan for this issue? Marking as QA/Blocked until we have one, thanks!

[pes10k]

@LaurenWags 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)

@pilgrim-brave it looks like there is a bug, with remote frames not getting the same farbled user-agent as the top level frame.

[LaurenWags]

@pes10k thanks for adding that. I noticed on the test pages that Version for User Agent is 1.17.x, does that mean that this issue was mistakenly put in the wrong milestone (1.16.x)? or did this code actually land in 1.16.x and it's broken there? Just trying to sort out where we should actually test this issue.

[pes10k]

@pilgrim-brave will the fixes for #12020 be uplifted?

[pilgrim-brave]

I discussed that with @bbondy and we agree that it should not be uplifted.

[pes10k]

Sounds good, thanks @pilgrim-brave .

@LaurenWags I believe that means that there are at least some aspects of this issue that won't be addressed until 1.17, so I think its best to treat the issue as not fully complete until 1.17 (I believe there are additional changes incoming too).

I just moved to the 1.17 milestone. Hope that helps!

[LaurenWags]

@pes10k thanks for following up on this one! Usually we don't move issues that have code PR'd against them, so I've moved this issue back to the milestone where the code landed (1.16.x), marked as QA/No and release-notes/exclude.

However, to ensure this issue gets checked, I've logged a testing placeholder issue, #12097, put that in the 1.17.x milestone, and labeled as QA/Yes and release-notes/include.

Please do review and let me know if anything looks amiss.