The explicit secure context check is not needed

[pozdnyakov]

The explicit secure context check at https://w3c.github.io/sensors/#construct-sensor-object is not needed as sensor interfaces already have [SecureContext] specifier.

[anssiko]

The Secure Contexts spec indeed states:

Authors could alternatively ensure that sensitive APIs are only exposed to secure contexts by guarding them with the [SecureContext] attribute.

Furthermore, the WebIDL spec states:

If the [SecureContext] extended attribute appears on an interface, partial interface, interface mixin, partial interface mixin, namespace, partial namespace, interface member, interface mixin member, or namespace member, it indicates that the construct is exposed only within a secure context. The [SecureContext] extended attribute must not be used on any other construct.

Notably, "exposed" (emphasis mine) in the above normative text does not link to its formal definition, thus the behavior is currently underspecified AFAICT.

The following informative note that follows the normative text references the formal definition of "exposed", but by virtue of it being a note, it cannot be counted on:

Note: Whether a construct is available only in secure contexts influences whether it is exposed in a given ECMAScript global environment.

Ping @tobie to confirm whether the WebIDL spec should link to the formal definition of exposed in the normative prose in the [SecureContext] section.

What comes to the proposal itself, it looks good assuming the WebIDL spec is clarified.

[tobie]

Notably, "exposed" (emphasis mine) in the above normative text does not link to its formal definition, thus the behavior is currently underspecified AFAICT.

Yes, that's because it's the generic computer science term that's used here, not the dfn.

The spec's pretty explicit in the "exposed" dfn, and then again in the bindings. The note x-ref is good enough imho, as the spec is supposed to be taken as a whole (see conforming implementation).

That said, I just fixed a small normative nit with the "exposed" dfn and turned it into an algorithm, which I think makes it stand out more.

[anssiko]

@tobie, thanks, it would be clearer if the generic term "exposed" and the "exposed" formal definition would be easier to distinguish from each other, optimally not share the same name. There are many occurrences of "exposed" using both the meanings in WebIDL (and elsewhere), so that refactor is out of scope for this particular issue I believe.

To fix this ambiguity within the [SecureContext] section, how about rename:

it indicates that the construct is exposed only within a secure context.

Into:

it is available only in secure contexts.

[tobie]

Yeah. Mind filling an issue?

[anssiko]

Filed whatwg/webidl#465