The idea of DRM for HTML isn't a new one, but it's gaining some traction. Granted, it's in the very early stages and it may not go far in its current form.
But the W3C, the standard body that defines most web technologies, is now looking into a new proposal put forward by Microsoft, Netflix and Google.
The proposal for Encrypted Media Extensions defines an API through which DRM schemes for the web would work. The idea is to keep video and audio content locked up even if it's served via HTML5.
The big problem, of course, is that DRM doesn't work – all it does is annoy the people who pay. This has been proven over and over again, but media and software companies aren't keen on listening.
In theory, DRM is supposed to protect video streams or software from pirates. In practice, users who can't easily make a copy of a video stream will simply find it on pirate sites.
At the same time, determined pirates are either going to find other sources or simply get around the DRM.
There are big problems with the proposed API as well. For one, the fact that it's an API. This means that the actual DRM would have to be provided by plugins.
If such a scheme became popular, you'd need multiple plugins to watch anything on the web and you still won't be guaranteed to be able to watch everything.
Standards are designed to promote interoperability, exactly what plugins hurt. It gets worse; some of the DRM methods described in the proposal are very bad at protecting anything, as pointed out by Manu Sporny, a member of the W3C's HTML working group who, incidentally, has great experience with DRM systems.
For now, the Working Group is looking over the proposal, but even if this particular one is rejected, the idea is not going to go away.
And, if or when DRM for HTML becomes a reality, there will be no getting away with it. IE will support it, Google will support it, and so will any browser based on WebKit, which is to say any browser out there except for Firefox.