Allow unmasked adapter info fields to be requested individually.

[toji]

Updates the Adapter identifiers proposal based on feedback from yesterday's call. Changes specifically include:

• New values have to be requested by name, passed as a "hints" array. This moves the design of this API closer to that of navigator.userAgentData.getHighEntropyValues()
• Made all values nullable, where previously vendor was not and it was assumed that "unknown" would be returned in cases where the UA did not wish to report the value. Given that Myles stated that Apple doesn't want to return the vendor by default I feel it's more important to give developers a clear sense of which values have not been reported than to always give them a string, regardless of it's accuracy.
• Called out specifically that the values may be masked or bucketed by the UA prior to requesting the unmasked version, and that the UA could choose to not reveal the actual values even after a call to requestUnmaskedAdapterInfo().
• Changed adapter.info to no longer be [SameObject] and for it to update in-place when requestUnmaskedAdapterInfo() is called.

I'd very much appreciate if Myles or another representative from Apple could give this a look and see if it addresses the changes that were requested.

Additionally, something I meant to ask on the call but forgot: Would Apple consider exposing any of these identifying values after user consent has been explicitly given in response to a requestUnmaskedAdapterInfo()? I understand that the intent prior to that is to return null for everything (which is allowed by this proposal).

[github-actions]

Previews, as seen when this build job started (cca4dd4):
WebGPU | IDL
WGSL
Explainer

[github-actions]

Previews, as seen when this build job started (e0c201f):
WebGPU | IDL
WGSL
Explainer

[github-actions]

Previews, as seen when this build job started (a6aa084):
WebGPU | IDL
WGSL
Explainer

[toji]

Thanks!

[kdashg]

WebGPU meeting minutes 2022-03-09

• BJ: (summary), also some other minor changes.
• BJ: Right now, says if you request something that the UA doesn’t want to provide, it rejects the promise. Unsure if that fits with the ethos of what we’re trying to achieve.
• MM: Think you did everything I described last time we discussed. One thing I was surprised by was iframe allow=webgpu, which is a little scary because we might want to disallow webgpu in iframe regardless of whether the parent page wants to allow it.
• BJ: Reasonable, figured I’d highlight another privacy-centric tool here, but technically distinct so could move forward with just the identifiers portion of this and continue to discuss whether or not we want to use the permissions API for iframe control.
• KG: Where is this mentioned?
  • BJ: Not in this PR, but in the document already: using permissions API to add new values that can block an iframe from using WebGPU. Becoming more common to control things like WebXR, Web Audio, etc. Way of embedding content without allowing capabilities.
  • https://github.com/gpuweb/gpuweb/blob/adapter-identifiers-refactor/design/AdapterIdentifiers.md
  • BJ: Included because also falls under the privacy umbrella.
• MM: Not pushing back on the idea, just not very familiar with the attribute. Does allow=webgpu mean you must allow WebGPU or does it allow the browser to still deny it?
• BJ: Completely reasonable to discuss/learn about this separately.
• MM: On rejecting: Probably good, encourages authors to only request what they need, make it slightly painful to request all info.
• BJ: Want to do some reading to learn why that decision was made in the getHighEntropyAPIs. Seems that providing a rejection provides more information than just null/undefined - ambiguous which of [UA doesn’t know, UA doesn’t expose, user chose not to expose, etc.]. So want to see why they did it this way.
• MM: The promise may also be hiding a prompt. UAs try to avoid making prompts. So if there’s a rejection and then the page requests less info, it might get auto rejected so the UA doesn’t have to ask again.
• BJ: Reasonable to iterate further…. If no concerns about this PR to the design doc, would like to merge it and then put together PRs about how it would be integrated into the spec. Any concern?
• KG: Rejecting seems more fragile than just returning less info. Useful because most of the codepaths keep working. Rejecting has to be handled explicitly. In a world where there’s an app that works in a common browser and doesn’t care about others, they may well break in other browsers.
• BJ: …
• KN/KG: Likely best to ALWAYS provide strings (no null/undefined), for that issue. Then all of the string prototypes are present.
• BJ: Only thing it may cause confusion with is if the driver returns an empty string or something. Don’t know if it’s ever important to distinguish that from “I didn’t want to tell you an answer”. Only place where it seems preferable.
• KG: Approved PR
• MM: KG, would prefer never to reject, instead return empty GPUAdapterInfo?
• KG: Basically yes. Think key thing this is valuable for, is to leave us room to ask the user for permission. That’s the big winner. And allow asking for specific things. As UAs probably wouldn’t be able to actually prompt at this granularity, but this API design allows us the opportunity to try.
• BJ: Agree the important part is the opportunity. Also allows UAs to decide where their cutoffs are. What they would expose always, behind a prompt, never.
• BJ: Myles, you’ve said you would never expose anything. Would Apple ever feel comfortable providing values with user consent?
• MM: Our general philosophy is that it’s very hard to get informed consent from users via a prompt. But that’s part of our browser product, not my call.
• KN: What we can do with this info, is use it to group this request to say e.g. “this page wants to identify you within a group of about NNN individuals”. Something like that.
• KG: Think we have things to move forward here.