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.
Web Deli - "Serving fresh websites daily"
00:22 (0 minutes ago)
Attn: Philippe Le Hegaret
cc: Paul Cotton, Maciej Stachowiak, Sam Ruby
Dear Philippe et al,
Further to your discussion, [http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0122.html]
Adding DRM to the open web is a dick move.
When you are old you will look back and think... yeah we really fucked up when we did that.
But anyway - hindsight is usually clearer than foresight - personally I would think your respective talent could be put to better use.
What you do in the world matters, and doing what your doing is harmful - it's shaping a sub-optimal future.
Please reconsider the value of what you are doing and consider pursuing other projects.
Kind Regards,
Principal Web Developer
Julian Smith | Director
e: julian@webdeli.com.au
m: +61423797376
Web Deli - “Fresh websites served daily”
eCommerce | Online Marketing | Drupal | Email Solutions | PHP Development | iOS Development
Please send all mail to : 303/585 Little Collins Street, Melbourne, VIC, AUSTRALIA 3000
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;
}
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.