Open Bug 1556223 Opened 5 years ago Updated 9 days ago

Remove CPU architecture from the Windows and Unix User-Agent strings and navigator APIs

Categories

(Core :: Networking: HTTP, task, P3)

Unspecified
All
task

Tracking

()

Tracking Status
firefox-esr60 --- wontfix
firefox67 --- wontfix
firefox67.0.1 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix

People

(Reporter: cpeterson, Assigned: cpeterson)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, site-compat, Whiteboard: [necko-triaged])

Attachments

(5 obsolete files)

I propose that Win64 and WOW64 Firefox use the unadorned Windows User-Agent already used by Firefox on x86 and AArch64 Windows. The primary use case for including CPU architecture and OS version in the User-Agent string is to allow software download sites to offer compatible software. If a site doesn't see "Win64" or "WOW64" in the User-Agent string, it might serve a Win32 x86 executable to a Win64 OS user. The x86 executable would still be compatible, just not optimal.

Linux users are unlikely to download much software from sites that sniff their CPU architecture, so omitting it should be safe (or if a CPU architecture token is needed for User-Agent parsing webcompat, we could spoof "i686" or simply "CPU" like iOS Safari).

I propose no change to the macOS User-Agent string at this time. Removing "Intel" now would not reduce any fingerprinting entropy (all modern Macs are x86_64) and might risk confusing some User-Agent string parsers. If AArch64 MacBooks become a thing, I propose we then omit CPU architecture on both x86_64 and AArch64 macOS.

The patches in this bug remove the CPU architecture from:

  • Windows' and Unix's User-Agent HTTP header
  • Windows', Unix's, and Android's navigator.userAgent, navigator.oscpu, and navigator.platform Web APIs

I have other patches with more incremental changes, such as changing the User-Agent header but not the navigator APIs, but they introduce new code complications. I'd like to propose these patches with the ideal outcome and only fall back to an incremental change if needed for webcompat.

Before:

OS Architecture User-Agent's OS/CPU navigator.oscpu navigator.platform
Windows AArch64 "... Windows NT 10.0; ..." "Windows NT 10.0" "Win32"
Windows x86 "... Windows NT 10.0; ..." "Windows NT 10.0" "Win32"
Windows x86 on x86_64 ... Windows NT 10.0; WOW64; ... "Windows NT 10.0; WOW64" "Win32"
Windows x86_64 "... Windows NT 10.0; Win64; x64; ..." "Windows NT 10.0; Win64; x64" "Win32"
Linux x86 "... Linux i686; ..." "Linux i686" "Linux i686"
Linux x86 on x86_64 "... Linux i686 on x86_64; ..." "Linux i686 on x86_64" "Linux i686 on x86_64"
Linux x86_64 "... Linux x86_64; ..." "Linux x86_64" "Linux x86_64"
Android ARMv7 "... Android 8.1.0; ..." "Linux armv7l" "Linux armv7l"
Android AArch64 "... Android 8.1.0; ..." "Linux aarch64 "Linux aarch64"
macOS x86_64 "... Macintosh; Intel Mac OS X 10.14; ..." "Intel Mac OS X 10.14" "MacIntel"

Changed:

OS Architecture User-Agent's OS/CPU navigator.oscpu navigator.platform
Windows x86 on x86_64 "... Windows NT 10.0; ..." "Windows NT 10.0" "Win32"
Windows x86_64 "... Windows NT 10.0; ..." "Windows NT 10.0" "Win32"
Linux x86 "... Linux; ..." "Linux" "Linux"
Linux x86 on x86_64 "... Linux; ..." "Linux" "Linux"
Linux x86_64 "... Linux; ..." "Linux" "Linux"
Android ARMv7 "... Android 8.1.0; ..." "Linux" "Linux"
Android AArch64 "... Android 8.1.0; ..." "Linux" "Linux"

Unchanged:

