Re: DRM nonsense

Sent from my iPhone

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

On Tue, Feb 12, 2013 at 8:40 PM, Mark Watson <watsonm@netflix.com<mailto: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.

In some scenarios the CDM handles everything including rendering. In others it could output decoded frames for compositing by the browser. See my
comment above.



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]

This is just incorrect. Why do you assume this ?

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