World Web Consortium warms HTML bed for forced DRM snuggle 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 …
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