OS Architecture User-Agent's OS/CPU navigator.oscpu navigator.platform
Windows AArch64 "... Windows NT 10.0; ..." "Windows NT 10.0" "Win32"
Windows x86 "... Windows NT 10.0; ..." "Windows NT 10.0" "Win32"
macOS x86_64 "... Macintosh; Intel Mac OS X 10.14; ..." "Intel Mac OS X 10.14" "MacIntel"
Depends on: 1484720

AFAICT, we had no tests for the default User-Agent string values.

The primary use case for including CPU architecture and OS version in the User-Agent string is to allow software download sites to offer compatible software. Linux users are unlikely to download much software from sites that sniff their CPU architecture, so omitting it should be safe (or if a CPU architecture token is needed for User-Agent parsing webcompat, we could spoof "i686" or simply "CPU" like iOS Safari).

Once upon a time, Mozilla's Plugin Finder Service checked (bug 265536) whether the browser architecture was 32-bit or 64-bit so it could direct users to a compatible Flash Player plugin. But these days Adobe's Flash Player installer includes both 32-bit and 64-bit plugins.

Depends on D33426

The primary use case for including CPU architecture and OS version in the User-Agent string is to allow software download sites to offer compatible software. If a site doesn't see "Win64" or "WOW64" in the User-Agent string, it might serve a Win32 x86 executable to a Win64 OS user. The x86 executable would still be compatible, just not optimal.

Once upon a time, Mozilla's Plugin Finder Service checked (bug 265536) whether the browser architecture was 32-bit or 64-bit so it could direct users to a compatible Flash Player plugin. But these days Adobe's Flash Player installer includes both 32-bit and 64-bit plugins.

Depends on D33427

And add a compile-time reminder to revisit the macOS User-Agent string when building on some future non-x86_64 (AArch64?) macOS:

  • Can we omit the CPU architecture from the User-Agent string on this new platform? Can we remove "Intel" from the Intel User-Agent string (bug 728582) to reduce fingerprintable platform-differences and header size?

  • What should navigator.platform return? What does Safari's navigator.platform return? Should we still return 'MacIntel' for backwards compatibility and to reduce fingerprintable platform-differences?

Depends on D33428

MOZ_UA_OS_AGNOSTIC was added for B2G's User-Agent string (in bug 777710).

Also remove an always-true check for #ifdef MOZ_WIDGET_ANDROID, which was used to differentiate Fennec Android and B2G.

Depends on D33429

This spreadsheet compares the User-Agent headers and navigator.userAgent, navigator.oscpu, and navigator.platform Web APIs for Firefox, Chrome, Edge, IE11, and Safari on Windows, Linux, FreeBSD, macOS, and Android:

https://docs.google.com/spreadsheets/d/1I--o6uYWUkBw05IP964Ee2aZCf67P9E3TxpuDawH4_I/edit#gid=0

Did we confirm that removing i386 or something from Linux UA didn't break the web (especially Google)? Some websites (especially Google) are very sensitive about UA changes. When we tried to change "Gecko/" token, it broke Google Search and we had to backout the change. As everybody knows, changing Edge UA broke Google Meet, Google Docs, YouTube, etc.

(In reply to Masatoshi Kimura [:emk] from comment #7)

Did we confirm that removing i386 or something from Linux UA didn't break the web (especially Google)? Some websites (especially Google) are very sensitive about UA changes. When we tried to change "Gecko/" token, it broke Google Search and we had to backout the change. As everybody knows, changing Edge UA broke Google Meet, Google Docs, YouTube, etc.

I will file a PI request asking for QA of popular websites. Given the likelihood of webcompat problems, I will add a pref to making testing and disabling the feature easier than a backout.

Keywords: dev-doc-needed
Whiteboard: [necko-triaged]
Keywords: site-compat
Depends on: 1559747
Type: enhancement → task
Attachment #9069253 - Attachment is obsolete: true
Attachment #9069252 - Attachment is obsolete: true
Attachment #9069251 - Attachment is obsolete: true
Attachment #9069250 - Attachment is obsolete: true
Attachment #9069249 - Attachment is obsolete: true
Depends on: 1711835
Severity: normal → S3
Depends on: 1861847
See Also: → 1869521
Depends on: 1873273
You need to log in before you can comment on or make changes to this bug.