Allow browsers to report the CPU architecture

[LifeIsStrange]

Introduction

It's quite crazy that I have in 2021 to make a proposal to such an antique problem but here we are and the problem is growing at an increasingly fast pace.
There is no reliable way do distinguish between 32 bit and 64 bit X86 CPUs, more importantly, there is no reliable way to even distinguish between ARM and x86 cpus...
The web browser makers have procrastinated this need for decades since the amalgam of Android/IOS == ARM and PC/macOS == x86 didn't worked too bad.. (except Android x86 is a thing) until now.

Use Cases

By far the main use case is to give the right binary to download for a given user. PCs ARM marketshare is growing at an increasingly fast pace. All new MacBooks use the M1 ARM processor, all (?) chromebooks use ARM since a long time and have (~10% ! of laptop marketshare), people have built ARM linuxes since decades and Windows ARM "Always connected" laptop will follow the path that Apple has paved. ARM is by design more energy efficient than x86 which make it more suitable for laptops, AND is becoming as fast as x86 latest CPUs.

The issue about this paradigm shift is that compile time languages that have no bytecode/VM generate arch dependant binaries (C, C++, Rust, Go, others).
And asking the user to choose its processor version adds friction and more importantly is just not a reasonable solution since a huge chunk of users will be unaware of what even x86 or ARM means...
Sure FatELF is a thing but it is 1) FAT AKA not ecological and 2) doesn't work on Windows.

Solution: Write Once, Run Anywhere

There seem to be a reliable (?) API to query the platform:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/PlatformArch
and it is supported by ALL browsers! Except it was placed under the WebExtension umbrella...
The proposal is to make this API accessible for regular websites too.
optional:
At the same time, this might be the occasion to extends the support to other archs (MIPS, RISC-V, etc) (I hope browsers can internally leverage an API to automatically get the CPU arch for any ARCH, it should be doable).
optional:
exposing hardware support level with things like HWCAPS levels
The most useful hardware support to detect would be SIMD support (and vector length)
https://v8.dev/features/simd apparently it's possible to detect but not sure it report the max supported vector length nor how accurate it is (ARM neon, SVE, etc)
moreover one can hope that one day at least for strong ecological reasons, JS will support SIMD natively like all other programming language in existence and when that day will come, such feature detection would be necessary.
optional: distinguish between ARM 32 and 64 bit

Privacy & Security Considerations

"No considerable privacy or security concerns are expected, but we welcome community feedback."
Native programs have had access to such informations since the begining of time and it is not a cause of significant security flaws.
About browser fingerprinting, that is not a real concern, the discriminative power of knowing the arch is extremely low especially compared to the regular low hanging fruits used in fingerprinting. The same apply for the optional extension of expliciting vector support, since any CPU from the decade support vector instructions and the vector length is increasingly reaching a maximal cap (512), leading to a progressive normalization of those values.

[beaufortfrancois]

User-Agent Client Hints as described at https://wicg.github.io/ua-client-hints/ and https://web.dev/user-agent-client-hints/ allow you to get the CPU architecture.

Your use case is listed at https://wicg.github.io/ua-client-hints/#binary-executable-downloads.

Here's a JS example:

await navigator.userAgentData.getHighEntropyValues([ "architecture", "bitness" ]);

{
  "architecture": "x86",
  "bitness": "64",
}

[cwilso]

@LifeIsStrange is the above solution sufficient to close this as a proposal?

[LifeIsStrange]

@beaufortfrancois sorry for the delay and thanks!
Well this answer exactly my use case (except info on SIMD support) but:
I am not familiar with the client hints proposal:
About
getHighEntropyValues()
The name makes me thinks that (in a paranoid manner) the browser will return values with "randomization" / entropy meaning that either the browser will sometime return false values (which is intolerable) or deny the request without a valid reason.
What makes those getters reliable in practice?
(sorry for my ignorance in the topic)

Related: WICG/ua-client-hints#151

[beaufortfrancois]

@miketaylr would know for sure but my understanding is that getHighEntropyValues() currently returns valid values in Chrome according to https://source.chromium.org/chromium/chromium/src/+/main:components/embedder_support/user_agent_utils.cc;l=326;drc=e3a85bb84de97dfe6941ea22f0595b7421fee480
In the future though, if the browser detects your webpage is using these data in an hostile way, getHighEntropyValues() may fail.

[LifeIsStrange]

Well then assuming reliability of the getter, this issue can be closed, thanks for sharing! :)

[miketaylr]

Yep, what @beaufortfrancois said.

Also, @LifeIsStrange, if you have use-cases for exposing the bitness of the browser (in addition to the current platform bitness), could you leave a comment in WICG/ua-client-hints#217?