W3C Declares DRM In-Scope For HTML
FredAndrews writes "The W3C has ruled DRM in-scope for their HTML standard. A lot of big businesses have supported advancing the Encrypted Media Extension, including Google, Microsoft, and Netfix. The BBC calls for a solution with legal sanctions. The EME could well be used to implement a DRM HTML engine. A DRM-enabled web would break a long tradition of the web browser being the User's Agent, and would restrict user choice and control over their security and privacy. There are other applications that can serve the purpose of viewing DRM video content, and I appeal to people to not taint the web standards with DRM but to please use other applications when necessary."
Looks like the web is becoming more like Xanadu, but not in a good way.
It's so tempting to just sit in the corner and say "DRM is evil, we don't want to taint the web with it" but unfortunately, as is often the case in the real world, we don't get to make decisions in isolation of their consequences. DRM on the web is already a reality, largely using Flash or Silverlight (see e.g. Hulu, Netflix). However, both of these platforms face problems -- Silverlight in particular seems to have a rather uncertain future, Flash availability on tablets and mobile in general is largely non-existant. The poster asks us to "please use other applications when necessary" - is this really a good answer? That is going to lead to even less interoperability, and I would argue it hurts the web at a time when it's already fighting a serious battle against native apps that generally offer developers better control (of UI, no random GC pauses, actual threading models, etc). It's easy to say "DRM will harm the web", it's a bit harder to foresee what the eventualities of telling people "please go away and use native apps" are.
I expect this is likely not going to be a popular response, but in short please realize that this is not as simple as saying "DRM is bad". Yes, DRM sucks but I'd argue that in the long run, having a hobbled web platform losing out to native apps (see e.g. iOS) is going to suck more.
It seems like it should be incumbent upon those that want to restrict your freedoms to bear the full burden of that cost. That is, we do not help them develop a standard for this, and force them to do all the work necessary for their restrictions to try to propagate in the browser ecosystem via plugins, extensions, custom applications, etc.
I would never go so far as to restrict *their* ability to do so, but we should never EVER encourage such behaviour in open standards.
The standards committees should be spending their time (and money) developing technologies that would help people, rather than hinder them.
Well, so much for open-source W3C-compliant browsers.
Lacking <sarcasm> tags,
Flash, Java, Silverlight, take your pick.
As the world wide web has grown it has gotten more information and become LESS usable thanks to all of the crap loaded onto it.
Yes, I know I am falling into the old-school "Back in the day..." crowd here, but seriously- I have a 100mb internet connection now and compared to my old-school 14,400 modem back in the 90s average page load times are.... about the same.
The information I am able to find and use is also about the same.
The useless crap I have to sift through is now HUGE on the other hand, and it actually takes more time to find relevant information. I have to move past all the bad video posts, Twitter crap and asinine Facebook pages. And I haven't even mentioned the BS sites that do nothing but redirect seaarch terms to advert delivery pages.
Hell, I would rather go back to text-based internet browsing than be forced to "migrate to decent user interface technologies."
It's a web PAGE, pal. It should look and work like a PAGE.
In other words there should be a "copyright" field in the metadata, so there is no doubt about it.
Ah .. so they finally want to implement the (almost) ten year old RFC 3514 IPv4 header!
I am Slashdot. Are you Slashdot as well?
The proposal is to extend HTMLMediaElement (which is an ALREADY existing part of HTML) so it supports DRM in a standard way. ...
HTMLMediaElement is a specific DOM element that correspond to media elements (audio, video) and extends the standard element with media specific features: play, pause, length, volume, etc
The proposal is to recognize that DRMs are an widespread feature used in conjunction with media elements. As such, it is worth standardizing.
If the DOM accepts having play/pause features on a media element, it could also support DRM methods on a specialization of this element.
As you said, the implementation and enforcement of DRM is EXTERNAL to the DOM/HTML. Have you read the proposal ? I guess you didn't because the ONLY thing this proposal adds is a bunch of events and methods to allow javascript to provide the key to decrypt an encrypted flow.
Sig (appended to the end of comments you post, 120 chars)