Re: [sensors] The explicit secure context check is not needed

The [Secure Contexts spec][1] 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][2] 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][3], 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][3] in a given ECMAScript global environment.

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

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

[1]: https://w3c.github.io/webappsec-secure-contexts/#new
[2]: https://heycam.github.io/webidl/#SecureContext
[3]: https://heycam.github.io/webidl/#dfn-exposed

-- 
GitHub Notification of comment by anssiko
Please view or discuss this issue at https://github.com/w3c/sensors/issues/314#issuecomment-337137292 using your GitHub account

Received on Tuesday, 17 October 2017 07:02:31 UTC