Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

TL;DR: Obfuscate your HTTP stream using ArrayBuffer and stream 
encryption and you will have met your contract requirements.

-Charles


On 2/23/12 3:59 PM, Mark Watson wrote:
> Tad,
>
> To address your last point first: There is clearly a choice to be made 
> as to whether the web platform should support commercial video 
> services any time soon, or should wait for the DRM-free future you 
> imagine below to arrive.

Mark, I appreciate the situation you're in. I've watched the music 
industry struggle with the same situation. They've required all 
providers to disable copy and paste of lyrics. But they did it in a 
reasonable manner. They simply ask that it's disabled for "typical" 
users. Any programmer with one minute of free time can bypass it. Well 
over 99.99% of users can not. The same is true for their audio feeds. 
Pandora, Jango and many others ship out "unprotected" streams. But they 
do so in a manner that a user can not simply use their context menu to 
clone content. And there's Google's HTML5 streaming of music videos. A 
similar situation.

Simply disabling the context menu is sufficient. But I know that's not 
the case for you. You've already made your commitments and your 
attorneys as well as theirs will wig out if you change things. I've seen 
your streaming process as well. Unlike Hulu, you've chosen to transmit 
over bare HTTP. Cool stuff. And I want you to get into HTML5.

But take a lesson from the other guys. You can obfuscate. It meets the 
criteria.

> This will be a long wait. During this time many millions of $$ of 
> engineering effort will be invested in providing commercial video 
> services on other platforms: effort which could have gone towards 
> making the web platform better in many different ways. These costs are 
> also 'unnecessary costs on legitimate users', because investment is 
> fragmented, duplicated, instead of targeting a single common platform. 
> And the sums involved far exceed the sums involved in supporting DRM.

I'm actually for this kind of effort. I've been writing components in 
HTML Canvas for awhile and have had a few vendor-developers tell me I'm 
being silly by making the effort that they feel is reserved for them / 
that they are entitled to as UA developers. That effort is not a big deal.

It's about whether we're going to speak the same language. Are we going 
to use HTML5? Are we going to use ARIA?  Are we going to follow WCAG? 
Are we going to make subtitles and captions available to users? Those 
are the issues that matter.

Every video site out there is going to make their own <video controls> 
implementation. Boy I love Hulu and Netflix and boy do I have a dislike 
for Viacom's web programmers.

If you want "robust" DRM, you're talking about one of two things: Either 
it's obfuscation, so that it's only coders who can grab the raw feed, or 
you're talking about "trusted" computing, which is a valid computing 
paradigm, but it's way above your pay grade, in government speak. James 
Bond needs trusted computing. The rest of us consumers are better off 
without it. But sure, if you want to pass keys into the hardware, yeah, 
we need an API. And I think the encrypted media proposal is legitimately 
addressing that need. And yeah, you've got to pass that data into the OS 
for your Bluray/DVD CSS licenses. I get that.

And I get that you're stuck, because you're not looking for more studios 
to wig out over you shifting formats. As I see it, you are already in a 
bad situation, and you're trying to make the best of it. I wish you the 
best of luck.

I do understand why Tab and Ian are against "trusted computing" APIs 
being present in web apps.

I don't know that they can win that battle. Best of luck to them too.


> Some additional comments inline ...

Also inline.


> On Feb 23, 2012, at 2:25 PM, Tab Atkins Jr. wrote:
>
>> On Tue, Feb 21, 2012 at 3:16 PM, Adrian Bateman 
>> <adrianba@microsoft.com <mailto:adrianba@microsoft.com>> wrote:
>>> We'd like to get people's feedback on the proposal. It is posted here:
>>> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
>>>
>>> Many content providers and application developers have said they 
>>> can't use <audio>
>>> and <video> because HTML lacks robust content protection. Without 
>>> this functionality,
>>> they cannot move their apps to the web platform. Many consumer 
>>> electronics are taking
>>
>> Despite the abstract attempting to claim that this spec is not DRM,
>> it's sole purpose is to communicate with a browser's built-in DRM
>> scheme.  Essentially, this spec describes a DRM system but leaves the
>> encryption/decryption part unspecified.
>
> The first sentence, yes, though there is a genuine reason for 
> referring to 'protection system' and not 'DRM'. 'rights management' 
> brings in a whole bunch of stuff related to rights expression and 
> associated business logic, which we prefer to be dealt with by the 
> service/application.
>
> The second sentence, no: we describe how to *communicate with* the 
> protection system, but we do not describe a protection system. The 
> contents of the /message/ and /key/ fields are protection-system 
> specific and may consist of signed/encrypted messages that only the 
> protection system understands. We do not specify these.
>
> Incidentally, specifying encryption/decryption should be 
> uncontroversial as these are well-defined functions widely implemented 
> in free open-source software.

