This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Netflix-style services need to be able to load the media file from a CDN, which implies that the case where the media file is different-origin with the document that hosts the media element has to work. However, the spec fails to cover how the same-origin policy applies in this case. The API exposes the initialization data and key IDs from the media file to the origin of the media element. The spec should: 1) Explicitly document what information gets exposed cross-origin. AND 2) Either: a) Explain why exposing that information cross-origin is harmless considering the threats that the same-origin policy generally defends against. OR b) Make the cross-origin case not work by default and explain how CORS can be used to make it work.
I would expect that the existing HTML5 spec language regarding access to the media file in the cross origin case would apply. That is, EME would not change this semantic. In other words, step (4) of the resource fetch algorithm for a media element [1] still applies (with no change). [1] http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#concept-media-load-resource I suppose it wouldn't hurt to add an informative note pointing this out.
The existing spec indeed says how CORS interacts with the fetch. However, EME should say how the CORS status affects the EME API.
Henri - why is this different in character from the information about the media file provided by the media element itself ? Such as duration, number and type of tracks, timed text cues etc. [I'm not saying your point is wrong, but I just want to understand exactly how you think EME introduces a new problem here].
(In reply to comment #3) > Henri - why is this different in character from the information about the > media file provided by the media element itself ? I'm not sure if initialization data is different in character. That's why I gave alternatives a and b under point 2. Even if initialization data and key IDs are deemed similar to duration, I think the spec should explicitly acknowledge the cross-origin information leak like the main spec does for duration. > Such as duration, number > and type of tracks, timed text cues etc. Per spec, text cues are not exposed without CORS.
(In reply to comment #4) > (In reply to comment #3) > > Henri - why is this different in character from the information about the > > media file provided by the media element itself ? > > I'm not sure if initialization data is different in character. That's why I > gave alternatives a and b under point 2. Even if initialization data and key > IDs are deemed similar to duration, I think the spec should explicitly > acknowledge the cross-origin information leak like the main spec does for > duration. > > > Such as duration, number > > and type of tracks, timed text cues etc. > > Per spec, text cues are not exposed without CORS. Ok, it sounds to me like the exposure of initialization data and key ids is similar to exposure of text cues (they could contain arbitrary information). Can we just cut&paste or refer to text from the Media Element specification ?
(In reply to comment #5) > Ok, it sounds to me like the exposure of initialization data and key ids is > similar to exposure of text cues (they could contain arbitrary information). OK. > Can we just cut&paste or refer to text from the Media Element specification ? I suggest doing the following spec edits instead of cutting and pasting: Under 5. Algorithms under 5.1 Encrypted Block Encountered under step 7. Key Presence change the case "If there is an event handler for needkey" to "If there is an event handler for needkey and media data is CORS-same-origin". Under 5.2. Potentially Encrypted Stream Encountered change step 6. Need Key to have a <dl class="switch"> where the first entry is labeled "If media data is CORS-same-origin" and the current text there and the second entry is "Otherwise": "Abort media element's resource fetch algorithm and run the steps to report a MEDIA_ERR_ENCRYPTED error." Under the steps for createSession, alter substep 2 or outer step 6 so that the "Otherwise" branch (the one that fires MediaKeyError and aborts) is taken if the media data is not CORS-same-origin. Under the steps for update(key), alter step 6 to jump to step 8 if next message is not null but media data is not CORS-same-origin. Add a non-normative section under introduction saying that EME exposes information from the embedded media data to the embedding origin, so in order for the API to fire keymessage and keyneeded events, media data needs to be same-origin with the embedding page or use the crossorigin attribute on the media element and CORS headers on the media data response to authorize cross-origin information exposure. Where "media data" in all cases is linked to http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#media-data
(In reply to comment #6) > substep 2 or outer step 6 s/or/of/
And "CORS-same-origin" should link to http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#cors-same-origin
> Add a non-normative section under introduction saying that EME exposes > information from the embedded media data to the embedding origin, so in > order for the API to fire keymessage and keyneeded events, media data needs > to be same-origin with the embedding page or use the crossorigin attribute > on the media element and CORS headers on the media data response to > authorize cross-origin information exposure. I want to make sure I understand which origins you are concerned about. There are at least three domains (possibly more) that we are talking about here. * The application domain * The media data domain * The key server domain(s) Are you looking for CORS compliance across all these domains? If so -- this runs into a problem I have brought up previously, namely that the application may not know ahead of time what key server domain(s) will be contacted. Can we exclude the key server domain(s) from this discussion?
(In reply to comment #9) > > Add a non-normative section under introduction saying that EME exposes > > information from the embedded media data to the embedding origin, so in > > order for the API to fire keymessage and keyneeded events, media data needs > > to be same-origin with the embedding page or use the crossorigin attribute > > on the media element and CORS headers on the media data response to > > authorize cross-origin information exposure. > > I want to make sure I understand which origins you are concerned about. > There are at least three domains (possibly more) that we are talking about > here. > > * The application domain > * The media data domain > * The key server domain(s) > > Are you looking for CORS compliance across all these domains? > > If so -- this runs into a problem I have brought up previously, namely that > the application may not know ahead of time what key server domain(s) will be > contacted. Can we exclude the key server domain(s) from this discussion? Communication with the key server (or indeed any other server) is not in scope of our specification. It's something the script may do according to the usual rules for scripts contacting servers. If you use XmlHttpRequest then the rules for that are documented in the XmlHttpRequest specification (and indeed do follow the same-origin policy, CORS etc.) Note that CORS does not require the origin of a script to know in advance which origins it will need to contact but rather requires those origins to authorize others to contact them (which they could do by advanced knowledge or through some kind of real-time authorization).
Ok. Thanks for the clarification.
(In reply to comment #9) > * The application domain > * The media data domain > * The key server domain(s) This is about an information leak from the media data origin to the application origin.
This was discussed at the April 2nd telecon: http://www.w3.org/2013/04/02-html-media-minutes.html#item02 There was discussion that the traditional src and MSE scenarios might be different or at least the origin for the media data is defined differently. Bug 21536 was filed to ensure MSE covers this. Do people have feedback on the proposed text in Comment 6? (Note that the existing 5.2 text may change as a result of bug 16857 so we may want to resolve that first.)
Adrian has started working on this.
Changeset -> https://dvcs.w3.org/hg/html-media/rev/69dbfb8baca8
Thanks. The "or use the crossorigin…" bit at https://dvcs.w3.org/hg/html-media/rev/69dbfb8baca8#l1.19 is confused, though. A CORS-enabled fetch labels the obtained resource as CORS-same-origin or CORS-cross-origin, so using the crossorigin attribute is part of making a cross-origin resource CORS-same-origin. I suggest replacing " or use the crossorigin attribute on the media element and CORS headers on the media data response to authorize cross-origin information exposure." with ". If media data is cross-origin with the embedding document, use the crossorigin attribute on the media element and CORS headers on the media data response to make it CORS-same-origin."
Adrian says reopen to make the change
(In reply to comment #15) > Changeset -> https://dvcs.w3.org/hg/html-media/rev/69dbfb8baca8 Thanks. A few minor comments. * (As long as we enforce the standard paths and don't allow side channels or other sources of data,) keymessage should be implicitly same origin. (Any type of stored or shared keys could cause problems, but that should probably be addressed explicitly.) * Not changing keymessage also keeps all the origin/media data issues in HTMLMediaElement and out of MediaKeySession. * The subject for the text beginning with "or use the crossorigin attribute..." is "media data". Should the subject be the UA, application, author, or something else? * The crossorigin anchor should be "attr-media-crossorigin" instead of "attr-img-crossorigin". * Do we need to address MSE (and XHRs) or is that implicitly (and sufficiently) addressed by crossorigin? * Did step 5 of section 4.2 need to be changed? We don't fire an event, so origin seems irrelevant.
(In reply to comment #17) > Adrian says reopen to make the change Updates -> https://dvcs.w3.org/hg/html-media/rev/5c8bb7219191 Not sure if I covered all of David's comments so not resolving yet.
(In reply to comment #18) > * The subject for the text beginning with "or use the crossorigin > attribute..." is "media data". Should the subject be the UA, application, > author, or something else? I think I changed this in the modified text. > * The crossorigin anchor should be "attr-media-crossorigin" instead of > "attr-img-crossorigin". Thanks. Fixed. > * Do we need to address MSE (and XHRs) or is that implicitly (and > sufficiently) addressed by crossorigin? I don't think we need to do anything explicit in EME. In MSE we directly state how to find the origin from the Origin of Blob URIs defined in the File API and I believe everything flows end-to-end. > * Did step 5 of section 4.2 need to be changed? We don't fire an event, so > origin seems irrelevant. That's a good question. Perhaps we can't get to this point if the media data is not already CORS same origin?
Thanks. We should find the answer to the question about section 4.2 step 5. Other than that, just a nit that we might want to replace "needs to be" with "must be". Henri, any other comments?
Hopefully this closes out this issue: https://dvcs.w3.org/hg/html-media/rev/e9e9690472e0
The createSession() algorithm currently says [1]: "If a request is successfully generated and the media data is CORS-same-origin". I don't think the second half of that statement is necessary or correct since the initData was provided by the application in the createSession() call. I plan to remove it. [1] https://dvcs.w3.org/hg/html-media/raw-file/8cd813d0a7b5/encrypted-media/encrypted-media.html#dom-createsession
I think the concern here was that the defaultURL associated with the key request is going to be provided by the CDM and yet may be sent data from the media origin (namely the initData). This could be seen as a leak. Maybe the wording needs to be adjusted however.
The application provides the initData, which contains the defaultURL (if any), and the application will send the keymessage to the server (either its own or the one specified by defaultURL). Ultimately, it is the application that is sending the information, which it already had access to, and normal CORS rules should apply, right?
(In reply to David Dorwin from comment #25) > The application provides the initData, which contains the defaultURL (if > any), and the application will send the keymessage to the server (either its > own or the one specified by defaultURL). Ultimately, it is the application > that is sending the information, which it already had access to, and normal > CORS rules should apply, right? The defaultURL is provided by the CDM. It may or may not have any direct relationship to the initData. However I see your point -- any information sent by the application is subject to CORS restrictions anyway. It makes sense to remove that text. I would also change step 2. of the procedure to say that the CDM provides the defaultURL based on the initData and leave it at that. Since the initData is CDM specific that is about all you can say.
I made the change in comment #23 in https://dvcs.w3.org/hg/html-media/rev/5369218d899b. (In reply to Joe Steele from comment #26) > I would also change step 2. of the procedure to say that the CDM provides > the defaultURL based on the initData and leave it at that. Since the > initData is CDM specific that is about all you can say. initData is container-specific, though the traditional use for CENC has been protection system-specific. I changed the text in https://dvcs.w3.org/hg/html-media/rev/9060ac54fe3d to be more generic while still implying that the defaultURL should come from the initData. I also removed the potential interpretation that the defaultURL not needs to be explicitly for the specific keySystem.
The update() algorithm contained what appears to be a similarly unnecessary check: > If next message is not null and the media data is not CORS-same-origin, jump to the Error step below and perform the task failed steps. I removed it in https://dvcs.w3.org/hg/html-media/rev/82a472ad7ef9
One of the original changesets for this bug (https://dvcs.w3.org/hg/html-media/rev/69dbfb8baca8) introduced a second instance of reporting MEDIA_ERR_ENCRYPTED. This one was introduced in 4.1 First Time a Key Reference is Encountered when needkey is to be fired but media data is not CORS-same-origin. Previously, the error could only be reported when a key was actually needed in 4.2. Encrypted Block Encountered. Should we really report an error when the first key reference is encountered or should we wait until an encrypted block is encountered (even though we cannot report a needkey event). It's possible playback could proceed without error (i.e. using only unencrypted streams within the media data. Also, having one place to report errors is simpler for impelementors.
(In reply to David Dorwin from comment #29) > Should we really report an error when the first key reference is encountered > or should we wait until an encrypted block is encountered (even though we > cannot report a needkey event). It's possible playback could proceed without > error (i.e. using only unencrypted streams within the media data. Also, > having one place to report errors is simpler for impelementors. Having looked at this, I have a different proposal: 1) We should change step 3 of the algorithm in 4.1 (First time a key reference is encountered) and instead of throwing an error, we should send the needkey event with empty initdata. This allows apps that can get the initdata from a different source to know the key reference has been reached. 2) We should remove the error from step 1 of 4.2 (encrypted block encountered) if keys is null. This means that applications that see encrypted content but haven't handled needkey or otherwise tried to provide keys will stall playback instead of throwing an error. I think this is acceptable. If we do this then we can remove MEDIA_ERR_ENCRYPTED from the spec.
Adrian's proposals sound good to me. It would be nice for applications to be able to detect that they won't be able to play the media, but this proposal simplifies a lot of things. Maybe the solution to bug 18515 will address that one remaining issue.
(In reply to Adrian Bateman [MSFT] from comment #30) > Having looked at this, I have a different proposal: > > 1) We should change step 3 of the algorithm in 4.1 (First time a key > reference is encountered) and instead of throwing an error, we should send > the needkey event with empty initdata. This allows apps that can get the > initdata from a different source to know the key reference has been reached. > > 2) We should remove the error from step 1 of 4.2 (encrypted block > encountered) if keys is null. This means that applications that see > encrypted content but haven't handled needkey or otherwise tried to provide > keys will stall playback instead of throwing an error. I think this is > acceptable. > > If we do this then we can remove MEDIA_ERR_ENCRYPTED from the spec. I made these changes. https://dvcs.w3.org/hg/html-media/rev/cb3a898bcd64
For future reference, https://dvcs.w3.org/hg/html-media/rev/424cf745ef6a removes some additional text related to the changeset above.