W3C Declares DRM In-Scope For HTML 290
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.
Reality vs idealism (Score:4, Interesting)
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.
Re:Reality vs idealism (Score:3, Interesting)
However, media via Flash or Silverlight is also broken. It doesn't work everywhere and those media executives are just too stupid to figure out a safe system that will work everywhere. They need to find some smart people that know how to make things work and stop push old ideas of trying to control the software in people's computers. It is possible to do.
Re:Reality vs idealism (Score:2, Interesting)
DRM won't harm the web, it will divide it. See Facebook.
iOS is just a trend, a fading one, otherwise it's percentages wouldn't shift that easy.
EME - That's a shit move (Score:2, Interesting)
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
Do I see a hole in the DRM? (Score:4, Interesting)
Re:Reality vs idealism (Score:4, Interesting)
The trouble is that the properties that make a DRM system actually useful(ie. some degree of robustness, enough information about their environment to 'rights manage' in some granular way, and so on) require fairly extraordinary powers over the client system.
The 'Encrypted Media Extension' itself doesn't; because it defines almost nothing(one 'baseline' encryption mechanism that is little more than a toy obfuscation system, along with standardization of some interfaces for asking the non-joke DRM module questions); but it is designed to plug into DRM systems that do, which is the only reason that it has any support at all.
Consider, for example, the BBC's little request list [w3.org]:
Unless it is 'sufficiently secure that there would be the possibility of legal action in the event of bypassing it.', no go.
Unless it 'securely identifies a type of device', no go(browser UA is explicitly noted as not being good enough)
Unless it allows 'identification of the context in which the content appears', no go.
And 'The ability to pass further restrictions to the graphics rendering path if available'.
A set of requirements like that is both a fairly stock summary of what a DRM system should be capable of to be worthy of the name and a set of demands that certainly aren't going to be met in any non-tivoized OSS implementation, and wouldn't even be particularly easy to meet on something that isn't a closed box.
Essentially, once the pointless little baseline case is immediately ignored by anybody who would ever actually use the system(since, if you don't want DRM, you won't want the hassle, and if you do, the baseline is far to pitiful to be worth anything), EME is a 'standard' for 'how to use javascript to talk to an entire black-box video rendering mechanism, upon which there will be enough demands that it will almost certainly be platform specific'. Pretty much exactly the same situation as having the video player stuck in a blob of Silverlight or Flash, except that (because this is HTML5, man) the wicked 'browser plugin' has been renamed a 'content decryption module'(which, as the spec notes, 'CDM implementations may return decrypted frames or render them directly, and 'CDM may use or defer to platform capabilities'). In all but name, it's the definition of a few javascript APIs for interacting with a black-box video path more or less identical(if not worse, given the more robust support for invoking the hardware-protected 'platform capabilities' now present on a lot of consumer gear, which something like Flash was always too dubiously competent to do in any serious way) to the plugin-based video player arrangements of the past.
Re:Reality vs idealism (Score:4, Interesting)
If I am put in a position where in order to purchase certain content, I have to accept DRM encoding, the very first thing I do before I use the file is strip the DRM out. I call this future-proofing, on the grounds that some content providers (Amazon again) have been known to "take back" content, and on the grounds that a digital file should be subject to the same restrictions as a physical book, CD, DVD or whatever.
But I digress: in the earlier years of the internet, I used to spend a (probably too-)large proportion of my life online. Nowadays, having moved away from urban centres and needing to devote more time to getting a life (growing vegies, raising chooks etc) - and with an enforced bandwidth and traffic limit, I find it easier to keep a more distant perspective. So I no longer spend so many hours trawling the net for things hitherto unknown, and actually spend a few more hours at night in bed with my wife.
Re:Reality vs idealism (Score:3, Interesting)
But if the browser is allowed to be open, then you've defeated the DRM.
the way I see this playing out is no movies or newspapers on Firefox or chromium. Google stands to save how much money with this? I imagine a large percentage of the people will go to chrome.
if the DRM is supposed to be any more effective than the no right click style JavaScript, its going to destroy the open source browser eco system. If It's simply meant to prevent the most casual of copying (this is actually what I think is a valid use of DRM, as realistically content is gonna get out anyway), then your plugin idea works, but good idea selling that.
Re:Reality vs idealism (Score:5, Interesting)
DRM is 100% nonsense. Such schemes are bait for suckers who persist in thinking that ideas and laws for material goods are applicable to data, the ones that use the term "intellectual property" disingenuously. Of course authors deserve compensation. But being fair to content creators does not mean we should accept costly measures to prop up business models that are clearly broken. Abandon the Internet? Submit to inspections by piracy police paid for by ourselves? Ridiculous! The honesty most lacking is not the people's, it's the proponents of these copy protection schemes.
How much work are you willing to do to watch that movie for free
You're thinking of it wrong. It's not how much work any one person is willing to do, it's how much work we all are willing to do. Amortized over a world population of about 7 billion, the amount of work required to break DRM is trivial. Only takes one crack to break the DRM for everyone.
Is it worth trying different patches made by people of questionable ethics
The people with the more questionable ethics are the ones trying to impose DRM. I'm more worried about what their unpatched software does than the viruses that could be present in cracks. Remember the Sony BMG rootkit fiasco? The Turbotax boot sector mod? Windows Genuine Advantage, particularly the false positives it raised against legitimate installs? Ernie Ball's experience with the BSA? And once again, you're looking at it wrong. How long can a crack with a trojan go undetected? Only takes one person out of those billions to discover the problem. As soon as it's found out, it's game over for that trojan.
Are you willing to solder a chip to your hardware, risk breaking it?
I'm not willing to buy that hardware in the first place.
Re:Focus on the specifics. "DRM Bad" is dumb (Score:3, Interesting)
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
Reality (Score:4, Interesting)
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.