The [SecureContext] text is unclear on exposure for interfaces

[jwatt]

The [SecureContext] text currently says:

If the [SecureContext] extended attribute appears on an interface, partial interface, an individual interface member, it indicates that the interface or interface member is exposed only within a secure context ([SECURE-CONTEXTS], section 2).

What does "the interface...is exposed only within a secure context" mean? Does it mean that [SecureContext] implies [NoInterfaceObject] in non-Secure Contexts? Or does it mean that all of an interface's members are only exposed within a secure context? Or both? If the former, that should be explicitly called out. If the latter, the text should be clearer and only talk about member exposure, not interface exposure.

CC @mikewest @bzbarsky

[bzbarsky]

It's both.

Does it mean that [SecureContext] implies [NoInterfaceObject] in non-Secure Contexts?

The relevant normative text is http://heycam.github.io/webidl/#dfn-exposed (which explicitly references the "available only in secure contexts" state) and http://heycam.github.io/webidl/#es-interfaces which says that things that are not "exposed" in the #dfn-exposed sense do not generate properties on the global.

Or does it mean that all of an interface's members are only exposed within a secure context?

The normative text here is http://heycam.github.io/webidl/#SecureContext where it says that for an interface member that doesn't have [SecureContext] specified explicitly:

The interface member is available only in secure contexts if and only if the interface or partial interface the member is declared on is.

and then back to #dfn-exposed referencing this state and the existing infrastructure using #dfn-exposed to control existence of properties for interface members.

[jwatt]

It seems like the word "exposed" in the text I originally quoted should really be linking to #dfn-exposed if the word is being used in its technical sense there.

And regarding:

The normative text here is http://heycam.github.io/webidl/#SecureContext where it says that for an interface member that doesn't have [SecureContext] specified explicitly:

The interface member is available only in secure contexts if and only if the interface or partial interface the member is declared on is.

I, uh, managed to read the text leading into that section as "Whether a constructor..." instead of "Whether a construct..." which unsurprisingly threw me off there. :-/

One other thing that's unclear to me is what the exposure of partial interface members is if [SecureContext] is specified on the non-partial interface but not on the partial interface. Probably if the non-partial interface is [SecureContext] then we want any non-partial interfaces to be [SecureContext] too. In that case it would be good to require that to be explicit in any WebIDL, similar to the way interfaces that inherit from a [SecureContext] interface are also required to be explicitly [SecureContext].

[bzbarsky]

One other thing that's unclear to me is what the exposure of partial interface members is if [SecureContext] is specified on the non-partial interface but not on the partial interface.

http://heycam.github.io/webidl/#SecureContext says:

Otherwise, if the [SecureContext] extended attribute does not appear on a construct, then whether it is available only in secure contexts depends on the type of construct:
...
partial interface
The partial interface is available only in secure contexts if and only if the original interface definition is.

So if the non-partial interface is [SecureContext], then so are all its partial interfaces, whether they claim to be [SecureContext] or not. We could make this explicit, sure, by making it a parse failure if an interface is annotated [SecureContext] but one of its partial interfaces is not...

[jwatt]

Ah, right, thanks. Requiring partial interfaces to be annotated with [SecureContext] if their non-partial interface is would be a bit inconvenient for WebIDL authors but would have the advantage of being clearer to anyone reading the WebIDL. I expect more than a few content authors will end up asking themselves "why isn't this thing visible" when the answer is "because it requires a Secure Context", so requiring WebIDL authors to be explicit about this would be good I think.

[tobie]

It seems adding a [SecureContext] extended attribute on a partial interface has no effects whatsoever. If so, shouldn't we prevent that altogether, much like we prevent adding [Constructor] to partial interfaces?

[tobie]

Okay, so @jyasskin tells me on irc that so [SecureContext] on a partial interface whose's non partial interface doesn't have [SecureContext] is shorthand for marking each members of that partial interface with [SecureContext].

I think that shorthand notation makes things more complicated. I think it's simpler if you limit [SecureContext] to non partial interfaces and members. If [SecureContext] is on a non partial interface, then the whole interface is concerned. If it's on a member, it's just that member.

searchfox.org tells me there's no case of [SecureContext] on anything but members and interfaces. Can we simplify things already?

[bzbarsky]

I think that shorthand notation makes things more complicated.

It's no different from how [Exposed] works. It's pretty helpful in making sure you don't miss members that you're adding, if you just flag your entire partial interface and are done with it.

[tobie]

Oh, well, if [Exposed] already works that way… I guess we can just close this.

[tobie]

I expect more than a few content authors will end up asking themselves "why isn't this thing visible" when the answer is "because it requires a Secure Context",

Well the whole interface will be hidden and will throw with a SecurityError, so that should be pretty explicit.

[domenic]

I just noticed, this issue is very similar: #154

#153 is also slightly related

[jyasskin]

Even if we don't want to forbid [[SecureContext]] on partial interfaces, I think @tobie's confusion is evidence that the existing spec is unclear, and that it'd be worth some of his time to try to clarify it.

[domenic]

@tobie this may be fixed with your recent overhaul; can you check?