Who cares if Netflix needs it? If Netflix wants to do DRM in the browser, then they can continue to do it the painful way with traditional proprietary plugins. Why should we oblige them and dirty the standard in the process?
I thought part of the reason for DRM-plugins-with-standardized-hooks-in-HTML is that it was the one particularly widely-used current use case for plugins that browser vendors weren't aiming to replace completely internally with HTML, CSS, and/or JS APIs, and switching to a standard mechanism for it would allow browser vendors to deprecate general purpose proprietary plugin mechanisms.
Because that stuff is a pain in the ass.
I say let us keep it that way.
They (note that the people who want that I referred to in the post you responded to are the browser vendors, not the DRM-ed content suppliers) want to switch from that model because they want to narrow the interface to external software and encourage developers to do more with HTML and related technologies, to keep browsers more focussed and to provide more opportunities for HTML/CSS/JS-based extensions to interact with content.
They "want" to keep DRM available through a narrowed-, specifiic plugin interface because there is enough demand from major content sources that the alternative is either keeping general purpose plugin interfaces alive (which browser vendors mostly don't want) or driving certain major uses of the internet out of browser entirely (which browser vendors want even less) or sites that want to deliver content for which the owners demand DRM make their own browsers with propietary DRM baked in.
Bullshit.
1) I am able to gleefully avoid it these days, but in the past flash worked with Linux. Furthermore, all relevant DRM systems work with Apple devices including OSX. Netflix works on Android, and on Google's ChromeOS.
2) Even if it did, who gives a shit? I'd rather have people who absolutely must watch netflix on their laptop do it with windows than have the standard dirtied with this shit.
3) Nothing about this shit being added to the standard will make Netflix work on Linux with open-source browsers anyway.
You are high if you think this will allow you to use Netflix on your GNU/Linux box. Netflix already has their shit working with google-chrome, on a Linux kernel, in ChromeOS (Linux, but not "GNUy", for lack of better terminology). They don't allow that to work with regular GNU/Linux because they don't trust the rest of the stack to keep their precious bits secret.
Why would netflix build their CDM for Linux? (They wouldn't, and they won't.)
Or perhaps they would rely on secure/trusted path this time. I doubt that - the hardware simply isn't there for their customers.
Anyhow, I certainly wouldn't want W3C to endorse any type of DRM, or have them make it easier to abuse DRM. It's a good thing that Flash and Silverlight are restricted to PCs. It's a good thing that plugins annoy people; it makes them less desirable. We really shouldn't be building a new framework for plugins on all platforms.
Furthermore, I'd like to assure everyone reading this that DRM-free media is (still) thriving on the Internet. It's unfortunate that some people fail to play along; this only means that money doesn't go to the right people even if it's their media that's being exchanged.
Are you aware of the argument for providing the simple clear key encryption or making it a requirement of the spec, or for optionally providing the clear form of the media stream back to the Javascript application? I would argue that the Clear Key scheme won't have applications in the content protection space as it's simple to bypass, but creates an opening for backdoor encryption of general content that has been encoded into a media stream which could be used to protect HTML documents and not just rendered media resources of a document.
Take this example, I'm a MooC with upstream providers that want protections on their textbooks. I choose to deliver my textbooks though HTML5 but not allow them to be copied, such as by intercepting mouse and key events which invoke the native copy and paste options on a web page. I also don't want someone to be able to save the content with a view source or save as command. My implementation is store the content in the media frames of a WebM file and require a certain CDM be installed. I then playback the stream and intercept the unencrypted packets, rendering them into the DOM as innerHTML. I have successfully implemented most of an HTML5 DRM system.
It might seem counter intuitive, but even RMS argued that software that violates ethics (the freedoms, etc.) should be contained in hardware with a clear interface with the rest of the system as preferable to a "blob" which can access the rest of the main CPUs software. In a similar vein, video processing offload chips such as the Crystal support open drivers because they have all of the patent-encumbered elements contained within the firmware of the chip. The chip itself processes MPEG transport streams. We can speak all we wish about "DRM-infested" systems like Windows Vista (also present in Windows 7 and most likely 8), but these are protections occurring at the same level as video codecs and not directly implemented in the browser. Anything supporting DirectShow codecs can support these DRM protected streams. The same is true for systems like Widevine and hardware offloaded video playback in devices like smartphones.
Personally, I'm still trying to understand where in the HTML5 spec it specifies how to render video and audio content on a page, such as what elements are supported in video streams, how macroblocks are decoded, etc. I don't believe it does.
[EDIT: I found the reference I used for the comment about RMS, this is the quote from and article based on an interview with him (at http://cedarandthistle.wordpress.com/2010/06/08/some-blobs-a...):
But later, Stallman said something that I found very surprising. He said that he has no problem with the firmware being burned into the hardware (via a ROM chip or the like). He said that he wanted a “black box”, and it’s obvious that he has no problem with proprietary firmware as long as it’s permanently embedded in the hardware rather than being loaded into it at boot time.
]