How are non-secure context Clients observable?

[ehsan]

As far as I can tell from reading the spec, a Client representing a non-secure context cannot be observed. Clients.matchAll() when used with includeUncontrolled: true already excludes non-secure Clients. And Clients.get() also excludes non-secure Clients (and it's impossible to observe such a clientId in the first place since we don't dispatch FetchEvents for such clients anyways).

Does this mean that implementations are free to ignore the places in the spec where we're talking about Client objects being non-secure?

[jungkees]

As far as I can tell from reading the spec, a Client representing a non-secure context cannot be observed.

Yes, that's the intention. Here's the summary how the APIs deal with the non-secure contexts: #754 (comment).

Does this mean that implementations are free to ignore the places in the spec where we're talking about Client objects being non-secure?

I'm not clear with this. Is there any such place in the spec I'm missing?

[jdm]

@jungkees Look for the phrase "not a secure context" in the spec.

[jungkees]

clients.get(id), clients.matchAll(), clients.claim() can still deal with the non-secure context clients, e.g., the iframes running on the same origin with the service worker but embedded in an http top frame. Those clients should be filtered out, and the above APIs are exactly where that happens.

Re client's id, fetch events for a non-secure client is also filtered out in Handle Fetch, but a non-secure client's id can still be exposed if we don't filter it out in matchAll(), etc.

[jungkees]

Closing. Please let me know if more discussion is needed.

[ehsan]

My point was mostly about Clients.get(). Per spec, there is no way to obtain a clientId belonging to a non-secure context. Clients.matchAll() and Clients.claim() don't work for non-secure clients, and we will never dispatch a FetchEvent for a non-secure non-subresource load, so the behavior of Clinets.get() would be the same whether or not the check for the secure context exists in the spec.