On 2/18/2021 3:51 AM, Henri Sivonen wrote:
As for the CPU architecture on Linux, on Mac and Windows we don't
expose aarch64 separately. (On Windows, consistent with Edge, aarch64
looks like x86. On Mac, aarch64 looks like x86_64 which itself doesn't
differ from what x86 looked like.)
As an alternative to removing the CPU architecture from the UA string,
Safari on iPhone literally uses "CPU" as a placeholder:
Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) ...
I don't know if Apple's iOS 1.0 team discovered a broken UA parsing
script that expected a CPU token or if they inserted the CPU placeholder
just to be prudent. Safari on iPadOS (and macOS aarch64, as you noted)
still uses the "Intel" desktop UA.
The software download situation for each desktop platform is
different: On Windows, an x86 stub installer can decide whether to
install x86, x86_64, or aarch64 app. On Mac, Universal Binaries make
it irrelevant to know the CPU architecture at the app download time.
On Linux, downloads outside the distro's package manager typically
involve the user having to choose from various options anyway due to
tarball vs. .deb vs. .rpm vs. Flatpak vs. Snap, etc. OTOH, unlike on
Windows and Mac, x86 or x86_64 emulation isn't typically automatically
ready to work on Linux.
Another alternative is to remove the CPU architecture from the
User-Agent HTTP header (to reduce servers' passive fingerprinting), but
still expose it in the navigator.userAgent and navigator.platform APIs.
But this header/API inconsistency might confuse sites (e.g. like
polyfill.io that serves different JS to different UAs).
I know the VLC download page dynamically detects 32- and 64-bit Windows:
https://www.videolan.org/vlc/
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
