Split up UA-Bitness hint into 2

[miketaylr]

Thinking more about the use-cases for "bitness" (see #105), it seems desirable to not only know platform bitness, but also the app bitness. For example, if you run an app store webpage, or a support page for an app, you can know if a user has downloaded the most optimized binary, or is in some other "32bit app on 64bit OS" bucket (aka "WOW64").

These 2 hints (UA-App-Bitness? / UA-Client-Bitness? & UA-Platform-Bitness) would be high-entropy hints and not available by default.

[bat999]

Hi
The User Agent string doesn't make reference to bitness with my Android phone.
So I would hope to see "" for any bitness-related User Agent Client Hints.
Same as with Sec-CH-UA-Arch: ""
(Just sayin')

[cpeterso]

Firefox's UA used to expose both the browser and platform bitness, e.g. Windows NT 10.0; WOW64 and Linux i686 on x86_64. The browser bitness (in Firefox bug 265536) was originally added so Mozilla's Plugin Finder Service could offer a 32-bit NPAPI plugins to 32-bit Firefox browser even if it was running on a 64-bit OS. (A 32-bit Firefox could not load a 64-bit plugin.)

I don't believe there is still any use case for exposing the browser bitness. No major browser still supports Flash or other NPAPI plugins and Adobe's Flash installer has bundled both 32- and 64-bit plugins for years. If a user is running a 64-bit OS, they probably would like to be offered 64-bit app installers, even if they are running a 32-bit browser for some reason. As such, I removed the browser bitness from Firefox's UA string in Firefox 69 (bug 1559747), exposing just the platform bitness.

[miketaylr]

The User Agent string doesn't make reference to bitness with my Android phone.
So I would hope to see "" for any bitness-related User Agent Client Hints.

I agree that bitness shouldn't be sent by default, but I think there are valid use cases for making it available. The spec has a carve-out for this if a browser wanted to withhold that information for privacy reasons:

User agents MAY return the empty string or a fictitious value for full version, platform architecture, platform bitness or model, for privacy, compatibility, or other reasons.

[bslassey]

I think this is something where we can wait until we have concrete and compelling use-cases (and I suspect the use cases would be pretty niche). Two come to mind, first I could imagine that media codec selection. I can also see browser support forums (and bug trackers) making use of this information.

[miketaylr]

I think this is something where we can wait until we have concrete and compelling use-cases (and I suspect the use cases would be pretty niche).

Yeah, agree. Let's park this for now and reconsider once we're sure it unlocks important use cases.

[miketaylr]

Documenting this relevant tweet:

https://twitter.com/makoto_kato/status/1381824750129872901

When looking crash data of Fenix, Most crashes are Android ABI is 64-bit, but Fenix build is 32-bit. Why do Fenix users 32-bit build on 64-bit device?

[bonmotbot]

We have a use case of the browser bitness in Google Meet. We turn off some features on 32-bit browsers because the performance isn't good enough without 64-bit SIMD instructions. Without the browser bitness hint, we won't be able to make that distinction anymore, or to detect its impact in future performance analysis.

[jesup]

You can directly test the speed of whatever SIMD operation I presume. It depends I suppose on what is slow on 32-bit. Scaling? Image analysis? If you can test the operation speed itself, you don't need to know the architecture. Also, in theory a browser might not optimize the case you care about on a 64-bit system, so 32 vs 64 may not be what you need.

In general, testing if something is implemented, or testing if it's fast enough on the system you're actually on, is better than any form of sniffing.

If this is hidden deep in Meet, and you don't know what the slow operation is, then sniffing is iffy anyways - and the Meet implementation might change tomorrow, so your sniffing may be wrong then.

Of course, Meet is the code that should be running these runtime acceptance tests, not some site using meet.

[bonmotbot]

Just to be clear, I'm reporting this use case on behalf of Google Meet, not trying to use Meet in another site.

Currently, we check for a 32-bit browser and disable some features, since we know they won't work well. The check lets us notify the user why the feature isn't supported and link to a help article:
https://support.google.com/meet/answer/10058482?expand_all_zippies=true#requirements&zippy=%2Cwhy-cant-i-use-the-change-background-option

It also allows us to avoid downloading a ~7MB wasm binary, which implements the unsupported features.

Without the browser bitness check, we can't really tease this case out from other sources of slowness. We'd have to let users download the extra code and let it work poorly, when we could have prevented that ahead of time.

Of the 32-bit browser usages we see currently, about half are on 64-bit OS, so this is a real segment of users.

[miketaylr]

Thinking about this some more, I think it's useful to make the transition from the UA string to UA-CH as seamless as possible, for browsers that exposed app bitness as WoW64 (obviously browsers that don't do not have any requirements to start exposing it) - even if we aren't aware of sites relying on this (we do know of Meet, but there's a vast audience of sites and devs out there who aren't looking at this issue to reply with use cases).

I don't think we need to expose the actual binary bitness, if backwards compat is the goal, but we can just add a hint that returns a boolean for "wow64-ness".

[cpeterso]

I don't think we need to expose the actual binary bitness, if backwards compat is the goal, but we can just add a hint that returns a boolean for "wow64-ness".

Firefox added app bitness to its UA so NPAPI plugin installation sites could differentiate between Win64 and WoW64 browsers. WoW64 Firefox didn't support 64-bit plugins. But now that Firefox no longer supports NPAPI plugins, Firefox reports Win64 for both Win64 and WoW64 browsers.

we aren't aware of sites relying on this (we do know of Meet, but there's a vast audience of sites and devs out there who aren't looking at this issue to reply with use cases).

@miketaylr - Does Meet differentiate between Win64 and WoW64 browsers? Do you have any more information you can share about Meet's 64-bit checks?

[miketaylr]

Does Meet differentiate between Win64 and WoW64 browsers? Do you have any more information you can share about Meet's 64-bit checks?

@cpeterso I'm not super familiar with the code, but perhaps @bonmotbot would know.

[bonmotbot]

The distinction between WoW64 and Win64 is used to disable features mentioned above. They're only supported on 64-bit browsers, which includes Win64, but not WoW64.

[mehagar]

@miketaylr , following up our conversation elsewhere, there is a use case for having Chrome OS reveal whether or not they are running on 32-bit Chrome OS or 64-bit Chrome OS (where the architecture of the CPU itself is 64-bit for both). The Zoom web app currently handles 32-bit Chrome OS (and Windows 32-bit Chrome, for that matter) differently by changing how WebAssembly memory is allocated, due to memory constraints on those 32-bit applications.