- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 24 Feb 2012 15:38:51 +0200
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Mark Watson <watsonm@netflix.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Adrian Bateman <adrianba@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, David Dorwin <ddorwin@google.com>
On Fri, Feb 24, 2012 at 10:55 AM, Charles Pritchard <chuck@jumis.com> wrote: > On 2/24/2012 12:17 AM, Henri Sivonen wrote: > >> The second sentence, no: we describe how to *communicate with* the >> protection system, but we do not describe a protection system. > > Failing to describe the protection system means that your spec fails > to deliver the benefits of interoperability and level playing field > for competition that detailed Royalty-Free specs deliver when they > fully describe the system. That is to say that your proposal fails to > satisfy a major reason for being for W3C specs. > > <video> and <audio> do not specify any interoperability. It's a huge problem that <video> and <audio> aren't interoperable in practice on the codec level. The lack of interoperability shouldn't be taken as a role model. It's a problem that needs fixing but that we haven't managed to fix yet. > <video> and <audio> are intentionally about arbitrary codecs, and not > pushing vendors to have any interop. You have the cause and effect reversed. The spec doesn't define a format, because the vendors are split into two camps and have not managed to agree on a format. > Louis CK did use some DRM, at a cost of several thousand, to tens of > thousands of dollars in added bandwidth costs. > It just wasn't an "encrypted stream". It was a time sensitive "encrypted" > URL. That's not conventionally called DRM. More importantly, it didn't put the burden of implementing the "DRM" on the browsers (or the OSs or hardware that the browsers run on). It's really not helpful to confuse the discussion by calling things that didn't involve sending scrambled content to the client side to be descrambled by a client-side black box "DRM". > Short of hardware encryption, an encrypted stream is no more special than an > arbitrary codec. > http://en.wikipedia.org/wiki/DeCSS They might be legally special in some places. > Trusted computing does make sense. > http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html In that use case for Trusted Computing Base, the adversary is the evil maid, not the user, and the user is the one who trust the Trusted Computing Base. In the case that this thread is about, the adversary is the user and content proprietors are the party trusting the Trusted Computing Base. Totally different scenarios. > Netflix needs Silverlight for "robust" protection like Hulu needs Flash for > "robust" protection. > They need the quotation marks for their attorneys. I think the word you are looking for is "effective". > I think we have a > moral duty to consider the better side of this technology: protecting the > privacy of people. I think it's laughable to portray the proposal under discussion as protecting the privacy of people. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 24 February 2012 13:39:22 UTC