[WIP] Use IDL to control if feature is exposed #33
Conversation
|
@raymeskhoury @clelland ptal. any red flags so far? |
|
I think this is looking good -- I'm still thinking about the defaults matrix, but it's making more sense. Also, you should be able to apply the |
'usermedia' controls access to NavigatorUserMedia interface and defaults to enabled by default for top-level browsing context. Nested contexts are default off; top-level browsing context must explicitly enable access to this feature. 'webrtc' controls access to RTCPeerConnection interface and defaults to enabled by default for top-level and nested browsing contexts. Because access to this interface is required to get access to data channels, those are implicitly controlled by this keyword as well (as well as all other webrtc features).
Controls access to the Notification interface and defaults to enabled for top-level browsing contexts. Nested contexts are default off; parent browsing context must explicitly enable the feature. Closes #3.
This way links jump to the top of the section.
Controls access to PaymentRequest interface and defaults to enabled for top-level browsing contexts. Nested contexts are default off; parent browsing context must explicitly enable the feature. See #18.
Controls access to PushManager interface and defaults to enabled for top-level browsing contexts. Nested contexts are default off; parent browsing context must explicitly enable the feature.
Controls access to requestMIDIAccess method and defaults to enabled for top-level browsing context. Nested contexts are default off; parent browsing context must explicitly enable the feature.
Controls access to vibrate method and defaults to enabled for top-level browsing contexts. Nested contexts are default off; parent browsing context must explicitly enable the feature.
Both are enabled by default for top-level and nested browsing contexts. Enforcement is done by integrating with existing HTML/XHR algorithms.
|
This mostly looks good to me. I don't remember us discussing controlling the access to webrtc in iframes, but I guess it can't hurt to have that (default is enabled). Not related to usermedia and webrtc: at first glance I did not see how a chain of embeddings would work. I mean, if the top-level allows feature X for https://foo.com and https://bar.com, an iframe controlled by bar.com could enable or disable feature X for iframes from https://bar.com, but never enable it for other domains? |
|
Looks good to me, but I'l leave to to @alvestrand to say if the token "webrtc" is appropriate for hiding the RTCPeerConnection interface. |
|
Merged. However, note that this does not (yet) reflect the latest discussions around migrating to the whitelist-only model... we'll tackle that once we have consensus on it via separate CLs. |
Preview: https://cdn.rawgit.com/WICG/feature-policy/idl/index.html#features