search

w3c / encrypted-media

Encrypted Media Extensions
https://w3c.github.io/encrypted-media/
Other
180 stars 79 forks source link

Disable EME by default in cross-origin iframes #371

Closed raymeskhoury closed 7 years ago

raymeskhoury commented 7 years ago

We would like to explore disabling EME by default for cross-origin iframes. The idea is that it would be possible for the embedder to re-enable EME using the proposed Feature Policy mechanism.

Note that this issue is mainly just intended to start the discussion about this change. We still need to nail down the spec for feature policy before this can proceed. I'm also not super familiar with the API so guidance is appreciated :).

EME already has a failure mode that occurs as a result of the user denying permission. This same failure mode can be reused but we probably still want to alter the spec to include the additional check to see if the feature is allowed by Feature Policy.

The motivations for this change and a discussion of compatibility risk can be found here: https://docs.google.com/document/d/13dp9xWVyGM8THAQohDOT2mMOTSGLxEhSZEvgpmVLrxU/edit

@ddorwin @clelland

raymeskhoury commented 7 years ago

@ddorwin I'd like to look at modifying the spec to add the checks for this. We basically need to call HTMLs "allowed to use" which is monkey-patched by the FP spec (see https://wicg.github.io/feature-policy/#integration-with-html).

The main question is where to insert the checks. Ideally, wherever we put the FP check would also be the place that user agents have the opportunity to prompt for permission (keeping these 2 things in sync is important in order to keep the permissions story sensible).

Do you have thoughts on where this should go in the flow? I see that there are currently ways to use requestMediaKeySystemAccess() that don't require a permission grant (at least in Chrome). Should we preserve the ability to do this even when the "encrypted-media" feature isn't enabled? If there are no security/privacy concerns with those invocations then it probably makes sense to continue to allow that.

ddorwin commented 7 years ago

I think the behavior should be consistent on all implementations, which would mean blocking regardless of whether user consent is required. In that case, we could reject the promise within the first 5 steps of https://w3c.github.io/encrypted-media/#requestMediaKeySystemAccess.

The spec is currently in PR, so we may not be able to make this change in this version, but a pull request would certainly be welcome and could be merged after v1 is complete.

ddorwin commented 7 years ago

Closing as a duplicate of #364.