Re: DRM nonsense

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

>  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
>
You don't need to out-obfuscate joe-average user. You're trying to
out-obfuscate people who can read assembly in hex as well as you may read
C++ or Ruby. Trying to outsmart the smarter has traditionally not worked
very well. And it only takes one single person to be smarter than the
entire exposure area of your obfuscation, which by definition cannot be
watertight, ever, then it lands on github, and bitbucket, and bitorrent and
your system is toast. It's futile. But, there isn't even a need to extract
keys or bother with all that because...

    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.
>
There is going to be a binary "trusted" blob which implements the entire
obfuscation. That blob will be "run" by the browser. The browser will need
the vanilla content at some point during display/output/composition etc.
You can just talk to that runtime pretending to be the browser and ask
nicely for the raw content. No keys required, also no intricate knowledge
of your obfuscation.


Ok, but CDMs are not general-purpose: they provide the functionality of
> handling protected media within a video element only.
>
There'll be a virtual machine [patented: check], which executes your DRM
[patented:check], using keys [patented:check], and a supplied bytecode
[patented:check], to extract the encrypted stream [patented:check], and
provide it to the using application [patented:check], under the assumption
that the CDM runtime is "trusted/vetted" [patented:check].

You ticked off every single one of PVs patent claims. Congrats.


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 ?
>
Personally I'd prefer people would stop trying to invent anti-features,
usability obstructions and just plain old impossible things (you're trying
an end-run around the limitation that you're using encryption with only one
trusted partner in a two-way communication, <facepalm>).

But if you must, try thinking about how Firefox could possibly implement
this. That's gonna be an interesting answer.