Re: DRM nonsense

On Tue, Feb 12, 2013 at 6:13 PM, Mark Watson <watsonm@netflix.com> wrote:

> The party performing the decryption (the CDM) is trusted.
>
You cannot "trust" anything that runs on a users machine.



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


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.



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


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". 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%.