search

web-platform-tests / wpt

Test suites for Web platform specs — including WHATWG, W3C, and others
https://web-platform-tests.org/
Other
4.89k stars 3.06k forks source link

[EME] *mp4-unique-origin.html doesn't enforce anything in the EME spec #4136

Open cpearce opened 7 years ago

cpearce commented 7 years ago

clearkey-mp4-unique-origin.html, and its DRM variant, test that EME can't be used on a "unique origin". I don't see anything in the current EME spec that says that a unique origin can't use EME.

Technically, there's no reason why EME can't work on a unique origin. It would seem this test is testing Chrome specific behaviour? This test came from the Google test suite.

However, the spec does say that EME is only usable inside a "secure context", and as per the Secure Contexts spec a data: URI inside a sandboxed iframe is not considered secure. But there is disagreement as to whether a data: URI inside a sandboxed iframe should be considered an insecure context, see Secure Context Spec issue 26.

It does not seem sensible for the EME test suite to be enforcing behaviour that is contested in another unfinished spec.

We should either remove this test, or change it such that it's insulated from the general question as to which contexts are considered secure.

cpearce commented 7 years ago

@ddorwin: thoughts? Can we remove clearkey-mp4-unique-origin.html and drm-mp4-unique-origin.html?

ddorwin commented 7 years ago

Yes, this was added to Blink for a Chrome-specific reason. The issue was that we could not check permissions and maybe handle storage correctly for "unique origins," which could occur for things like file://. I'm not sure how much, if any, of that is spec'd.

Although it is a corner case, it would be nice to have consistency across implementations. Perhaps we should open a vNext spec issue and disable these pending resolution of that issue.

/sub @jrummell-chromium

ddorwin commented 7 years ago

@cpearce, what do you think? Do you want to create a PR?

jrummell-chromium commented 6 years ago

Section 10.4.2 in "iframe Attacks" (https://w3c.github.io/encrypted-media/#mitigations-0) notes:

should not allow hosting frames to invoke the APIs defined in this specification.

So should the test be updated to verify that requestMediaKeySystemAccess is not available in the iframe rather than checking that mediaKeys fails to create? This is what the similar test in Chromium now does (https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/media/encrypted-media/encrypted-media-unique-origin.html).

ddorwin commented 6 years ago

The quoted recommendation is for authors of applications and is not something enforceable by implementations.