> 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.
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.
> Why do you think they want to switch away from the old general purpose proprietary plugin mechanisms, which are specific to the browser?
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.
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.