Opened 9 months ago

Closed 9 months ago

Last modified 7 months ago

#28740 closed defect (fixed)

Make navigator.platform return "Win32", even on Win64 OS

Reported by: omg Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: GeorgKoppen201812, TorBrowserTeam201812R, tbb-backported
Cc: mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Child Tickets

Change History (8)

comment:1 Changed 9 months ago by gk

Cc: mcs brade added
Keywords: GeorgKoppen201812 TorBrowserTeam201812R added
Status: newneeds_review

So, not sending "Win32" here risks websites breaking. Thus, let's backport that patch then. bug_28740 (https://gitweb.torproject.org/user/gk/tor-browser.git/commit/?h=bug_28740&id=a3cbc068df86e03a6420bc863be2793e35078fa3) is up for review (the patch applied cleanly).

Last edited 9 months ago by gk (previous) (diff)

comment:2 Changed 9 months ago by omg

Also you use Mozilla's JS spoofing

  win: "Windows NT 6.1; Win64; x64",

and UA Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0.
Spoofing Windows NT 6.1 without Win64; x64 looks better for compatibility.

comment:3 Changed 9 months ago by mcs

r=brade, r=mcs
Matching the value returned by recent versions of Firefox (as well as Chrome and Edge) seems like a good idea.

comment:4 Changed 9 months ago by gk

Keywords: tbb-backport added
Resolution: fixed
Status: needs_reviewclosed

Thanks. Merged to tor-browser-60.3.0esr-8.5-1 (commit a3cbc068df86e03a6420bc863be2793e35078fa3). Marking for possible backport.

comment:5 in reply to:  3 Changed 9 months ago by Thorin

Replying to mcs:

r=brade, r=mcs
Matching the value returned by recent versions of Firefox...

Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1401493 I ran some tests (Windows). The platform difference was already noted. Note: this is not (for me at least) about blending TB users with FF RFP users, but ultimately about making sure that Tor Uplift patches came thru unscathed (and that includes relaxing prefs used in the past or still used in v8* that are now covered by RFP)

Anyway, just FYI, if you didn't want to wait until the next ESR cycle, standardizing the buildId could be a good patch to backport: hardcoding 20181001000000 rather than relying on a pref and using 20100101. - see https://bugzilla.mozilla.org/show_bug.cgi?id=583181

Up to you guys :) Not backporting it doesn't harm Tor Browser's FP'ing entropy

comment:6 Changed 9 months ago by Thorin

I ran some tests (Windows). Gee, forgot to give you the link (includes lots of pretty pictures). There may some other things in there that stick out for you (e.g Pointer Events you already covered)

comment:7 in reply to:  2 Changed 8 months ago by omg

Replying to omg:

Also you use Mozilla's JS spoofing

  win: "Windows NT 6.1; Win64; x64",

and UA Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0.
Spoofing Windows NT 6.1 without Win64; x64 looks better for compatibility.

Anyway, we should be consistent in either 32-bit or 64-bit browser we impersonate.

comment:8 Changed 7 months ago by gk

Keywords: tbb-backported added; tbb-backport removed

commit a102f8b853fb04db32bcd0f924fd6391cd3d40da on tor-browser-60.4.0esr-8.0-1 has the backport for the 8.0 series.

Note: See TracTickets for help on using tickets.