It would be nice to leave the possibility for user agents to lie about supported extensions, for example to reduce fingerprinting surface in untrusted contexts.

@Kangz , how would leaving the possibility for user agents to lie change the proposed spec text?

Agree, since the [=adapter=] can expose whatever it wants, this leaves the user agent open to "lie" by just not including all hardware capabilities in the WebGPU adapter's capabilities.

Maybe we could just say if an extensions is exposed by the user-agent and supported by the adapter then it will be true, otherwise undefined?

I'll tweak this.

I'm also thinking about changing the 'false' case to also expose undefined. There shouldn't be any reason that apps need to differentiate the two.

To me, if we feel like we must say something about lying, it would be non-normative text that says something along the lines of: "For privacy reasons, user agents may lie to you about hardware capabilities" and leave it at that.

If we start introducing new values like "undefined", then we risk sites intentionally or non-intentionally breaking when run in privacy modes ... not a good user experience.

There’s “lying” and then there’s “lying.” We can make “lying” implementations intentionally diverge from the spec, or we can make the flex more flexible to allow for intentional “lying.” We should do the latter.

To clarify, do you think the spec as written is insufficiently flexible to allow lying? Or just responding to Rafael's comment?

The phrasing "supported by the [=adapter=]" does not yet exist. That is where we would say that the browser can create adapters which "support" whatever they want.

Please describe what the word "realm" means within the context of WebGPU? Are you referring to different threads? Objects belonging to different adapters? Objects belonging to different WebGPU instances? Something else? The ECMA spec definition didn't clarify things for me.

Now that I'm looking at it again, I think realm is the wrong one. Agent looks like the right definition, does it clear things up?

(I'm talking about different threads (workers).)

The spec you linked describes Agents as a set of execution contexts. A thread is a means to execute jobs on the contexts. Unless I am missing something, I do not think this is quite the same as "agent == thread"

Is this "agent" different than the agent used in the term "user agent"?

If you're talking about different threads/works, why don't we just use that term instead?

Agent is the spec language used by ECMAScript and HTML.

https://html.spec.whatwg.org/multipage/structured-data.html#transferable-objects

Transferable objects support being transferred across agents.

An agent is not the same as a user agent. It's what we colloquially refer to as a "thread" (main thread or worker).

Thanks, @kainino0x . That makes sense.

@Kangz , how would leaving the possibility for user agents to lie change the proposed spec text?

Why are we introducing internal objects anyway? It seems confusing to me: it implies that some objects are not internal. Moreover, what is the value in saying that an interface exposes API to an internal object? I mean, how is it internal any more as we have a public interface to it...

Internal objects exist to be shared across "agents" (threads). IDL interfaces cannot, because they are JS objects.

I wouldn’t call them “internal,” then.

(sorry for the slow response.) Can you elaborate - why not? They are not exposed to the web platform - that's why they're called internal (in line with "internal slot"). Should a different name be used?

It seems confusing to me: it implies that some objects are not internal.

To clarify, the interface objects are not internal.

Moreover, what is the value in saying that an interface exposes API to an internal object? I mean, how is it internal any more as we have a public interface to it...

I was imagining the tracked state as being internal to the internal object, so it would expose the API. However I realize now that doesn't make sense - the internal object should be like a "dumb struct" whose state tracking is visible to the GPU* object which exposes it.

why would it be a different adapter if it's just a GPU that re-connected?

I was thinking the old adapter would be permanently lost, and we would return the new one if you ask again. This isn't strictly necessary (adapters don't have to be one-way the way devices do, according to ErrorHandling.md), but it keeps consistency. Imagine the following two cases:

• External GPU is unplugged and plugged back into the same port
• External GPU is unplugged and plugged back into a different port
• External GPU is unplugged and an identical one is plugged in

I see no reason that the application should want to be able to distinguish these, or should have to program against extra possibilities that behave the same way. So we either have to make these all appear as the same adapter (what happens once you have two?), or we have to make it always appear as a different adapter.

I think the confusion comes from "Different" word here. I read it as: you have a list of things returned by a function, and this documentation explains why it has different things. But what you are trying to explain in this comment is why would a subsequent request for this list potentially return things that are different from the current request.

I agree with @kainino0x that once an adapter becomes lost, it should stay permanently lost. If the user re-plugs in an external GPU, WebGPU should create a brand new adapter object for it.

Updated the text here; PTAL

I presume the "[=device=] that this {{GPUDevice}} refers to" is meant to be an "internal slot"?

Not sure I understand, but yes it is an internal slot:

{{GPUDevice}} also has the following internal slots:

I wouldn’t call them “internal,” then.

There’s “lying” and then there’s “lying.” We can make “lying” implementations intentionally diverge from the spec, or we can make the flex more flexible to allow for intentional “lying.” We should do the latter.