Re: Arbitrary codecs and encryption schemes, was: Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

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