RE: Technical Review of EME (DRM in HTML5)

If you want to have input into the CfC FPWD then you will need to act soon.

I have filed are few place-holder bugs for some of the general privacy related
concerns, please see:

Bug 20959 - 
      EME does not prevent a per-user specific CDM
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20959

Bug 20961 - 
      EME depends on privileged access to the users computer which is not technically available.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20961

Bug 20965 - 
      EME results in a loss of control over security and privacy.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965

Bug 20966 - 
      EME design trivializes the demanded loss of control of security and privacy demanded.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20966

These bugs may be merged/split/closed/refocused as the issues are explored.

A collection of notes is available in the link below, including may quotes
from email discussions that seemed relevant:
http://www.w3.org/community/pua/wiki/Digital_Rights_Management

I think this is a very important issue to explore and to try to
communicate well, and any help would be appreciated.

cheers
Fred

> From: runnegar@isoc.org
> Date: Fri, 8 Feb 2013 10:35:06 +0100
> CC: public-privacy@w3.org
> To: fredandw@live.com
> Subject: Re: Technical Review of EME (DRM in HTML5)
> 
> Thank you Fred.
> 
> As we are trying to bring this discussion into the Privacy Interest Group (PING), it would be very helpful if you could concisely set out the issues on this email list.
> 
> Many thanks,
> Christine and Tara
> 
> On Feb 8, 2013, at 2:46 AM, Fred Andrews wrote:
> 
> > Dear Christine,
> > 
> > You might be interested in the following objection from the PUA CG:
> > http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0048.html
> > 
> > I think this is huge privacy and security threat to the web.  I would
> > be ashamed if we passed on a DRM web legacy to the next generation,
> > and this is contrary to the charter of the PUA CG.  I hope you will take
> > up the cause.
> > 
> > cheers
> > Fred
> > 
> > 
> >> From: runnegar@isoc.org
> >> Date: Wed, 6 Feb 2013 20:53:02 +0100
> >> CC: walter.van.holst@xs4all.nl; public-tracking@w3.org; tjwhalen@gmail.com; public-privacy@w3.org
> >> To: npdoty@w3.org
> >> Subject: Re: Technical Review of EME (DRM in HTML5)
> >> 
> >> Thanks Nick.
> >> 
> >> We'll take up your suggestion and see if we can schedule a discussion at the next Privacy Interest Group (PING) call.
> >> 
> >> Christine and Tara
> >> PING co-chairs
> >> 
> >> On Feb 6, 2013, at 11:58 AM, Nicholas Doty wrote:
> >> 
> >>> On Feb 6, 2013, at 2:52 AM, Walter van Holst <walter.van.holst@xs4all.nl> wrote:
> >>> 
> >>>> On 2/3/13 6:33 PM, Manu Sporny wrote:
> >>>>> On 01/30/2013 02:19 AM, Mark Watson wrote:
> >>>>>>>> For some, a simple CDM implementation like clear key decryption 
> >>>>>>>> is sufficient, because they aren't delivering very high value 
> >>>>>>>> content, and key protection isn't necessary.
> >>>>>>> 
> >>>>>>> This contradicts what Mark Watson, one of the editors of the spec,
> >>>>>>> has stated, which is:
> >>>>>>> 
> >>>>>>> "[Clear Key] doesn't constitute any kind of DRM or content 
> >>>>>>> protection scheme."
> >>>>>> 
> >>>>>> You are looking for division where there really is none.
> >>>> 
> >>>> Can somebody explain why this is crossposted, what it is about and why
> >>>> it is relevant to DNT?
> >>> 
> >>> Per my message on February 3rd, I think this message is of more relevance to the public-privacy mailing list than our mailing list, and I tried to move the thread there.
> >>> 
> >>> http://www.w3.org/mid/02B98900-BF0A-476A-A8B3-EEE2249840B6@w3.org
> >>> 
> >>>> I'm genuinely confused and really don't feel like diving into the HTML5
> >>>> intricacies.
> >>> 
> >>> I believe there was a concern from an HTML WG member that a particular privacy issue was arising in a proposed spec for encrypted media extensions. I don't fully understand those details myself, and have asked for more discussion that might shed some light on a privacy review, which I think would be a suitable discussion for the Privacy Interest Group. It could be relevant to the Tracking Preference Expression spec to the extent that we have discussed making the Do Not Track signal accessible to plugins or extensions.
> >>> 
> >>> Thanks,
> >>> Nick
> >> 
> >> 
> 
>