It has to happen
We need it to get away from crap playback options.
The World Web Consortium (W3C) is pressing ahead with plans to standardise Digital Rights Management (DRM) in HTML, despite opposition to the proposal. The W3C's chief executive Jeff Jaffe announced imminent publication of a first draft of the specification for Encrypted Media Extensions (EME) on Thursday. The draft is now here …
We need it to get away from crap playback options.
Can anyone outline for me the actual problems this will cause?
I understand the overarching philosophical objection but leaving that to one side for a moment, why do I actually care if there's a DRM standard implemented in browsers?
If I want to slap down proponents of this move, what's my angle?
OK, you want the problems:
1) the *only* way DRM can "work" is that the DRM mechanism must have a secure channel from the decryption code to the user's sensory organs. If at any point in that channel there isn't total security, then the user can intercept the data at that point, and then do whatever they want with it. Thus, the ONLY way DRM can be implemented is if the content holders control your computer, not you - otherwise you can subvert that secure channel.
2) DRM means that just because you can access something today does not mean you can access it tomorrow. You may have that copy of "1984" that you bought and paid for, but if whoever controls the DRM key server decides you shall no longer have access, you don't. The system is totally asymmetric in terms of who's "rights" are "managed".
3) Likewise, it is an invasion of privacy: if you do have local "managed" media, whoever manages the key server can see when you access that media. You may not care if they see how often you want My Little Pony, but do you perhaps care if they see how often you read those "subversive" works - or even how often you re-read that one chapter of "50 Shades of Grey"?
4) It means restrictions on competition.
4a) No Free Software can implement DRM, since if I have the ability to compile and run the source, I can intercept the decoded data (see 1, above).
4b) Indeed, since the algorithms and implementations must be kept secret, that means that whoever controls the algorithms controls who can make players (e.g.: The digital FM system here in the US, iBiquity, requires as a part of the standard that all data SHALL be encrypted using a key from iBiquity - and so if you want to make an HD Radio, you SHALL pay iBiquity for that key. And if they don't like what kind of radio you propose to make, you don't make it. Look up "Griffin HD Radio Shark", and what happened to it.)
5) It can lead to restrictions on media creation. If entities like the RIAA have their way, then once DRM is widely available, they can start towards requiring ALL media to be rights managed. You want to upload your funny cat video? You MUST use a key, and guess what? You MUST rent that key from them! (Yes, this is a "slippery slope" argument. "Slippery Slope" is not a fallacy, but rather an assumption. You may chose to question the truth of the assumption, and thus the validity of the argument, but it is not always in error, and given what has transpired in the past, the slippery slope is more often than not taken).
i agree with your post wholeheartedly however i must point out that:
"4a) No Free Software can implement DRM, since if I have the ability to compile and run the source, I can intercept the decoded data"
free software can and indeed does in many cases implement DRM, there is a world of difference between free software which can be closed source, and open source software,
even open source software can implement DRM, sure you can read the source code, which will allow you to understand how the DRM is implemented even the code for the DRM module itself - however its the hash it uses that counts, be it a supplied hash that will allow the use of secondary software or media or your own hash for media or software you create for use with the program. the DRM module will just check hashes and can be open source for the world to see, it carries out a very basic function, the hashes themselves are another matter.
That depends upon how strongly you define "Free". I tend more towards RMS's level, that if you cannot modify, compile, and run the resulting code, it is not Free. It may be Open Source, but it is not Free.
So saying "Sure, here's the code, but we won't make the private key available to you, we won't let you sign the executable, and thus you cannot use a version you built for the intended purpose" means it is not Free.
You may define Free differently.
"free software can and indeed does in many cases implement DRM, there is a world of difference between free software which can be closed source, and open source software"
You clearly have no idea what free software is.
'Free' as in liberty, not 'free' as in money - although in a Venn diagram there will often be a lot of overlap, they don't mean the same.
...and the free exchange of ideas, the Internet is not to have a Digital Repression Mechanism installed into its core.
The W3C are fundamentally wrong on this one.
Agreed! If we get away from the ~idealism~ of both sides for a second, then how can DRM be a good thing for the actual HTML itself?
One example of DRM gone by bad technical merit is, what if DRM is incorporate as vastly as SSL? How many webpages that you save for offline use will no longer load, unless you have a inet connection to the originating domain? It seems it could force the technology of HTML itself to require a inet connection, how is that a positive evolution at all?
Not only fundamentally wrong, but insanely unclear on the the entire concept of the Internet, i.e. anything on it can eventually be hacked, cracked and phreaked.
It's the old castle versus cannon mistake. Fast mobile warfare was the only real defense.
Doesn't Really Matter
The web has a tendancy to produce alternative means and methods, I will sit this one out and wait for the alternative. If none comes along then tough luck, I'll just find something else to do..
<---- This is an alternative to DRM
I agree with you Khaptain, but I wish I didn't! I wish that because if the web has shown us anything at all, it has shown us that technically it creates redundant, non-standard, and proprietary technologies that only create a ever growing divide. I know the web brings us as humans together, but everything else it seems to clutter. I'm sort of reminded by that in another aspect every time I find a software package ending in .deb, but for which division is the .deb for... And so it goes, a common interest that perpetually encourages a common division.
I have no idea how you managed to extract that out of my post.. Sometimes you can even make AMANFROMMARS seem sensible....
"This is the most shocking sell out since MS . . . . . . "
You just couldn't help yourself could you.
Beware! Eadons fanclub are reading this articles forum!
Well that's another nail in the coffin.
Given that html supports plugins, there is not much real need to bake in DRM.
It's sad that the CEO of the W3C would be so wrong.
The Encrypted Media Extensions would standardize the APIs for the content decryption modules, but it won't standardize the content decryption modules (CDMs). It can't standardize the CDMs, because that would make the encryption scheme unworkable, due to pre-existing W3C policies on open source. Therefore, the content "protected" by the CDMs would be restricted to "applications inaccessible to the Open Web or completely locked down devices." Exactly what Jaffe said he didn't want.
EME will not make the web more open. It will only make life easier for people who try to restrict users' freedoms. It's the <video> tag all over again, but even worse.
"....Adobe did exactly the same with Flash Player, which Microsoft had been trying to topple from its leading position as the internet's worst browser-based media player...."
That's what it meant to say, yes?
You know what, anyone that wants a copy of drm'd content can ultimately just stick a microphone in front of their speakers or a video camera in front of their monitor (if even digital capture of the final output is not possible) Sure there will be a slight loss of quality, but for the pirates that distribute stuff, that doesn't matter.
The sooner the copyright owning corporations wake up to the fact that the best way to prevent theft is simply to distribute content at a fair price, the better. Most people prefer to be honest unless they feel they are being ripped off.
Unless its built into all hardware it wont work: run up a VM with your favourite OS and DRM'ed browser in it - pipe sound and video to your choice of format.
... a "Content Decryption Module" interfacing with a browser-embedded API ("Encrypted Media Extensions") is different from a "Plugin" -- such as Adobe Flash -- interfacing with a browser-embedded API ("NPAPI - Netscape Plugin Application Programming Interface", or "PPAPI - Pepper Plugin Application Programming Interface")?
It appears to me that all the W3C is going to accomplish with this activity is create a limited-function, "pseudo-plugin" interface that moves the Play/Skip/Fast-Forward/Rewind/Volume "buttons" for encrypted multimedia content out of (for lack of a better term) "full-fledged" plugins like Flash and into the browser, which has already been accomplished for non-encrypted content via the HTML5 "video" tag.
For example, right now there is absolutely nothing preventing YouTube, DailyMotion, and Vimeo from wrapping their **entire content catalogs** (both user-generated **and** commercial) in DRM, and forcing them to be delivered by Flash, Silverlight, or Quicktime under a "pay-to-play" model.
After all, a good 75% to 90% of the content delivered by Flash is H.264/MPEG-4 video, presented through a Flash-scripted Applet, and a good chunk of that is (supposedly) "encrypted" and "rights-managed".
How would this be any different?
The thing that concerns me isn't the fact that the W3C wants to include a pipe to an encrypted media decoder as one of the standard browser APIs, it's the fact that they're developing yet another API by committee. And who knows how long that will take? I mean, look at HTML5, and the boondoggle that became...
With a standard, you have a two tier web - one tier for free content, accessible from open-source software, and another tier for paid content, accessible only from browsers made by major companies that are allowed to sign NDAs for the DRM secrets.
Without a standard, there is one web - except for those seeking DRM, who are consigned to the outer darkness of having to make up their own software and do without interoperability.
I'm not sure that such a standard will actually be all that bad, but I certainly can see why it is being objected to, as it at least appears to threaten making open-source browsers second-class.
So, the embedding of Video is to be covered by HTML 5. This is a good thing, standards for video across all OSes, all browsers and all platforms.
The companies which want to commercially stream media, and that's mainly who we're dealing with, won't use this standard if there is no DRM. The reason they want DRM is because a streaming service generally sends media to paying customers and generally the customers will get only a couple of views for the price they pay. This seems fair, it also seems fair that the businesses streaming the media don't want people to be able to download a single copy and rely on trust that the end user will delete it after their single view. It would be very naive to suggest that this will happen in any meaningful way.
So, there are two options: No DRM and therefore no cross platform commercial video, or DRM and cross platform commercial video.
Which to go for? Personally I want to be able to stream video to my Mac, Windows and Linux PCs without having to arse about with proprietary plugins, which don't support Linux very well in particular. I don't think that this is an unreasonable request and I don't think that it's breaking some "everything for Linux or the Web must be free" ideology which seems to be taken by certain of RMS' followers.