- From: ddorwin via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Aug 2016 22:51:32 +0000
- To: public-html-media@w3.org
ddorwin has just created a new issue for https://github.com/w3c/encrypted-media: == Restrict all interfaces to secure contexts == #271 added `[SecureContext]` to `requestMediaKeySystemAccess()`, which effectively makes use of the APIs and CDM impossible on insecure contexts. However, all the other dictionaries, interfaces, and partial interfaces will still be visible to insecure contexts. This is a bit strange since feature detection using `if (MediaKeys)` would succeed while `if (navigator.requestMediaKeySystemAccess)` would not. Probably the correct/consistent thing to do would be to add `[SecureContext]` to all IDL blocks, including `partial interface HTMLMediaElement`. This is easy and straightforward. However, that alone would not prevent the `encrypted` and `waitingforkey` events from being fired even though the `on...` attributes would not be usable. I see three options: 1. Abort the relevant algorithms when in an insecure context, preventing the events from being fired. 1. Fire the events but leave the `on...` attributes inaccessible. 1. Fire the events and allow use of the `on...` attributes but leave everything else inaccessible. (This is accomplished by adding `[SecureContext]` to the `mediaKeys` and `setMediaKeys` members rather than the entire `partial interface`.) (2) and (3) allow players on insecure contexts to detect but not handle encrypted content, which seems good. (2) seems like unexpected behavior and limits the benefits in the previous sentence. Therefore, I am leaning towards (3). @mikewest, any comments on the preferred behavior? Please view or discuss this issue at https://github.com/w3c/encrypted-media/issues/289 using your GitHub account
Received on Tuesday, 2 August 2016 22:53:35 UTC