3 ms·

Thanks. I read the spec and saw this regarding open source browsers: "9.5. Can I ensure the content key is protected without working with a content protection

by logn 14y ago

Thanks. I read the spec and saw this regarding open source browsers: "9.5. Can I ensure the content key is protected without working with a content protection provider? "No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. [...] In addition, it is not something that fully open source browsers could natively support."

trunnell 14y ago
Exactly. This illustrates why this W3C spec is not DRM. Some other DRM technology is needed for certain modes.
- Natsu 14y ago
  So it's not DRM, it's just a way for 3rd parties to plug in their own DRM system. Sorry, that's worse, not better.
  - trunnell 14y ago
    Third parties, namely Flash and Silverlight, already plug in their own DRM systems via NSAPI. How is this worse?
    - trunnell 14y ago
      Oops, I meant NPAPI (not NSAPI).
    - darklajid 14y ago
      Depends. What Flash and Silverlight do is just as bad => This proposal isn't worse. But Flash and Silverlight are dead or dying and were never public specifications we cared about. What I consider 'worse' here in this proposal is that we'd kind of 'bless' the DRM layer in HTML. I fear a comment like "Hey, it's part of HTML 5 so it has to be good, right?" if nonsense like this is added.
    - Natsu 14y ago
      We don't want to make it easier to add DRM. The more painful it is, the better.