- From: Mark Watson <watsonm@netflix.com>
- Date: Tue, 12 Feb 2013 20:51:28 +0000
- To: Florian Bösch <pyalot@gmail.com>
- CC: "<public-html-media@w3.org>" <public-html-media@w3.org>
Received on Tuesday, 12 February 2013 20:51:57 UTC
Sent from my iPhone On Feb 12, 2013, at 12:22 PM, "Florian Bösch" <pyalot@gmail.com<mailto:pyalot@gmail.com>> wrote: On Tue, Feb 12, 2013 at 9:16 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote: In others it could output decoded frames for compositing by the browser. Boom, and the DRM is toast. Please see my other comment about the different things being protected. This is just incorrect. Why do you assume this ? Because the "standard" describes a containerized system to deliver the content with the bits about how the DRM works left out completely other than a handshake about how it can work. Obviously you could implement the obfuscation fixed in the browser, which is probably a bad idea given that this will be cracked in 5 minutes flat after release. So since I cannot imagine browser-vendors being happy to deliver patches in 5-minute intervals or face being blacklisted by you, you've got to come up with a way to make a tiny little bit harder. The typical answer is some sort of generic executable code, run in a "trusted" VM. It's pretty obvious really. No, this doesn't follow at all. I'm just saying that as a matter of fact, the DRMs we use today and intend to use with EME do not operate in the manner you describe. ...Mark
Received on Tuesday, 12 February 2013 20:51:57 UTC