Outside of the government, I think we're all aware that this is about 
obfuscating the content stream. It's particularly protecting it, because 
"consumer" content protection is just a silly cat and mouse game of 
make-work opportunities for corporate attorneys and 501c structures. 
It's well-established that content protection does not stop any consumer 
products from being pirated. Obfuscation works just fine for stopping 
the average consumer. Everything else is just extra work, unfortunately 
necessary to keep contracts from getting wet.


>> This does not solve the problems brought up last time against adding
>> DRM to <video>.  In particular, a browser like Mozilla is *legally
>> prevented* from actually implementing DRM, because they have to reveal
>> all their code, including the decryption code that contains the
>> secrets you use to decrypt.  We should not be attempting to put
>> anything in HTML which won't be implemented by one of the major
>> browsers.
>
> From a specification point of view, the problem is solved because we 
> don't specify protection systems (except clearkey, which should be 
> uncontroversial).
>
> You can certainly implement the communication with a protection system 
> in open source, just as open source browsers access many and varied 
> device and platform capabilities without shipping implementations of 
> those capabilities.
>
> DRM doesn't primarily derive the security it offers from being closed 
> source: you could publish the code for most if not all DRM systems 
> without making them easy to crack. I'm not saying that it's possible 
> to have an open source DRM that can just be downloaded and installed 
> on arbitrary platforms. Or that there are not IPR issues. But they are 
> not based on security through obscurity.

Yes, this API is about sending a key to the OS. It's about passing 
something from the scripting environment through the UA to the OS. I am 
a proponent of exposing OS-level interfaces to the scripting environment.

Now the <video> and <audio> tags can already "work" with DRM. It's 
really up to the UA what kind of formats they're passing around. I've 
already posted that it's dead simple to add arbitrary encryption to an 
ArrayBuffer and from that, a data stream, for anyone who supports 
passing byte streams into the media element.

But your spec makes DRM easier. It also makes hardware level protection 
a lot easier. It's just that nobody is using the latter, and the 
Mozilla/WHATWG community have will always fight against the former.

I'm still for enabling government grade techniques on the web. And 
trusted computing is one of those. But I do recognize, it has some real 
costs. Ian talked about it as an ethical issue. It is. I can't fix that 
tension for anyone. When it came to fair use being restricted by the 
music industry, I sold my assets and left. I was done with it.


>> This is ignoring the more general concerns with the concept of DRM,
>> namely that it's technically impossible and practically useless,
>
> Of course it's not possible to make it impossible for protected 
> content to be copied. Any more than a speed bump makes it impossible 
> to break the speed limit. It merely makes it more difficult, 
> uncomfortable, very obviously not endorsed by the owner (or the 
> content, or the road).
>
> DRM is probably more effective at it's objective than speed bumps are 
> at theirs and noone would call speed bumps "technically impossible" or 
> "practically useless".

You'll have good success by just encrypting and decrypting your data 
stream in JavaScript.

The only thing this adds is that plug-in authors will have to ask more 
permissions of the browser. Mozilla doesn't even have granularity, and 
Chrome via NaCl is doing just fine exposing C and C++ code.

I know you're not going to paint yourself into a corner and require that 
your audience have actual DRM chips installed on their devices.

We both know that. It's just not going to happen.

Instead, you're going to see new companies sprout up, following 
YouTube's lead. YouTube is streaming, sans-DRM, the majority of music 
videos ever released. You'll see Comcast, or someone else pop up, and 
they'll start out using HTML5 video. And that's just how it'll go. It's 
already happening with Adobe's streams.


I'm disappointed in all parties with this situation. We have very 
important work to do to make it so we can take an ArrayBuffer and 
decrypt it, and run it through a media element. And we're having some 
progress there. We've got important work in taking a bitmap and audio 
frames, and running them through a web worker for filtering, and we're 
making progress there. We've got important work in taking subtitles and 
captions and exposing them for programmatic access. We're making 
progress there.

And we've got this proposal. Important work in trusted computing, where 
the host machine is a thin client, and it's sending data to another 
piece of hardware, and everything is as secure as we can make it on this 
earth. And this API can make progress there. But that's not what is 
being pushed. That's the disconnect that upsets me.

It's a perfectly reasonable and helpful API, but the motivation for it 
is not reasonable.

I'm a big fan of lawyers. I know where they are coming from, but law is 
part of the liberal arts, and engineers lose sight of that. And CEOs, 
COOs and CTOs have to weigh the risks.



-Charles