Exposed=* vs Exposed=Shadow

[annevk]

whatwg/dom#1253 suggests that in order to be a global you now need to support an event loop. When we started out with this that's not what ShadowRealms would imply. And in fact it would be the APIs we could imagine each global to support.

I wonder if this means we should simply give them their own Exposed value and add that in various places.

Correct me if I'm wrong, but I don't think all worklets have an event loop for instance.

cc @domenic @littledan @Ms2ger @ptomato

[domenic]

Right, Exposed=* doesn't work for anything event loop related, because of worklets. I wonder what happens when you construct a ShadowRealm inside such a worklet? I think that just argues against exposing such things to ShadowRealms.

[Ms2ger]

The main reason for Exposed=* is that it would be surprising to expose things in a shadow realm that are not exposed in its principal realm. I suppose the alternative is that exposure inside a shadow realm is conditional on them being exposed in the principal realm as well.

[annevk]

Or we don't expose shadow realms in certain globals. There's a lot of options, but you can't impose event loops on all (potential) globals.

[caridy]

Oh, I thought we already made that decision a while ago when we decided to make the global object of a shadow realm an event target.

[domenic]

? EventTarget is unrelated to the event loop.

[caridy]

Ok, I think I understand it now. It seems that we have multiple options:

A. Exposed=Shadow regardless of what the principal realm exposes. (I don't think this is really an option).
B. Exposed=Shadow conditional on them being exposed in the principal realm. (Would this open the door for ShadowRealms inside worklets if use-cases surface in the future?)
C. Exposed=* expose shadow realms in certain globals, which means it must be excluded from worklets.

Is there any other option? It sounds to me (with my very limited knowledge) that option B is superior, but I have no idea how that could be spec'd.

[domenic]

Another option is to not expose anything in shadow realms which is not exposable to worklets, i.e. not expose anything which has an event loop dependency. I believe that was the original consensus.

[annevk]

Yeah, the original idea was that shadow realms would only have features we could imagine being in all possible (including future) global environments. That's why * felt justified. If you stray from that you will need to exclude either shadow realms from certain globals or exclude features from shadow realms when used in certain globals.

What syntax to use if you decide to stray from the original idea would need some consideration.

[caridy]

@annevk @domenic here is where we need your guidance and knowledge. The only recent change was about timers, specifically setTimeout & co. Since we are not in the business of protecting against side-channel attacks (spectre/meltdown), we have no reasons to prevent or sensor timers, for those reasons, we thought it was OK to include setTimeout & co in the initial list. It seems that this has bigger implications (which we didn't know). In other words, we have no opinions on whether or not this can be/should be included or not.

Additionally, I will like to know what other APIs depend on the event loop? we can double check our use-cases against those!

[littledan]

While timers would be convenient, they aren't essential for any ShadowRealm use case I've heard of. I like following the philosophy of exposing to ShadowRealms the intersection of what will be available in any conceivable environment. This sounds like a convenient rule of thumb when deciding what to put in ShadowRealms, avoiding the need for web spec developers to think through "confidentiality" and "integrity" with respect to a certain programming model that they might not be familiar with.

[ptomato]

Specifically, not exposing any APIs that depend on an event loop seems like a good criterion, and the rationale outweighs the requests in #393 for the convenience provided by setTimeout.

Concretely, this would mean reverting the recent changes to whatwg/html#9893 re. {set,clear}{Timeout,Interval}, and closing whatwg/dom#1253. Agreed?

Additionally, I will like to know what other APIs depend on the event loop

@Ms2ger is double-checking that none of the other, non-timer, APIs that we proposed to have in ShadowRealm have this dependency. I'm not sure about queueMicrotask; at first glance it seems that it only depends on having a current execution stack, not an event loop, but we'd need to verify that.

[ljharb]

Given that Atomics.wait exists, isn't there already a timer in the language, that would definitely exist in ShadowRealms? Assuming that's accurate, what would be the harm of including other ones like setTimeout?