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 …
This post has been deleted by a moderator
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.
This post has been deleted by its author
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?
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.
This post has been deleted by a moderator
This post has been deleted by a moderator
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.
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.
... 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.
Biting the hand that feeds IT © 1998–2020