Sec-CH-UA-Arch exposes info that is frozen or omitted in some UA strings, thus would be a privacy regression

[othermaciej]

In Safari, we have frozen or omitted the CPU value found in some legacy UA strings.

For desktop versions of Safari (including macOS and iPadOS), we use Intel and for mobile versions (including iOS and watchOS) we use CPU, whether or not this accurately reflects the CPU architecture. And we hav decided not to introduce new values even if we introduce new CPU architectures.

Thus, implementing Sec-CH-UA-Arch honestly would be a privacy regression for us. We could implement a fake version that only says Intel or CPU, or perhaps even a version that only says CPU, but then what's the point? It's also not clear if a bogus implementation like this would be compliant with the spec.

I think it would be best if this was dropped, but at the very least it should be optional, since some browsers are choosing not to expose CPU information.

[mcatanzaro]

I don't understand what benefit exposing CPU architecture could possibly have. Why would a server possibly care what CPU architecture is being used? (Maybe to autodownload architecture-specific binaries to the user's computer? Is the benefit really worth the cost?)

WebKit has previously experienced trouble where Google websites (e.g. Google Maps, Google Calendar, etc.) provide a degraded user experience when the CPU architecture string is not "x86_64", so we have a quirk (not used by Safari; WebKit and Safari have separate UA quirks) to send an x86_64 user agent to such domains. My guess is that this is some badly misguided attempt to check for OpenGL capability, but it doesn't really matter why it happened: what matters is that major websites actually intentionally look at the CPU architecture portion of the user agent string and improperly decide to degrade the user experience if it doesn't match what they want to see.

Any client hint exposed by this spec is inevitably going to require a quirks list so that we can send fake values to websites that decide to use it to alter web content. It's easier for everyone if we limit client hints to the minimum that's actually required.

[othermaciej]

I'm not sure what it's for either. I guess downloads? On platforms that have multiple CPU architectures and no norm of fat binaries or CPU emulation, executable downloads could be different per-CPU. That said, we've frozen it in Safari and will likely never update it. (We'd probably recommend other ports also freezing at "Intel" for desktop platforms (or "Intel"/"x64"/"x86_64" if it needs to be different per OS) and "CPU" for mobile platforms since these demonstrably work fine.

I would be happiest if this was omitted entirely.

[mcatanzaro]

(We'd probably recommend other ports also freezing at "Intel" for desktop platforms (or "Intel"/"x64"/"x86_64" if it needs to be different per OS)

Oh yes, it needs to be "x86_64" for Linux. I think FreeBSD uses "amd64" which may cause problems, because the Linux value has ossified. (WebKitGTK uses the value from uname -i, which is platform-specific.)

[othermaciej]

Exposing uname -i might be an unnecessary privacy leak, relative to always pretending to be x86_64, even on 32-bit intel, platforms like FreeBSD, and other CPU types in generally desktop platforms.

[mcatanzaro]

Oh yes, it needs to be "x86_64" for Linux. I think FreeBSD uses "amd64" which may cause problems, because the Linux value has ossified. (WebKitGTK uses the value from uname -i, which is platform-specific.)

Here's a reference, the architecture must not begin with the letter "a" otherwise it breaks Google Calendar: https://bugs.webkit.org/show_bug.cgi?id=142074#c25

[othermaciej]

Issues like this Google Calendar thing illustrate some of why we don’t want to expose the CPU type at all for Apple WebKit ports. We’d prefer to leave this header blank, or set it to a special “Unspecified" CPU value, or ideally not even have it in the spec.

[yoavweiss]

Allowing the architecture to be unspecified seems totally reasonable. Regarding the mentioned issues, one of the goals of this proposal is to reduce the server side complexity required to parse UA strings, and reduce such bugs.

[othermaciej]

I would prefer we drop it entirely, to merely allowing it to be unspecified. What's the use case for exposing CPU architecture at all? I think we should keep this as an optional feature only if there is a good use case. And even then, only if #61 is also addressed.

[yoshimo]

Well you could argue it helps to serve the proper application file along with the OS.

[othermaciej]

You could argue, but is that the true intended use case? Is it the only use case?

On many systems, native app download is impossible or not recommended except through trusted online stores, so at least in this cases, that wouldn’t be a reason to expose the CPU architecture. On other platforms with multiple CPU types, there are fat binaries or emulators, or historically have been.

If CPU arch is solely for app downloads, how about at least limiting to platforms where that is possible and architecture is relevant?

[yoavweiss]

The intended use case is indeed for download pages to be able to offer the right binary by default. Looking at the use cases, it seems like I left that one out. I'll add it.

[mcatanzaro]

I think it's fine as long as browsers have an option to leave it unspecified. On Windows, we can reveal the actual architecture to facilitate binary downloads, and on other platforms we can leave it unspecified.

If it becomes a problem in the future, browsers can always lie and set x86_64 everywhere. The spec should be clear that the arch hint should be used as a hint, not as end truth.

[mcatanzaro]

One thing's for sure: I don't want WebKit revealing to the web that users are using interesting architectures like ppc64le, s390x, mips, aarch64, etc. That should cost more entropy budget than we ever allow. ;)

[yoavweiss]

I believe this was closed by #90

[othermaciej]

Confirmed that this is addressed by #90, by making CPU architecture optional and discouraged in most circumstances.