[Bug 20960] EME is not limited to video.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20960

--- Comment #10 from Fred Andrews <fredandw@live.com> ---
(In reply to comment #8)
> > This is unique to the EME because of the back channel that EME provides from
> > the CDM to the server.  An image decoder or a video decoder do not require a
> > back channel.
> 
> Thank you. That makes the threat you are worried about more clear. 
> 
> Let me restate to make sure I understand:
> * There is a bi-directional channel to the CDM from the web application
> * This allows the web application to funnel all data and events the web
> application sees to the CDM. 
> * Because the CDM can implement any code it wants, it could implement an
> HTML engine.
> * The combination of these two things allows a CDM to render content from
> the web application in an alternate HTML engine and process events for it

It is also important to note that:

* The web application can tunnel the secret communication between the CDM and
the server.  The combination of the EME spec. plus a simple web app. tunnel, as
shown in the EME examples, creates a secret bi-directional channel from the CDM
to the server.

* Because the CDM can implement video DRM it is likely that it can implement
DRM of general HTML content.

> If we replace "CDM" with "video codec" in the above argument, I believe we
> have the same situation. Video elements have a bi-directional channel as
> well in the HTMLMediaElement text track support (textTracks and
> addTextTrack).

No, not at all. A video codec does not have a back channel, or a secret back
channel, or the privilege to implement DRM.

This does appear to be a technical matter that we could explore further and
likely come to some technical agreement on. Technical tests would be:

* demonstrate that a video codec without a back channel can implement strong
DRM?

* demonstrate that a CDM can implement a general DRM enabled web engine.

> > DRM would be attractive to a wider range of content authors than just video 
> > authors, 
> 
> I agree with this.
> 
> > and if a CDM can support DRM then there would be demand for more 
> > general HTML support within the CDM - I suggest it's inevitable that a CDM 
> > would be written that supports a relative comprehensive HTML engine.  
> 
> I don't agree with this. 

You appear to agree that it would be attractive to content authors, and it
appears to be technically possible, so could you elaborate on why you do not
believe this would be done?

> The described threat would require the UA to include a CDM with this
> behavior.

Agreed, but this is rather obvious.  Perhaps this leads into CDM management.

> There is no requirement that any UA include any specific CDM other
> than ClearKey (which does not have this behavior).

ClearKey could be un-bundled from EME so the existence of 'ClearKey' is
probably not a defense.

> A much shorter path to
> this scenario is that the UA provides a direct non-standard method to turn
> on "DRM" for the web page and does not include an entire alternate HTML
> engine. Both scenarios require collusion by the UA implementer and both rely
> on behavior outside of the specification.

And if someone proposes this then I will object to it too, but this is not the
matter at hand.

If a DRM 'hole' is created by EME that can support more general DRM of content
then developers with exploit it. 

> Having said this -- it sounds like it would satisfy your concern to have
> some spec text that says something along the lines of "The CDM must not
> implement a user agent.". Do you have some alternate text to suggest?

This constraint would need to be verifiable by the user.  It is not clear how
this would be possible in a way that is consistent with the design of DRM -
there have been suggestions that the CDM be standardized, independently
implementable, support open source, etc that would go some way.   Technically,
removing the support for a back channel would go some way.  Moving the CDM
within the scope of W3C standardization would allow review. Do you have other
suggestions?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 20 February 2013 23:33:19 UTC