Bug 21203 - EME leaks information cross-origin
EME leaks information cross-origin
Status: RESOLVED FIXED
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions
unspecified
All All
: P2 normal
: ---
Assigned To: Adrian Bateman [MSFT]
HTML WG Bugzilla archive list
:
Depends on: 16857 21536
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-06 09:21 UTC by Henri Sivonen
Modified: 2014-01-28 01:49 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henri Sivonen 2013-03-06 09:21:38 UTC
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.
Comment 1 Glenn Adams 2013-03-06 14:55:00 UTC
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.
Comment 2 Henri Sivonen 2013-03-06 15:24:29 UTC
The existing spec indeed says how CORS interacts with the fetch. However, EME should say how the CORS status affects the EME API.
Comment 3 Mark Watson 2013-03-06 15:43:16 UTC
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].
Comment 4 Henri Sivonen 2013-03-06 15:56:58 UTC
(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.
Comment 5 Mark Watson 2013-03-06 16:50:06 UTC
(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 ?
Comment 6 Henri Sivonen 2013-03-07 09:40:22 UTC
(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
Comment 7 Henri Sivonen 2013-03-07 09:41:15 UTC
(In reply to comment #6)
> substep 2 or outer step 6

s/or/of/
Comment 8 Henri Sivonen 2013-03-07 09:42:27 UTC
And "CORS-same-origin" should link to http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#cors-same-origin
Comment 9 Joe Steele 2013-03-08 21:38:17 UTC
> 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?
Comment 10 Mark Watson 2013-03-08 21:46:22 UTC
(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).
Comment 11 Joe Steele 2013-03-08 21:55:47 UTC
Ok. Thanks for the clarification.
Comment 12 Henri Sivonen 2013-03-11 15:23:50 UTC
(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.
Comment 13 David Dorwin 2013-04-24 17:24:39 UTC
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.)
Comment 14 David Dorwin 2013-05-21 15:27:11 UTC
Adrian has started working on this.
Comment 15 Adrian Bateman [MSFT] 2013-06-04 15:02:28 UTC
Changeset -> https://dvcs.w3.org/hg/html-media/rev/69dbfb8baca8
Comment 16 Henri Sivonen 2013-06-05 11:11:45 UTC
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."
Comment 17 Joe Steele 2013-08-20 15:15:00 UTC
Adrian says reopen to make the change
Comment 18 David Dorwin 2013-08-27 04:29:40 UTC
(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.
Comment 19 Adrian Bateman [MSFT] 2013-08-27 15:00:17 UTC
(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.
Comment 20 Adrian Bateman [MSFT] 2013-08-27 18:30:54 UTC
(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?
Comment 21 David Dorwin 2013-09-10 00:53:20 UTC
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?
Comment 22 Adrian Bateman [MSFT] 2013-09-17 05:23:29 UTC
Hopefully this closes out this issue:
https://dvcs.w3.org/hg/html-media/rev/e9e9690472e0
Comment 23 David Dorwin 2013-10-26 00:16:23 UTC
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
Comment 24 Joe Steele 2013-10-26 01:15:18 UTC
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.
Comment 25 David Dorwin 2013-10-26 04:14:06 UTC
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?
Comment 26 Joe Steele 2013-10-28 18:19:00 UTC
(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.
Comment 27 David Dorwin 2013-10-28 20:14:55 UTC
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.
Comment 28 David Dorwin 2013-10-28 23:26:09 UTC
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
Comment 29 David Dorwin 2013-11-05 02:04:22 UTC
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.
Comment 30 Adrian Bateman [MSFT] 2013-11-15 03:37:46 UTC
(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.
Comment 31 David Dorwin 2013-12-06 23:08:20 UTC
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.
Comment 32 Adrian Bateman [MSFT] 2013-12-17 22:44:32 UTC
(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
Comment 33 David Dorwin 2014-01-28 01:49:32 UTC
For future reference, https://dvcs.w3.org/hg/html-media/rev/424cf745ef6a removes some additional text related to the changeset above.