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

Status: NEW

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

Description

[Chris Peterson [:cpeterson]]

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"

Comment 1

[Chris Peterson [:cpeterson]]

Attachment: Bug 1556223 - Part 1: Add tests for the default User-Agent before enabling resistFingerprinting. r?tjr

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

Comment 2

[Chris Peterson [:cpeterson]]

Attachment: Bug 1556223 - Part 2: Remove CPU architecture from the Unix and Android User-Agent strings and navigator APIs. r?tjr

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

Comment 3

[Chris Peterson [:cpeterson]]

Attachment: Bug 1556223 - Part 3: Remove CPU architecture from the Windows User-Agent string and navigator APIs. r?tjr

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

Comment 4

[Chris Peterson [:cpeterson]]

Attachment: Bug 1556223 - Part 4: Remove unused Mac PPC code from the macOS User-Agent string code. r?tjr

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

Comment 5

[Chris Peterson [:cpeterson]]

Attachment: Bug 1556223 - Part 5: Remove always-false MOZ_UA_OS_AGNOSTIC macro from B2G. r?tjr

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

Comment 6

[Chris Peterson [:cpeterson]]

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

Comment 7

[Masatoshi Kimura [:emk]]

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.

Comment 8

[Chris Peterson [:cpeterson]]

(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.

Comment 9

[Dennis Schubert [:denschub]]

According to bug 1869521 and this social media post, exposing the CPU architecture is a WebCompat issue that manifests in YouTube delivering a lower resolution, and some sites always delivering a mobile layout.

Comment 10

[Dennis Schubert [:denschub]]

Disregard - I'll move the WebComapt flag to bug 1861847, where it's more appropriate, and that bug is most likely also easier to fix as the risk of breakage is easier to manage.