Exactly. This illustrates why this W3C spec is not DRM. Some other DRM technology is needed for certain modes.
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.
Third parties, namely Flash and Silverlight, already plug in their own DRM systems via NSAPI. How is this worse?
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.
Oops, I meant NPAPI (not NSAPI).
"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."