Re: Comments on w3ctag/eme/

Hi Henri,

Thanks for taking the time to look at the draft opinion and your comments. You’ll have seen that I’ve asked other TAG members to address some of them.

> > Content that is accessed through a plugin is also rarely accessible to other
> > technologies in use on the web. It cannot be linked to from other pages
> > (reducing the number of links that could be made, and thus reducing the
> > value of the web).
>  
> This depends on whether the entire site navigation is done within the
> plug-in. It's probably more common for a plug-in to appear on each
> linkable page as on YouTube than for the entire site navigation to be
> done within the plug-in. On the other hand, it's quite possible to put
> the entire site navigation inside a plug-in-free Open Web Platform  
> program.
>  
> Therefore, I don't think non-linkability is a major plug-in-specific  
> disadvantage.

Fair enough.

> > The Encrypted Media Extensions defined in the Encrypted Media Extensions
> > Working Draft aim to provide a common, platform independent interface to
> > enable sharing of encrypted content on the web.
>  
> I think this characterization is shameful.
>
> As I have said earlier on this list, it is technically correct that
> EME involves "encrypted" content, but talking about encryption evokes
> the wrong connotations about who the adversary is. (Typically,  
> encryption is used against a third party on the network. In the case
> of EME, the user is the adversary against whom encryption is used.)  
> Describing the "aim" of EME without saying "DRM" up front is grossly  
> misleading.
>  
> Furthermore, saying that the "aim" of EME is to "enable sharing of
> encrypted content" is Newspeakish, when the stated goal of DRM is to
> *disable* sharing of content.

OK, sorry this offended you. I’ve replaced with a direct quote from the EME spec and the HTML charter, and a characterisation that I think addresses your concern.

> > So when considering encrypted media on the web, we have to ensure that
> > the "black box" of encryption technologies is platform independent, as well
> > as the interface that surrounds it.
>  
> Calling DRM implementations "encryption technologies" amounts  
> to weasel words.

OK, obviously a bad choice of wording on my part. I’ve switched to calling DRM DRM.

> > The EME specification must ensure platform independence, for example
> > by specifying the use of open standard encryption algorithms.  
>  
> This statement is naïve in a way similar to diagnosing the
> interoperability problems with .doc files to stem from insufficient  
> use of XML when .docx retains the same higher-level complexity.  
>  
> While EME leaves the encryption part open-ended, both the MP4 CENC and
> WebM encryption methods non-normatively (because the W3C doesn't in
> general reference video formats normatively) referenced by EME are
> based on 128-bit AES-CTR, which is publicly documented and
> standardized.
>  
> Open standard encryption *algorithms* don't result in platform  
> independence, when the encryption *keys* are withheld from  
> you based on policies that discriminate by platform.
>  
> The design of EME is primarily informed by PlayReady. Other DRMs are
> free to adapt to PlayReady's shape to become EME-compatible, but it's
> instructive to look at PlayReady, since EME is made for
> PlayReady-shaped DRMs. PlayReady is technically platform-independent,  
> but the policy level paints a different picture. Take a look at  
> http://go.microsoft.com/fwlink/?LinkID=122671 :
> Section 2.1 says that the key parts of the license don't apply to "PC
> Software", which is defined in Section 1.5 to include, for example,  
> software running on Windows, OS X, desktop Linux and Solaris. Now,
> there's a different SDK for Windows with different terms, but tough
> luck for non-Windows PC Software (except Microsoft's own Silverlight  
> for Mac).
>  
> And that's ignoring royalties and such.
>  
> I don't know what crypto algorithms PlayReady uses apart from AES-CTR,
> but the public documentation strongly suggests that a PKI is involved.
> It would be surprising if such a PKI wasn't based on open-standard  
> crypto algorithms such as RSA. But even if you implemented all the
> right algorithms, your implementation wouldn't actually have utility
> unless you got your keys signed such that they chain to the root of
> trust of the PKI. That is, policy is enforced by refusing to sign your
> keys—not by algorithms being non-standard.

OK. The goal of this section is to try to outline what a truly platform-independent mechanism for playing protected content might look like. I’d really appreciate your help to improve it. I’ve added some wording about it being possible to get hold of the keys in an open way as well, but this is not my area of expertise and there may be additional points that should be made. Suggestions of concrete textual changes are particularly welcome.

The changes that I’m suggesting to address the points above are in a pull request at:

  https://github.com/w3ctag/eme/pull/1

so that they can be discussed more easily.

Thanks,

Jeni
--  
Jeni Tennison
http://www.jenitennison.com/

Received on Saturday, 22 February 2014 14:49:56 UTC