Who Maintains the Invariants

[mgaudet]

I have a slightly dumb question about ShadowRealms. In principle, we're doing a whole bunch of work to define the set of exposed interfaces inside a ShadowRealm for the web platform integration. Mechanically right now that's all done via Exposed=*.

The discussion about what to include covers things like maintaining invariants like confidentiality.

My question is this: As the web platform evolves, and new standard authors write their interfaces... who is going to make sure that someone doesn't break the invariants (especially since for new standards, I'm sure Exposed=* seems reasonable as a default choice). Are we going to provide guidance for how standards should interact with this?

This is extremely related to (but not 100% overlapping with) #398 as well.

[mgaudet]

(Yulia suggested I tag @domenic / @annevk here as well for visibility)

[annevk]

He Who Remains

j/k, no idea.

[caridy]

@mgaudet this is a great question. I do think that this kind of situation exists today. As a champion of a new API, how do you decide to have something on a worker or worklet or not? I believe the burden falls onto the champions, and the editors can simply raise issues as they are reviewing the spec changes. Is there a centralized place where we keep guidelines for champions?

[ptomato]

I've tried to create a coherent proposal for this in w3ctag/design-principles#509. (It hasn't had any comments yet from the TAG.) This moves away from the "confidentiality" invariant and towards a guideline that only purely computational interfaces not depending on an event loop should have Exposed=*. Please let me know what you think.

[ptomato]

I've written a draft text for the principle in w3ctag/design-principles#510. If we are happy with that text, I believe it's sufficient to answer the question about how the invariants are maintained. The invariants described there are simple enough that it's easy to evaluate new interfaces against them.

[ptomato]

I think the TAG design principles is a sufficiently good place to keep this guidance and we can consider this issue addressed.