Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
othermaciej opened this issue Feb 5, 2020 · 13 comments
Labels

Comments

@othermaciej
Copy link

@othermaciej othermaciej commented Feb 5, 2020

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

This comment has been minimized.

Copy link

@mcatanzaro mcatanzaro commented Feb 8, 2020

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

This comment has been minimized.

Copy link
Author

@othermaciej othermaciej commented Feb 8, 2020

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

This comment has been minimized.

Copy link

@mcatanzaro mcatanzaro commented Feb 9, 2020

(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

This comment has been minimized.

Copy link
Author

@othermaciej othermaciej commented Feb 9, 2020

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

This comment has been minimized.

Copy link

@mcatanzaro mcatanzaro commented Feb 20, 2020

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

This comment has been minimized.

Copy link
Author

@othermaciej othermaciej commented Feb 21, 2020

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 yoavweiss added the needs_pr label Mar 14, 2020
@yoavweiss

This comment has been minimized.

Copy link
Collaborator

@yoavweiss yoavweiss commented Mar 14, 2020

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

This comment has been minimized.

Copy link
Author

@othermaciej othermaciej commented Mar 14, 2020

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

This comment has been minimized.

Copy link

@yoshimo yoshimo commented Mar 15, 2020

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

@othermaciej

This comment has been minimized.

Copy link
Author

@othermaciej othermaciej commented Mar 15, 2020

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

This comment has been minimized.

Copy link
Collaborator

@yoavweiss yoavweiss commented Mar 16, 2020

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

This comment has been minimized.

Copy link

@mcatanzaro mcatanzaro commented Mar 16, 2020

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

This comment has been minimized.

Copy link

@mcatanzaro mcatanzaro commented Mar 16, 2020

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. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.