Re: DRM nonsense

Sent from my iPhone

On Feb 12, 2013, at 9:44 AM, "Florian Bösch" <pyalot@gmail.com<mailto:pyalot@gmail.com>> wrote:

On Tue, Feb 12, 2013 at 6:13 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
The party performing the decryption (the CDM) is trusted.
You cannot "trust" anything that runs on a users machine.

There are three scenarios in which we do, to different extents:
- on completely 'closed' devices, where user modification of the software essentially requires hardware modifications. For example this is the case with many TVs and Set Top Boxes
- on devices where the CDM runs in a hardware-protected Trusted Execution Environment. These are available on many mobile platforms, for example
- when the CDM code has been protected with some kind of software obfuscation technology, making it very difficult to extract the keys that attest to this fact



The content key, decrypted encoded content, decoded content and analog rendered images are different things and in practice protected to different extents.
Wget/curl/pyhtons urllib/etc. would only need to speak to your proprietary blob and pretend to be a browser to download your "protected" content.

Downloading the (encrypted) content is, indeed, easy. But decrypting it can only be done by a CDM in one of the trusted scenarios above.



It's not intended to standardize any specific DRM.
Exactly my point. It's another non-standard.


On the 7 points immediately above, this is the case already. The proprietary runtimes are plugins such as Flash or Silverlight. If they want access to content, users are required to install these large and complex pieces of software and give them access to their machine without the usual protections of the browser. I understand that for this reason browsers would prefer to reduce support for plugins.

Our proposal does not fundamentally change this situation, but moves from using large, general-purpose, arbitrary plugin components to small browser-vetted single-purpose CDMs. It is not a proposal to encourage the use of DRM, but rather a proposal to encourage the use of HTML5.
I don't see an essential difference between large and small general purpose plugins.

Ok, but CDMs are not general-purpose: they provide the functionality of handling protected media within a video element only.



I think it's unlikely that browsers would expose an open plugin API for this, allowing arbitrary user-downloadable CDM plugins (for exactly the reasons that people decry a "new plugin API"). Whilst there may be a plugin-like API internally, I would expect it to be open only to explicitly browser-vetted and explicitly integrated CDMs.
Which is another way of saying it's just another scheme of excluding the competition.

I don't see how. You can't have it both ways: either there are APIs for arbitrary user-installable plugins - with all the associated security and privacy issues - or there are not and only functionality determined by the browser developer goes into the browser. Which do you prefer, by the way ?



This is not the intent of DRM schemes. I don't expect there to be a "Netflix DRM plugin" or "Amazon DRM plugin". In fact our system is independent of any particular DRM. i.e. we can work with many different DRMs, exactly so as to make the service as widely available as possible.

A couple remarks on this point.

1) You seem to expect that your plugin will be "vetted" hence making you the gatekeeper to who can deploy what DRM "algorithm".

No, I meant vetted by the browser developer - in that they decide what goes into their browser.

I can see how Amazon would probably not subscribe to that theory. Would you if the role is reversed? So the assertion "There won't be a <insert vendor> list of DRM plugins" is standing on pretty thin ice.

2) Your DRM runtime would just become another backdoor to insert generic executable code. It's not essentially different from flash. Any sufficiently advanced technology for obfuscation will have to rely on a general purpose executable environment to implement its obfuscation scheme. In fact, "vetting" your plugin won't guarantee anything. Now you've become the gatekeeper to introducing arbitrary runtime code to the browser, under the pretense of having been "vetted". Again argument on extremely thin ice.

3) I'm sure you're aware that what you're essentially describing is polymorphic-DRM, something of which I know that Packet Video is in possession of several key patents. Seeing as packet video is struggling with cash flow, likelihood of getting sued nearly 100%.