Client Hint for CPU "bitness" #105
Comments
|
I don't think this is a good idea; it's quite a bit of extra entropy. Is this exposed in any current User-agent strings? |
I'm not 100% sure it is either, therefore I marked it as "enhancement", that may be part of a future iteration. The motivation here: As part of #106 we significantly reduce the entropy currently exposed (at least in Chromium, at least in some platforms), under the assumption that it's sufficient for binary downloads. The idea is that if legitimate use-cases arise that actually need that extra information, we'd be able to provide that information without forcing the more common use cases to touch that entropy. |
|
@othermaciej this is related to #106 (comment) where you said that the 32/64bit distinction is important. Entropy-wise, having a single hint that has arm32, arm64, x86 and x86_64 versus two hints with arm, x86 and 32, 64 values is the same. Practically, I see some benefits from separating the two. First, it is forward compatible in that as the architectures have expanded (i.e. when 32 bit and 64 bit chips were introduced) existing binaries were backward compatible (so 16bit binaries ran on 32 bit chips and 32 bit binaries ran on 64 bit chips). In the future when we have 128 bit chips, I would hate to see a world where the x86_128 or arm128 tokens caused sites serving 64 bit binaries to error out. On a similar token, right now if I am a site hosting 32 bit x86 or 32 bit arm binaries, I don't particularly care about the distinction of 32 and 64 bit when user is trying to download them. |
|
Not all 64-bit operating systems for arm or x86 are able to run 32-bit binaries. (For example, the latest versions of macOS and iOS are strictly 64-bit only; and there's apparently Linux distributions that have 64-bit only userland). But perhaps this is not the common case. I did not initially get that this was only meant to express 64-bit vs 32-bit. I imagined "detailed CPU architecture" would mean a specific processor or processor generation, e.g. A hint for just 32-bit vs 64-bit seems ok, though I'm not sure there is much win to separating x86/arm/blank from 32/64/blank. (For Safari on Apple platforms, we'll probably always leave these blank, or pick one fixed value for all mobile and another for all desktop, even if these have to be fake on some devices.) |
|
(Or perhaps you could imagine something short of exact CPU model but still more than the broad architecture class. Within 64-bit ARM, the original version is |
|
Can we change the title of this issue to make clear that it's only about "bitness" for related 32-bit and 64-bit CPU architectures, and not about more specific instruction set architecture versions like |
yoavweiss
changed the title
|
Changed. We may still look into exposing more specific instruction set in the future, but I agree that if we'd do something like that, it'd probably be yet another hint, and it's better to focus this issue on the clearer use case. |
|
UA-CH-CPU-Bitwidth?
…On Wed, May 13, 2020, 5:54 PM Maciej Stachowiak ***@***.***> wrote:
Can we change the title of this issue to make clear that it's only about
"bitness" for related 32-bit and 64-bit CPU architectures, and not about
more specific instruction set architecture versions like ARMv8.6-A, or
exact CPU models like Qualcomm Snapdragon 410?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#105 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKSN4TNHG34OMT4VMD4J2LRRMJJHANCNFSM4MY33ZAQ>
.
|
|
|
On macOS we chose to use "Intel" to represent both flavors of the x86 CPU architecture and have never exposed this distinction to the web. iPads (by default) and iPhones (when using "Request Desktop Site") both also claim to be "Intel". I think if we implement UA client hints, we'd likely not expose the CPU architecture or bitness on any Apple platform. |
That's Apple's prerogative, but as ARM slowly invades the desktop, this can remove information for ISVs providing downloads. At time of writing this, Windows and Linux both provide it. My understanding of the client-hints was to allow this type of information when requested (as opposed to User-Agent which doesn't give the end-user an option to opt-out). I'd expect more information through sanctioned channels and for this reason, I'd expect browsers to make an upfront attempt to remain the same. That said, from an ISV's perspective, Safari poses other technical issues already. Furthemore, Apple's philosophy on mixed architecture (if such a thing ever happens again in the future) has historically been to offer up a "Universal" packager for all to remove any selection-burden from the end-user at the expense of download size. Ultimately, downstream's always at the mercy of the decisions of upstream, but if a standard is accepted, it'd be stellar to have Safari on board with that. |
|
This incubation spec (not yet a standard) allows omitting this info, and we’re on board with this. You’re right that Apple’s recommendation across CPU arch transitions is generally universal binaries (or else an emulator, as was done for PPC —> Intel. |
|
As a downstream implementer, I'm still unsure how to handle this. @othermaciej although I respect the decision to keep this info private, for those that do provide it, the spec seems to still require certain values. For now, I think I'll just keep it as |
|
Refer to the spec and its editors for what's allowed in this field. I think the intent is that the main CPU field will only be |
|
Rephrasing....
Hmm... well, the readme says
Is this not the correct forum? |
Thanks for pointing out that contradiction. #112 fixes the README. |
(And some small language tweaks and a typos fix in the spec)
Intent to Implement and Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/dafizBGwWMw WICG/ua-client-hints#105 To be honest, the only real point of interest is `content/common/user_agent.cc`, which is where `GetLowEntropyCpuBitness` is implemented. Everything else is various levels of plumbing to set up a new Client Hint header, populate it, test it, and add a new Permissions Policy to control it. Bug: 1199809 Change-Id: I0e7f36c8915720cb46e06452a85092a64bde8f06 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2840423 Commit-Queue: Aaron Tagliaboschi <[email protected]> Reviewed-by: Andrey Kosyakov <[email protected]> Reviewed-by: Alex Moshchuk <[email protected]> Reviewed-by: Yoav Weiss <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Colin Blundell <[email protected]> Cr-Commit-Position: refs/heads/master@{#894021}
Intent to Implement and Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/dafizBGwWMw WICG/ua-client-hints#105 To be honest, the only real point of interest is `content/common/user_agent.cc`, which is where `GetLowEntropyCpuBitness` is implemented. Everything else is various levels of plumbing to set up a new Client Hint header, populate it, test it, and add a new Permissions Policy to control it. Bug: 1199809 Change-Id: I0e7f36c8915720cb46e06452a85092a64bde8f06 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2840423 Commit-Queue: Aaron Tagliaboschi <[email protected]> Reviewed-by: Andrey Kosyakov <[email protected]> Reviewed-by: Alex Moshchuk <[email protected]> Reviewed-by: Yoav Weiss <[email protected]> Reviewed-by: Daniel Cheng <[email protected]> Reviewed-by: Colin Blundell <[email protected]> Cr-Commit-Position: refs/heads/master@{#894021} NOKEYCHECK=True GitOrigin-RevId: 1649e103a6c9a386884f1a2366979b2b0e0bcd8c
There may be use-cases in which detailed CPU architectures is needed (e.g. download of highly-optimized binary executables).
It would be good to keep the current
architecture/Sec-CH-UA-Archrelatively low-entropy (for the common case), and potentially expose more detailed info only to sites that opt-in to that specifically.The text was updated successfully, but these errors were encountered: