Closed Bug 1727775 Opened 4 years ago Closed 4 months ago

[android] RFP userAgent vs Desktop Mode

Categories

(Core :: DOM: Security, enhancement, P5)

Firefox 91
enhancement

Tracking

()

RESOLVED FIXED
140 Branch
Tracking Status
firefox140 --- fixed

People

(Reporter: thorin, Assigned: fkilic)

References

Details

(Whiteboard: [fingerprinting][domsecurity-backlog3])

Attachments

(1 file, 2 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Test: https://arkenfox.github.io/TZP/tzp.html#useragent
Client: Android

pics to follow

STR1

  • RFP off (I used FF91)
  • load test with desktop mode = off
  • everything should match
  • flip desktop mode on (page should auto-reload)
  • not the issue: workers don't match
  • not the issue: the desktop userAgent string does not match the expected format for android (and technically, you are lying), so congrats, you get a pinnochio

STR2:

  • RFP on (I used Nightly 93)
  • repeat test
  • not the issue: with desktop mode off
    • everything matches
    • the green colored v91.0 are just the test saying that we know you're lying (and are really v93, via feature detection), the hashes are always exactly what the client reported - i.e we bypassed your sneaky lies and recorded the real value in the fingerprint
  • with desktop mode on
    • most workers don't match (RFP still protects the web worker) which is a little different from when RFP = off

STR3

  • Tor Browser
  • repeat test
  • different to RFP in Firefox: the web worker doesn't match (and service workers are not available)

So the questions are

  • do we want to make all methods return the same desktop string when in desktop mode
  • is the userAgent for all android users in desktop mode the same? i.e no entropy when used by that set?
  • when RFP is on, is this a "leak" that should be patched? Which would make RFP users unable to request desktop mode
  • why is TB different to FF re web worker

Also, I am not a very big android user, but how sticky is the desktop mode. I see there is a toggle, but is that global or per site?

Component: Untriaged → DOM: Security
Product: Firefox → Core
Attached image RFP-off-FF91.png (obsolete) —
Attached image RFP-on-FF93.png (obsolete) —

STR2 ... most workers don't match (RFP still protects the web worker) which is a little different from when RFP = off

Sorry, got that back to front. Just look at the two pictures above, right hand sides. And TB is identical to RFP

Priority: -- → P5
Whiteboard: [fingerprinting][domsecurity-backlog3]

pinging myself as a reminder to revisit and retest that nothing is leaked when flipping desktop modes - also given some devices are looking at permanent desktop mode (tablets? foldables?)

Flags: needinfo?(thorin)
Flags: needinfo?(thorin)
See Also: → default-desktop-mode
Flags: needinfo?(thorin)
Attachment #9238182 - Attachment is obsolete: true
Flags: needinfo?(thorin)
Attachment #9238183 - Attachment is obsolete: true

This is about toggling desktop-mode on. Starting in desktop mode clearly adds entropy, but is a different topic for another rainy day.

note

  • these values (RFP values shown) do not change, only userAgent and HTTP Header do
    • appVersion: 5.0 (Android 10) | oscpu: Linux armv81 | platform: Linux armv81
  • header always matches JS userAgent

tests

  • userAgent: Mozilla/5.0 (Android 10; Mobile; rv:136.0) Gecko/136.0 Firefox/136.0 // RFP
  • userAgent: Mozilla/5.0 (X11; Linux x86_64; rv:136.0) Gecko/20100101 Firefox/136.0 // desktop mode with and without RFP
  • userAgent: Mozilla/5.0 (X11; Linux x86_64; rv:136.0) Gecko/20100101 Firefox/136.0 // RFP linux

So far so good. desktop mode on android happens to match RFP linux, but that may be sheer luck - I'm only testing a single phone (maybe it has entropy). I think we want to ensure (i.e code with existing RFPTargets) so RFP = enabled, the values for userAgent (both js and header) in desktop mode always return the corresponding RFP values for linux. This way there are no surprises in the future.

ni fkilic, pierov for their thoughts, tjr feel free to pipe up

Flags: needinfo?(pierov)
Flags: needinfo?(fkilic)

(In reply to Thorin [:thorin] from comment #5)

So far so good. desktop mode on android happens to match RFP linux, but that may be sheer luck

It seems it is...
https://searchfox.org/mozilla-central/rev/206eaea9a2fd4307da16e1614cd934920368165a/mobile/shared/modules/geckoview/GeckoViewSettings.sys.mjs#19-24

nsRFPService::GetSpoofedUserAgent contains some build time checks for Android, which should be converted to runtime checks if we wanted to make sure the code to set a spoofed user agent is in only one place, at least for RFP.
Also, this would need a refactor on the Android side, I don't know how big.

Finally, notice there's also a VR mode, but I don't know if it's used.
However, I don't know if VR can be ever made RFP.

Flags: needinfo?(pierov)

I think VR or XR or whatever it's called these days is abandonware - it's all disabled on all platforms

It seems it is...
https://searchfox.org/mozilla-central/rev/206eaea9a2fd4307da16e1614cd934920368165a/mobile/shared/modules/geckoview/GeckoViewSettings.sys.mjs#19-24

Hmm it seems like it. I have been working on android stuff recently, I'll take a look sometime

and yeah I also agree rfp and desktop mode should match (without any suprises)

Flags: needinfo?(fkilic)
Assignee: nobody → fkilic
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by fkilic@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/89e3c7ade6ee Spoof the user agent if RFP target is enabled. r=tjr,geckoview-reviewers,ohall
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 140 Branch
QA Whiteboard: [qa-triage-done-c141/b140]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: