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?
Because this will break it beyond repair.
The problem with socialism is that they always run out of other people's money. - Margaret Thatcher
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.
It's not about the evilness of DRM, it's about the fact that it's useless. Has there been a DRM in history that has not been cracked? Why spend energy on a useless endeavour?
The people pushing for this may believe it's worthwhile and useful (or rather the content licensees do), but I think most people on Slashdot are clueful enough to know better.
So besides placating the studio executives, are there any valid (ideally technical) reasons why DRM should be pursued?
"However, the BBC is unlikely to be able to use any such mechanism unless we feel that it is sufficiently secure that there would be the possibility of legal action in the event of bypassing it."
Not sure why you would defend the BBC, but that is pretty much the definition of a sanction. In fact it states quite clearly that the BBC is less interested in about how good the DRM is [they expect it to be broken], but whether anti-circumvention provisions is protected by law e.g. DMCA. It is just focused on stopping the people forced to pay for service in the UK having unrestricted access to the content they paid for.
The BBC has a rather bonkers idea about DRM anyway. For example, HD Freesat receivers are required to implemtn DRM on their output (i.e. HDCP on the HD output, no analogue HD output, etc.), even though the DVB-S signal they are receiving is transmitted in the clear anyway. All it does is inconvenience legitimate consumers - anyone planning on copyright infringement is going to find it more trivial to record the raw DVB-S stream rather than an HDMI stream anyway.
Similarly, iPlayer's DRM is so weak as to be completely useless, and yet they still use it and therefore insist on using the terrible Flash player instead of making the video streams available in a standard format that would work on all platforms. (The flash player is so bad that I invariably just use get_iplayer and then play it with mplayer).
http://blog.nexusuk.org
Nothing in the "Encrypted Media Extension" specs prevents or forbids proxying of both the key and the encrypted media stream to an external "decryption and caching" service. And all of the usual "how do we prevent the plaintext from leaking from the user's machine" questions are still in full force. It is unlikely that the W3C will get "effective protection".
extern warranty;
main()
{
(void)warranty;
}
Here, read this: http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0137.html, this person puts it very clearly: WTF is the W3C doing trying to *hinder* an open accessible web? DRM is against what their purpose in life as an organisation is.
Did "the Director" die, or something??
To be, or not to be: isn't that quite logical, Slashdot Beta?
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)
Lets focus on the specifics of EME. "DRM Bad" is a gross oversimplification.
Interesting, let's see.
I think we can all agree that HTTPS is a good idea - it lets us securely communicate with our bank etc.
Indeed, that's because HTTPS has nothing to do with DRM, besides the fact that both use encryption. HTTPS serves the user, and the user has full control over it.
What if our bank wants to send us a video message, or we want to watch one of our home videos we've stored on a cloud server? Well, we could use HTTPS for that. But HTTPS requires the server to encrypt the content as we're streaming it... that's probably OK for those scenarios, since there won't be more than one person downloading the same video at once.
Exactly. So far, no uses for DRM. Let's hear further.
Now suppose a video store offers to sell us a video. Of course we'd use HTTPS to send our credit card details to prevent them getting intercepted by hackers. The video store might let us download or stream the video over HTTPS. But HTTPS requires the server to encrypt the content as we're streaming it, and if lots of people are streaming the same video the server will be very busy. What's more, since the server has to send differently-encrypted data to different people, they can't use a CDN to spread the load (unless they load their private key into all the CDN boxes, which would be insecure). The solution is EME with the "Clear Key" encryption: the store encrypts the video file once, and tells us to stream the encrypted video file over plain HTTP from their CDN. They then send us the key over HTTPS. The browser uses that key to decrypt the file. Note that there's no "DRM" anti-consumer stuff here - the consumer's web browser has both the key and the encrypted data, and could save those if they wanted to. It's just protecting the data as it flows over the network, like HTTPS does.
What you described is no DRM. The server is giving the user full access to the media, by giving the key to him. They could as well store the media inside a password-protected zip file, serve it over plain HTTP, then send the password for that file to the user. It would have achieved the same level of security. The point is that no media company will use such a model for distribution, because a single user could give away his password to all the other users, making the system ineffective. In fact, no user's right is restricted by this model, there's no "black box" software or hardware involved, there are no encryption keys ureachable to the user, there's no personal information of the user stored inside the media. This is not DRM and this is not what people are afraid of.
Now, EME does also have hooks for a full DRM system. It doesn't specify a full DRM system - it's just hooks so your browser could include a DRM system if it wanted to. Rather than getting the clear key over HTTPS, the browser can get some encrypted data that's passed to the DRM system. The DRM system then does it's thing and decrypts the video, presumably applying copy protection as it does.
So after you've talked so much about completely irrelevant topics, you dismiss the actual problem with three lines and no argumentation. You're actually worsening my concerns, because not only you're telling us that EME will force all content consumers on the web to implement DRM and pay for its implementation and its computational overhead, but also you're giving us reason to believe that the specification will be incomplete, and every content publisher will be free to implement or license a different digital restriction management system based on those "hooks", forcing the users to choose what content they want to access, or to implement or license all of the competing systems, as is already happening with DRM systems for digital television broadcasting.
The sort of companies who are going
Arrghh.. Really? People can still totally misunderstand the situation this badly, in 2013?
The people who endure the things that you're talking about, also pay. The fact that they paid for the DRMed media, is why they have DRMed media. Nobody does anything like what you're talking about, to avoid paying.
People who don't pay, don't go through any of that. How much work am I willing to do to watch that movie for free? NONE. The free content is what works on a computer without any patches, rebuilding, soldering, etc; it works under normal conditions with normal hardware and software. That's the smooth, reliable case, and since anyone and everyone can work on it, there are many players competing against each other to be The Best.
The non-free DRMed content, is the stuff where the computer is always abnormal in some regard. Either the computer is actively hostile to its user (i.e. the user just accepts the absurdity of the DRM-compatible players' artificial limitations and their general lack of competitive features), or it's schizophrenic and (possibly) unreliable, due to needing to [appear to] serve two masters (the case you seem to be harping on).
There's not even a grey area worth speaking of. It's not a matter of "some non-payers have to deal with DRM and some customers don't." These are truly all-or-nothing scenarios, where the exceptions are so rare that it's not worth speaking of. Everyone who makes use of pirated media, is free from having to deal with DRM bullshit while they use that media. And similarly, everyone who does struggle with DRM, is always working with a non-pirated copy, which was paid for, unless you're talking about some fringe case of shoplifting or something like that. Don't you understand that?
So it's not a matter of keeping the honest honest. It's a matter of punishing and discouraging the honest for the "crime"(?) of being honest, constantly tempting them with the promise of how much nicer and easier things will be, if they defect.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.