W3C home > Mailing lists > Public > public-html-media@w3.org > September 2016

Re: Formal objections to Encrypted Media Extensions

From: Mark Watson <watsonm@netflix.com>
Date: Thu, 8 Sep 2016 13:04:23 -0700
Message-ID: <CAEnTvdDvUvM=UnTW=j7duALN4ie+iPJ0GRSc2ehD=8BRvSGxkw@mail.gmail.com>
To: devin@devinulibarri.com
Cc: David Singer <singer@apple.com>, Cory Doctorow <cory@eff.org>, Joe Feely <joe.feely@googlemail.com>, Joseph Lorenzo Hall <joe@cdt.org>, Harry Halpin <hhalpin@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>
On Thu, Sep 8, 2016 at 12:11 PM, Devin Ulibarri <devin@devinulibarri.com>
wrote:

> > I think we covered that ground pretty thoroughly then, and I suspect
> no-one will thank us for re-visiting it.
>
> I would be super-happy is this discussion were revisited. I represent
> other educators, my students, and my musician colleagues.
>

​I believe David was referring to the specific issue of a covenant for
security research, as proposed by the EFF, not the general issue of whether
W3C should publish EME.


> Can someone(s) please help me understand how EME will benefit the regular,
> but socially-minded, web user such as myself?
>

​Very generally, before EME, *if* you wished to use a website that employs
DRM ​- such as Netflix - you would be asked to install a plugin - such as
Adobe Flash or Microsoft Silverlight. EME offers such sites the opportunity
to migrate to a different model, in which the DRM component is integrated
with their browser and is constrained in various ways defined by the
specification.

A major advantage to users is that in the EME model, some DRMs can take
advantage of hardware accelerated video decoding, greatly extending battery
life while watching video. In the near future, you will be able to play 4K
video from such sites, the security for which the plugin model would not
have supported. There are other advantages with respect to security and
privacy, compared to the plugin model.

EME is a technical refactoring of functionality which already existed on
the web and will facilitate the eventual deprecation of plugins altogether.
Personally, I don't consider such practical engineering work as
representing some kind of statement on the various political issues that
have been raised, but obviously some people do.

...Mark


>
> Specifically:
>
> How will media consumers benefit from EME?
>
> How will teachers benefit from EME?
>
> And their students?
>
> How will the average musician who is self-publishing on the internet
> benefit from EME?
>
> Also, please explain how DRM may be implemented using EME, and how the
> users from the above examples might experience that DRM in their everyday
> web-surfing experience.
>
> I think, if you answer these questions for me, you will help me understand
> why this is being designed for me, my students, and my colleagues.
>
> Got to go teach some music now!
> Devin
> --
> I am currently away from my computer, my desk and all associated
> conveniences. Please excuse my brevity and any typos.
> www.devinulibarri.com
>
>
> On September 8, 2016 12:14:38 PM EDT, David Singer <singer@apple.com>
> wrote:
>>
>> Hi Cory
>>
>>  On Sep 8, 2016, at 18:07 , Cory Doctorow <cory@eff.org> wrote:
>>>
>>>  Unless, of course, those legislative issues relate to software patents
>>>  and their interference with open standardisation, in which case the W3C
>>>  has proved to be the very best place to address this issue.
>>>
>>
>> Thank you for those nice words about the w3c and its policies!
>>
>>
>>>  The de novo anticircumvention rights that EME hands to members who
>>>  participate in this WG
>>>
>>
>> I don’t think EME hands any rights to anyone. It’s just an interface. But we’re now back in the discussion we held, in depth, leading up to the AC meeting and its panel discussion. I think we
>> covered that ground pretty thoroughly then, and I suspect no-one will thank us for re-visiting it.
>>
>> David Singer
>> Manager, Software Standards, Apple Inc.
>>
>>
>>
Received on Thursday, 8 September 2016 20:04:55 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 September 2016 20:04:56 UTC