- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Oct 2017 07:02:23 +0000
- To: public-device-apis-log@w3.org
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