Require explicit enabling of EME in nested contexts

[ddorwin]

Nested contexts/iframes should only be able to access EME if the embedding app explicitly enables it. The reasons are similar to other features that [will] have such limitations. Specifically, this helps mitigate many security and privacy concerns, especially where the top-level context is not complicit. This includes some of the concerns in #101.

Feature Policy appears to be the way forward for these purposes.

The default policies would be:

• Enable: self for top-level browsing context, and null for nested browsing context
• Disable: null

The changes to the EME spec itself would likely be similar to those proposed for Web MIDI. Basically, the promise returned by requestMediaKeySystemAccess() would be rejected with SecurityError if EME is disabled.

[ddorwin]

w3c/webappsec-permissions-policy#40 is tracking this on the Feature Policy side.

[ddorwin]

The issue above is resolved and EME is now included in the Feature Policy spec: https://wicg.github.io/feature-policy/#eme-feature.

The name is currently "eme", though I think "encrypted-media" would be better. See w3c/webappsec-permissions-policy#40 (comment).

[ddorwin]

The correct link is now https://github.com/WICG/feature-policy/blob/gh-pages/features.md#encrypted-media. Also, the name has been changed to "encrypted-media".

[ddorwin]

FYI, Blink/Chrome will be deprecating on-by-default permissions in cross-origin iframes for several features, including EME, in Chrome 61. These features will need to be explicitly allowed in Chrome 63. See https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes for details.

We'll post a PR for the relevant changes to the EME algorithms. (This will not officially be part of EME v1.0.)

[ddorwin]

PR #432

[raymeskhoury]

FYI, Blink/Chrome will be deprecating on-by-default permissions in cross-origin iframes for several features, including EME, in Chrome 61. These features will need to be explicitly allowed in Chrome 63

Just an update: Chrome 64 is now the target for these changes to land.

[ddorwin]

To clarify, this change does not affect permissions (consent). The change is that the requestMediaKeySystemAccess() call will reject by default in cross-origin iframes. As shown in PR #432, this happens in the first step, well before consent is checked.

[luwes]

Sorry to ask here but we ran into a bug related to this ticket with the Vimeo player.

It started happening for Chrome 83 on Mac and Windows. For a cross-domain iframe embed with MSE and HDCP enabled playback is blocked while there is no external monitor connected.

The video plays for a few seconds and the key status returns usable but then after a bit it changes to output-restricted.

Are there any known changes made to make the cross-domain iframe embed with MSE and HDCP more secure?

I did some searching but didn't come up with much.
Our embeds have the required allow attribute.

<iframe allow="encrypted-media; autoplay; fullscreen" src="https://..." frameborder="0"></iframe>

I tried adding the * after the properties like encrypted-media *; but it didn't work.

[joeyparrish]

@luwes, that sounds like a potential Chrome or Widevine issue. I would suggest you file on crbug.com and post the link here so interested parties can track it. @xhwang-chromium, can you confirm if this should be filed on crbug?

[luwes]

thanks for the quick reply @joeyparrish, yes it might be a Chrome bug then. Hoping it's not :)

Ok, I will report it on crbug.com.

[xhwang-chromium]

luwes: Please file a crbug and assign to xhwang@chromium.org and I'll help you find the owner.

[luwes]

thanks @xhwang-chromium posted a bug report here, https://bugs.chromium.org/p/chromium/issues/detail?id=1087475

(not sure how I could assign anyone)