RE: Technical Review of EME (DRM in HTML5)

There was some interesting discussions recently about the EME FPWD CfC and many views were raised.  I have tried to note many of the views, see: http://www.w3.org/community/pua/wiki/Digital_Rights_Management  It is not trivial to develop a concise position, but I'll be working on it.

The W3C has already decided that DRM is in scope for web standards.  It's disturbing reading some of the supporting messages - there is no regard at all for the principles that guide much of the standards work, such as designing for privacy, or designing for the user first.  The proponents feel that if there is a business need for users to trade off their security or privacy then this is a valid technical need.  This position would appear to run contrary to the existence of a privacy interest group, and undermine any credibility that the W3C had in the area of privacy.

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
> >> 
> >> 
> 
>