W3C green-lights adding DRM to the Web's standards(boingboing.net)
boingboing.net
W3C green-lights adding DRM to the Web's standards
http://boingboing.net/2013/10/02/w3c-green-lights-adding-drm-to.html?
313 comments
What is the WHATWG's position on this? They represent the browser makers. If they support DRM then it's game over. Another break-away standards group won't be able to do anything to sway the browser makers. What could they do?
Seemingly, the WHATWG is against this. But there's a big difference between individuals on a mailing list and broader corporate interests.
It's a tragic comedy that everyone's yelling at the W3C for losing their way yet again... the WHATWG, weren't they great. Yet the WHATWG is basically a proxy for Google, Apple and Microsoft. And they have driven the W3C agenda for a long while.
When you repeatedly shit on the hippies, academics, and non-browser makers that had more sway in the past at the W3C, and replace them by corporate browser makers, you weaken the antibodies that were in place. The WHATWG's presence has marginalizing other voices within the W3C and forced it to listen to its primary members - i.e. corporate, pay-to-play ones.
It's a tragic comedy that everyone's yelling at the W3C for losing their way yet again... the WHATWG, weren't they great. Yet the WHATWG is basically a proxy for Google, Apple and Microsoft. And they have driven the W3C agenda for a long while.
When you repeatedly shit on the hippies, academics, and non-browser makers that had more sway in the past at the W3C, and replace them by corporate browser makers, you weaken the antibodies that were in place. The WHATWG's presence has marginalizing other voices within the W3C and forced it to listen to its primary members - i.e. corporate, pay-to-play ones.
Consider that three of the largest browser makers -- Microsoft, Apple, and Google -- all have arms that deal heavily with media companies.
I dislike DRM as much as the next person, but if it's implemented reasonably (think Steam or Netflix), then many consumers are willing to deal with it. EME was what enabled Netflix on ARM-based Chromebooks, for example; and I prefer EME to not being able to legally access media at all.
I dislike DRM as much as the next person, but if it's implemented reasonably (think Steam or Netflix), then many consumers are willing to deal with it. EME was what enabled Netflix on ARM-based Chromebooks, for example; and I prefer EME to not being able to legally access media at all.
I prefer EME to not being able to legally access media at all.
In other words, you are willing to give up freedom to get--what, exactly? Movies? Music? Eye candy?
I confess I simply can't understand this point of view. People are willing to hand over the Internet to DRM and the media corporations because they can't live without the "entertainment" that Hollywood provides? People are willing to have their computers pwned just so they can watch Netflix? That appalls me.
In other words, you are willing to give up freedom to get--what, exactly? Movies? Music? Eye candy?
I confess I simply can't understand this point of view. People are willing to hand over the Internet to DRM and the media corporations because they can't live without the "entertainment" that Hollywood provides? People are willing to have their computers pwned just so they can watch Netflix? That appalls me.
I'm writing this comment from a Samsung Chromebook. When I use Chrome OS; I'm already giving up my freedom. Chromium itself is open-source, but there are tons of binary blobs on this device: the accelerated graphics driver for the Mali GPU, the ARM build of Adobe Flash, and the EME implementation that makes Netflix work on my device.
EME is not new. There are already devices shipping with implementations, like mine. If EME is standardized, what it means for me is that there's a chance that my device will work with all DRMed content I want to access, and not on a per-service basis.
We're not talking about giving "big bad media companies" full control of the Ring 0 Hypervisor; I am still perfectly capable of flipping the virtual developer switch on my device and booting a pure version of Linux at any time. If I buy a device ships like that, I hope that future me will have the good sense to return it to the store.
EME is not new. There are already devices shipping with implementations, like mine. If EME is standardized, what it means for me is that there's a chance that my device will work with all DRMed content I want to access, and not on a per-service basis.
We're not talking about giving "big bad media companies" full control of the Ring 0 Hypervisor; I am still perfectly capable of flipping the virtual developer switch on my device and booting a pure version of Linux at any time. If I buy a device ships like that, I hope that future me will have the good sense to return it to the store.
You're giving up a lot more than that. Last I heard, the existing Chrome OS implementation of HTML5 EME refuses to run unless the device is a Chromebook that's locked down to ensure no unauthorized or modified code is running anywhere on the device: enable developer mode and the CDM disables itself.
When I use Chrome OS; I'm already giving up my freedom.
Yes. Why? (I don't have a Chromebook, and don't use Chrome OS, for this very reason.)
Yes. Why? (I don't have a Chromebook, and don't use Chrome OS, for this very reason.)
If you don't plan on using your laptop for anything outside of entertainment, being able to rewrite the software on the micro that controls the battery charging circuit is not particularly relevant or useful.
The WHATWG doesn't really "exist" in quite the same way that the W3C does. There isn't Process for obtaining an opinion that you can then ascribe to an organisation rather than one or more individuals. It only represents the browser makers insofar as the specs hosted at whatwg.org accurately reflect what browsers implement. Sometimes this is achived by adjusting the browsers to match the specs; oftentimes the opposite occurs.
It is certainly the case that several individuals editing specs under the WHATWG banner have set out their opposition to DRM. It seems unlikely that Hixie will include it the HTML spec he edits unless, of course, we end up with something implemented in browsers that is both interoperable and open. Since "open" rather defeats the point of DRM, it's difficult to imagine that happening, however.
It is certainly the case that several individuals editing specs under the WHATWG banner have set out their opposition to DRM. It seems unlikely that Hixie will include it the HTML spec he edits unless, of course, we end up with something implemented in browsers that is both interoperable and open. Since "open" rather defeats the point of DRM, it's difficult to imagine that happening, however.
The W3C though is an organization you can buy. Their process is not reasonable and we should not recognise their authority. Especially after this.
Most browsers are free software nowadays. Their makers opinion is important (yeah, forking is hard work), but not that much.
EME is driven by two browser vendors, Google and Microsoft, in partnership with Netflix. See Editors section of the spec,
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...
Chrome and IE are the ones pushing this - so yes, the opinion of browser makers matter, but sadly the 2 biggest ones, Google and Microsoft, do not just support EME but are the ones driving it.
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...
Chrome and IE are the ones pushing this - so yes, the opinion of browser makers matter, but sadly the 2 biggest ones, Google and Microsoft, do not just support EME but are the ones driving it.
This vastly underestimates the importance of the massive number of users running browsers supplied by the vendor of their device/OS.
The WHATWG are in control of the W3C's agenda. The corporate members of the WHATWG are the ones pushing for Web DRM. Oh, not the individuals necessarily. They might be opposed to it.
But they're just voices in a large game: Microsoft and Google are co-editors with Netflix of the new DRM spec.
But they're just voices in a large game: Microsoft and Google are co-editors with Netflix of the new DRM spec.
This news makes me so sad. Also: The more things progress, the more and more sense RMS makes.
What is RMS in this context? Googling got me nowhere.
We're talking about DRM and content protection, so RMS' 1997 short story seems apropos:
http://www.gnu.org/philosophy/right-to-read.html
http://www.gnu.org/philosophy/right-to-read.html
RMS -> Richard Matthew Stallman
> It's a place where the next Tim Berners-Lee or Mozilla, if they were building a new browser from scratch, couldn't just look up the details of all the "Web" technologies. They'd have to negotiate and sign compliance agreements with a raft of DRM providers just to be fully standards-compliant and interoperable.
I may be totally naive here, but I'm not really sure why this matters. That there is a WC3 standard does not imply that browsers have to adhere to it. If they didn't they simply wouldn't be able to access DRM protected content. From a UX perspective this seems no different from Netflix putting their content behind a login. Maybe I am being an idiot, if so please correct me, but this doesn't really seem like anything to worry about. The threats implied by EFF, that massive corporations will control content on the internet, seems only true for content published by those massive corporations (and thus are already happening now, with 3rd party DRM ie: Netflix's Silverlight player). It doesn't stop people from publishing non DRM protected content.
I would agree this doesn't belong in the spec on technical level, but it seems to be inclusive not exclusive.
I may be totally naive here, but I'm not really sure why this matters. That there is a WC3 standard does not imply that browsers have to adhere to it. If they didn't they simply wouldn't be able to access DRM protected content. From a UX perspective this seems no different from Netflix putting their content behind a login. Maybe I am being an idiot, if so please correct me, but this doesn't really seem like anything to worry about. The threats implied by EFF, that massive corporations will control content on the internet, seems only true for content published by those massive corporations (and thus are already happening now, with 3rd party DRM ie: Netflix's Silverlight player). It doesn't stop people from publishing non DRM protected content.
I would agree this doesn't belong in the spec on technical level, but it seems to be inclusive not exclusive.
The W3C is the guardian of the world wide web, a system for disseminating information publicly and globally to all those who may benefit from it. By standardizing DRM for video, they are giving legitimacy to a technical kludge that is designed specifically to prevent the dissemination of information. There are legitimate reasons why someone may wish to save a video to their hard drive, just like they can save an image today. There is no reason the web should be built upon mechanisms designed specifically to privilege corporate interests over the interests of those falling under fair use exemptions to copyright laws.
If I had my way we wouldn't have copyright at all. It seems idiotic to me for the same reasons patents are.
But we do, and so just as you say there are "legitimate reasons" why someone may wish to save a video, there are too "legitimate reasons" someone may want to share their work in a protected manner. It's a product. If you don't like it don't buy it.
There is no part of this that forces the user to view only DRM protected websites. As far as I can tell this only increases the rights of copyright holders, which, again, I think is stupid, but seems completely legal and a reasonable thing to do under our existing legal framework. Edit: it also does not seem like it will fundamentally change the user experience of the web since the things that it allows are mostly already doable, just not with an HTML standard.
But we do, and so just as you say there are "legitimate reasons" why someone may wish to save a video, there are too "legitimate reasons" someone may want to share their work in a protected manner. It's a product. If you don't like it don't buy it.
There is no part of this that forces the user to view only DRM protected websites. As far as I can tell this only increases the rights of copyright holders, which, again, I think is stupid, but seems completely legal and a reasonable thing to do under our existing legal framework. Edit: it also does not seem like it will fundamentally change the user experience of the web since the things that it allows are mostly already doable, just not with an HTML standard.
If some copyright holder wants his stuff DRMed then they are free to implement their own DRM plugin or App. But I don't see why we should support them. Especially when it makes our nice open web depend on proprietary closed source binary blobs.
The idea was that HTML5 gets rid of Flash and similar plugins and not that HTML5 turns into a vehicle for "yet another Flash".
Next thing we are adding a spy module feature because advertisers and the NSA demand it? Well at least the spy module could be free software unlike the proprietary closed source binary blobs needed for Digital Restrictions Management.
The idea was that HTML5 gets rid of Flash and similar plugins and not that HTML5 turns into a vehicle for "yet another Flash".
Next thing we are adding a spy module feature because advertisers and the NSA demand it? Well at least the spy module could be free software unlike the proprietary closed source binary blobs needed for Digital Restrictions Management.
DRM doesn't "increase the rights" of copyright holders, it just intentionally goes out of its way to stifle everyone else. The fact that it's called "Digital Rights Management" is a bit of doublespeak, which is why the FSF encourages using the more accurate description of "Digital Restrictions Management."
Although it seems the word "copyright" is also a bit of doublespeak these days. In general it doesn't go out of its way to give authors the right to control how publishers distribute copies any more, it's been co-opted as a system for publishers to deny every individual the the ability to make their own copies for any reason. If you ask me they should call it a copy-block instead of a copy-right.
Although it seems the word "copyright" is also a bit of doublespeak these days. In general it doesn't go out of its way to give authors the right to control how publishers distribute copies any more, it's been co-opted as a system for publishers to deny every individual the the ability to make their own copies for any reason. If you ask me they should call it a copy-block instead of a copy-right.
What I don't understand is that if these companies want so desperately to enforce DRM, why are they using the web? A native application is better suited to what they want to do, and they are going to end up writing DRM modules in native code anyway. So why are they targeting the web at all, and why do they insist on getting something that is fundamentally closed (DRM) put into something that was meant to be open (HTML)?
IMO, this is a very dumb approach. This would not be OK anywhere else. Feel free to enforce your copyright, but don't expect me to bear your burden without kicking and screaming.
IMO, this is a very dumb approach. This would not be OK anywhere else. Feel free to enforce your copyright, but don't expect me to bear your burden without kicking and screaming.
Content providers want to be on the web, because that's where the audience is. If they're made to feel unwelcome on the web, they certainly will take their content away. This makes the web less useful and harms users.
The web has had copies of that content well before the "content providers" even had a website, and it'll have copies of the content well after they decide to leave.
All they can take away is the sources that actually bring them money.
All they can take away is the sources that actually bring them money.
The "web" has existed in a mature form for over 2 decades.
The web's success has been extraordinary in the same terms of any monumental human achievement -- the discovery of anti-biotics, the moon landing, the Magna Carta.
Why would we cripple that set of features just to make a tiny group of people happy (relative to the world's population, the copyright "special interest" cartel is indeed microscopic.)
And I thought web sites screwing up keyboard shortcuts was annoying..
The web's success has been extraordinary in the same terms of any monumental human achievement -- the discovery of anti-biotics, the moon landing, the Magna Carta.
Why would we cripple that set of features just to make a tiny group of people happy (relative to the world's population, the copyright "special interest" cartel is indeed microscopic.)
And I thought web sites screwing up keyboard shortcuts was annoying..
If I had my way we wouldn't have copyright
at all. It seems idiotic to me for the same
reasons patents are.
Edit: I'm obviously not serious.
I wonder how explosive the web's growth would have been if Hyper Text Markup Language was complex, pre-compiled, and invisible to end users.
I wouldn't recommend it: the name and logo are trademarked, and even if you replaced those, if anyone noticed the rest of the copying, you'd be the laughingstock of the internet. Who'd want to buy your product then?
Zynga doesn't particularly seem to care about that kind of thing and they're doing pretty ok...
Zynga only had one profitable year in 2010. They have lost $600 million since then.
Worst. Example. Evar.
I think you're proposing dire consequences where there aren't likely to be any.
Google copying Yahoo's front page code? Okay, that'll be in the news and everyone will have a good laugh.
Some Joe Schmoe Web Developer lifting CSS/HTML from an unknown client to sell to an unknown client? Eh, not so much. This probably happens often and goes undetected.
Google copying Yahoo's front page code? Okay, that'll be in the news and everyone will have a good laugh.
Some Joe Schmoe Web Developer lifting CSS/HTML from an unknown client to sell to an unknown client? Eh, not so much. This probably happens often and goes undetected.
It's not my company, and the things I'm saying don't represent the opinions of my employer.
To your question, is it "ok," I couldn't provide the answer as I don't own the copyright.
My statement was that I wish we lived in a world without copyright. The rules would be very different, and thus we would act and compete differently. As is, brand is an important asset for a company. I think you know all this.
I also think your argument is a bit sophomoric and I find it obnoxious that you are calling out my employer's name.
To your question, is it "ok," I couldn't provide the answer as I don't own the copyright.
My statement was that I wish we lived in a world without copyright. The rules would be very different, and thus we would act and compete differently. As is, brand is an important asset for a company. I think you know all this.
I also think your argument is a bit sophomoric and I find it obnoxious that you are calling out my employer's name.
What do brands have to do with copyright law?
Or are you also advocating for changes to trademark law?
Or are you also advocating for changes to trademark law?
It seems counter intuitive and even foolish to suggest that you could increase innovation and creativity by getting rid of copyrights and patents. But there is a great great example of an industry that actually thrives in both sales and innovation, despite not having any copyrights or patents - the fashion industry.
This TED talk explains it quite well : http://www.ted.com/talks/johanna_blakley_lessons_from_fashio...
This TED talk explains it quite well : http://www.ted.com/talks/johanna_blakley_lessons_from_fashio...
The elephant in the corner of your argument is trademarks, which are vigorously protected by fashion labels.
You're right, I'm conflating the two. I mean to be saying intellectual property law in general, which I am not a huge fan of.
If you're against "intellectual property" then you shouldn't use that propaganda term. Refer to the specific legal protections at issue, like copyright, patents, or trademarks, because they are all have very different functions and purposes.
http://www.gnu.org/philosophy/not-ipr.html
http://www.gnu.org/philosophy/not-ipr.html
Copyrights, patents and trademarks all share a single unifying assumption: ideas are things that can be owned. Since I disagree with that assumption, it makes sense to speak about "disagreeing with intellectual property" if IP is just a synonym for "a legal framework that uses violence to support laws that allow ideas to be owned."
That's an interesting piece, thanks for sharing. I think from the perspective of "what existing pieces of culture can I use to create something new" IP is actually a useful bucket. From the perspective of people who have already created or are consuming that piece of culture, I agree that combining trademark with copyright and patents is not useful.
[deleted]
"The W3C is the guardian of the world wide web"...
I completely disagree. You are the guardian. Every one of us is the guardian.
"Guarding the web" isn't in the W3C's mission at all: http://www.w3.org/Consortium/mission.html They design standards used internationally. That's it.
I completely disagree. You are the guardian. Every one of us is the guardian.
"Guarding the web" isn't in the W3C's mission at all: http://www.w3.org/Consortium/mission.html They design standards used internationally. That's it.
> The W3C is the guardian of the world wide web
At least they were.
At least they were.
It matters because of two things:
1 - We'll lose the W3C. We'll have to either create another standards body, or go back to the 90's situation when nobody agreed on anything.
2 - There are a few places where actualy reading the data somebody sent to you is a crime. Despite the drawbacks on those kinds of law, some of those places are still very importantly economically, and we can't just ignore them, at least for now. If you create a code for "don't read this data" to be sent over the web, disobeying it will become a crime there.
1 - We'll lose the W3C. We'll have to either create another standards body, or go back to the 90's situation when nobody agreed on anything.
2 - There are a few places where actualy reading the data somebody sent to you is a crime. Despite the drawbacks on those kinds of law, some of those places are still very importantly economically, and we can't just ignore them, at least for now. If you create a code for "don't read this data" to be sent over the web, disobeying it will become a crime there.
> 1 - We'll lose the W3C. We'll have to either create another standards body, or go back to the 90's situation when nobody agreed on anything.
We already lost the W3C once for about 10 years. Remember XHTML and XHTML2? Those, and a bunch of special purpose not particularly interesting niche XML standards (P3P? XML-FO?) were pretty much all they worked on for a decade or so. It wasn't until the WHATWG was formed by some browser vendors who wanted to start working on a standard for features that users would actually want, rather than what architecture astronauts thought would be a nice design, and the W3C realized that's what people were actually interested in and so replaced XHTML2 with HTML5 based on the WHATWG spec that they actually became relevant again.
Now, I will have to give credit that there were still a few groups at the W3C doing work relevant to the actual open web, such as SVG and CSS. But given how the WHATWG took over work on the HTML standard and actually did work towards a standard that was useful and relevant to browser vendors when the W3C went off the rails the last time means that I'm not too worried if it goes off the rails again this time, you can always form another standards body if it becomes irrelevant. You just need to be sure to recognize this early on, so you don't waste too much time and effort waiting for the W3C to get its act together again.
We already lost the W3C once for about 10 years. Remember XHTML and XHTML2? Those, and a bunch of special purpose not particularly interesting niche XML standards (P3P? XML-FO?) were pretty much all they worked on for a decade or so. It wasn't until the WHATWG was formed by some browser vendors who wanted to start working on a standard for features that users would actually want, rather than what architecture astronauts thought would be a nice design, and the W3C realized that's what people were actually interested in and so replaced XHTML2 with HTML5 based on the WHATWG spec that they actually became relevant again.
Now, I will have to give credit that there were still a few groups at the W3C doing work relevant to the actual open web, such as SVG and CSS. But given how the WHATWG took over work on the HTML standard and actually did work towards a standard that was useful and relevant to browser vendors when the W3C went off the rails the last time means that I'm not too worried if it goes off the rails again this time, you can always form another standards body if it becomes irrelevant. You just need to be sure to recognize this early on, so you don't waste too much time and effort waiting for the W3C to get its act together again.
> W3C realized that's what people were actually interested in
So, with XHTML, the main thing is that people just wanted their web pages to work like they always had; they didn't want to deal with adding slashes to make their web pages XML and strict parsers and whatnot.
But with P3P, what people want is Netflix and Rdio on all their devices (such as ARM-based Samsung Chromebooks).
Frankly, I prefer the sound of standardized DRM to everyone rolling their own ala the 90s; with any luck it'll mean fewer formats/keys that need to be reverse engineered and whatnot.
So, with XHTML, the main thing is that people just wanted their web pages to work like they always had; they didn't want to deal with adding slashes to make their web pages XML and strict parsers and whatnot.
But with P3P, what people want is Netflix and Rdio on all their devices (such as ARM-based Samsung Chromebooks).
Frankly, I prefer the sound of standardized DRM to everyone rolling their own ala the 90s; with any luck it'll mean fewer formats/keys that need to be reverse engineered and whatnot.
First of all, I think you have gotten P3P confused with EME (or whatever the new term is). P3P, the "platform for privacy protection" was just one of my examples of previous useless stuff the W3C has worked on (it was basically a schema for describing a website's privacy policy, with dubious advantages over simply linking to a privacy policy in the footer).
Second, none of the proposals for EME that I've seen actually address the issue of being able to play the same content across devices. They aren't a standardized DRM scheme; they are merely hooks for proprietary DRM schemes, essentially a way to allow proprietary DRM schemes to hook into the HTML5 media player rather than having to use the plugin interface and implement the media player in Flash or Silverlight. It's basically just a plugin API for plugins that provide only DRM, leaving the rest up to the browser.
Don't think that this is meant to actually increase interoperability; a large portion of the "value" of DRM, for those who promote it, it the ability to have various lucrative exclusive contracts with particular cable networks, hardware vendors, and so on. You're just going to see more "Live NFL - a Samsung exclusive!", not actually be able to get Netflix on any device you want.
If it worked across any device, then it would need to work on open devices as well, but of course if the device is open you can bypass the DRM. So it's always going to be based on licenses, that only certain vendors can get if they promise to implement DRM securely and not give users full access to their own devices.
Second, none of the proposals for EME that I've seen actually address the issue of being able to play the same content across devices. They aren't a standardized DRM scheme; they are merely hooks for proprietary DRM schemes, essentially a way to allow proprietary DRM schemes to hook into the HTML5 media player rather than having to use the plugin interface and implement the media player in Flash or Silverlight. It's basically just a plugin API for plugins that provide only DRM, leaving the rest up to the browser.
Don't think that this is meant to actually increase interoperability; a large portion of the "value" of DRM, for those who promote it, it the ability to have various lucrative exclusive contracts with particular cable networks, hardware vendors, and so on. You're just going to see more "Live NFL - a Samsung exclusive!", not actually be able to get Netflix on any device you want.
If it worked across any device, then it would need to work on open devices as well, but of course if the device is open you can bypass the DRM. So it's always going to be based on licenses, that only certain vendors can get if they promise to implement DRM securely and not give users full access to their own devices.
> They aren't a standardized DRM scheme; they are merely hooks for proprietary DRM schemes, essentially a way to allow proprietary DRM schemes to hook into the HTML5 media player rather than having to use the plugin interface and implement the media player in Flash or Silverlight. It's basically just a plugin API for plugins that provide only DRM, leaving the rest up to the browser.
Exactly: its a specification for a constrained plugin API focussed DRM, so that browsers don't have to either maintain a common general purpose plugin API (e.g., NPAPI) or, alternatively, have browser-specific APIs in order to meet content-owners demand for a DRM-supporting delivery channel.
Exactly: its a specification for a constrained plugin API focussed DRM, so that browsers don't have to either maintain a common general purpose plugin API (e.g., NPAPI) or, alternatively, have browser-specific APIs in order to meet content-owners demand for a DRM-supporting delivery channel.
Yes, I typed the acronym wrong; that's what I get for writing HN comments in the middle of the night.
I agree with the rest of what you've said, but I don't think the typical end-user worries about "openness" until it's too late.
I agree with the rest of what you've said, but I don't think the typical end-user worries about "openness" until it's too late.
> architecture astronauts
That's an awesome term for something I never quite had a word for.
That's an awesome term for something I never quite had a word for.
I suspect this may be the article that introduced the term:
http://www.joelonsoftware.com/articles/fog0000000018.html
http://www.joelonsoftware.com/articles/fog0000000018.html
1. I don't agree that this is true at all. The W3C is not created to destroy copyright, which seems to be the implication of your statement (ie: we will need a new standards body that does not provide a copyright-compliant standard). I don't agree with copyright law, but it is law. We currently have a web that provides the ability to companies to protect their data via implementation, this simply provides a spec to do it in a different way. It does not fundamentally change the user experience of the web.
2. Yes, like in the United States. Just like receiving stolen goods is a crime. No offense, but when you say things like "If you create a code for "don't read this data" to be sent over the web, disobeying it will become a crime there." I don't think you fully understand how DRM currently works and how it would work using this standard. It is simply a standard people can implement.
Edit: as some of you have pointed out, the phrase "copyright-compliant" is somewhat meaningless. I should've chosen my words more carefully. I meant "copyright-enforcement-enabling."
2. Yes, like in the United States. Just like receiving stolen goods is a crime. No offense, but when you say things like "If you create a code for "don't read this data" to be sent over the web, disobeying it will become a crime there." I don't think you fully understand how DRM currently works and how it would work using this standard. It is simply a standard people can implement.
Edit: as some of you have pointed out, the phrase "copyright-compliant" is somewhat meaningless. I should've chosen my words more carefully. I meant "copyright-enforcement-enabling."
> The W3C is not created to destroy copyright, which seems to be the implication of your statement (ie: we will need a new standards body that does not provide a copyright-compliant standard).
No, what he means is that, if we stop listening to the W3C because of this, the W3C will no longer matter. So either we won't have a standards body, or we will need a new one.
No, what he means is that, if we stop listening to the W3C because of this, the W3C will no longer matter. So either we won't have a standards body, or we will need a new one.
And why would we stop listening to the W3C because of this?
Exactly. There are countless standards issued by the W3C that are completely ignored by Browser Vendors at large. Yet it's still the most relevant consortium on the matter.
Conversely, there are countless features introduced by Browser Vendors that do not exist in the W3C's specs. (And some of those are even eventually picked up by the W3c.)
I honestly don't think people understand how the Standards Body's work, and how their specs propagate into actual products that people use on a daily basis.
Many companies have cherry-picked what to implement and what not to. This is not new. If anything, it's the norm. Vendors will continue to do this as long as the W3C will exist, and can continue to do so in this case, without destroying the W3C or making it an invalid body.
This particular argument is totally bunk.
Conversely, there are countless features introduced by Browser Vendors that do not exist in the W3C's specs. (And some of those are even eventually picked up by the W3c.)
I honestly don't think people understand how the Standards Body's work, and how their specs propagate into actual products that people use on a daily basis.
Many companies have cherry-picked what to implement and what not to. This is not new. If anything, it's the norm. Vendors will continue to do this as long as the W3C will exist, and can continue to do so in this case, without destroying the W3C or making it an invalid body.
This particular argument is totally bunk.
It was your own suggestion that spawned this thread.
You wrote:
"I may be totally naive here, but I'm not really sure why this matters. That there is a WC3 standard does not imply that browsers have to adhere to it." - https://news.ycombinator.com/item?id=6491428
marcosdumay is responding to that by saying "It matters because ..."
You wrote:
"I may be totally naive here, but I'm not really sure why this matters. That there is a WC3 standard does not imply that browsers have to adhere to it." - https://news.ycombinator.com/item?id=6491428
marcosdumay is responding to that by saying "It matters because ..."
Sorry, fair point. My point that you quoted was that anyone could roll a browser that did not include the DRM standard (or any standard for that matter). And many do already. I don't think this implies that the W3C is dead.
anyone could roll a browser that did not include the DRM standard
And how many people will use it, apart from outliers like people who post here? The vast majority of people use one of the Big Three: Firefox, Internet Exploder [no, that's not a typo ;)], and Chrome.
Furthermore, if the Big Three implement a DRM standard, then web pages that want to "protect their content" will simply use the DRM standard, and it won't matter that Joe's Really Cool Browser doesn't implement it; that browser simply won't be able to view the pages. A few outliers like us will rant and rave; anyone else who tries it will say "Joe's Really Cool Browser Sucks" and go back to using one of the Big Three.
And how many people will use it, apart from outliers like people who post here? The vast majority of people use one of the Big Three: Firefox, Internet Exploder [no, that's not a typo ;)], and Chrome.
Furthermore, if the Big Three implement a DRM standard, then web pages that want to "protect their content" will simply use the DRM standard, and it won't matter that Joe's Really Cool Browser doesn't implement it; that browser simply won't be able to view the pages. A few outliers like us will rant and rave; anyone else who tries it will say "Joe's Really Cool Browser Sucks" and go back to using one of the Big Three.
DRM can not work. Assuming that you don't come up with a plan, which prevents reading data, while allowing the reading of data. So if the W3C starts to write standards which defy the basis of logic, were are forced to abandon their standards, thus destroying the W3C.
Copyright-compliant standard? How is the existing standard not compliant with copyrights?
This is not about making a copyright-friendly web. This is about attacking the openness of the web.
This is not about making a copyright-friendly web. This is about attacking the openness of the web.
> Despite the drawbacks on those kinds of law, some of those places are still very importantly economically, and we can't just ignore them
Browsers have plug-in architectures. DRM systems are inherently proprietary. Leave them to implement proprietary plug-ins.
Browsers have plug-in architectures. DRM systems are inherently proprietary. Leave them to implement proprietary plug-ins.
Oh sure, that's the logical solution.
In reality though these control freak moves only "work" (for them) if everybody is forced to adopt. Another site another plugin type situation will shift a lot of people to non-drm content providers, whether on principle or maybe just plain old apathy. I'm sure browser makers could streamline this process so that it's a minimal hurdle to install a plugin but if it's optional then we have the option to avoid it and that is exactly what those goddamn morons would like to stop.
In reality though these control freak moves only "work" (for them) if everybody is forced to adopt. Another site another plugin type situation will shift a lot of people to non-drm content providers, whether on principle or maybe just plain old apathy. I'm sure browser makers could streamline this process so that it's a minimal hurdle to install a plugin but if it's optional then we have the option to avoid it and that is exactly what those goddamn morons would like to stop.
"> It's a place where the next Tim Berners-Lee or Mozilla, if they were building a new browser from scratch, couldn't just look up the details of all the "Web" technologies. They'd have to negotiate and sign compliance agreements with a raft of DRM providers just to be fully standards-compliant and interoperable."
What the hell are they even talking about here? Since when has ANY browser been "Fully, 100% W3C Compliant"?? Answer: None. Ever. Seriously.
There are rafts of non-compliant features, both legacy and newly introduced, in every single one of the most popular modern web browsers. (Even Opera!!) Certainly, with the last decade of popular support pushing Browser Vendors towards W3C compliance, the web has been more standards-based than ever before.
But this is just a silly argument. I agree with the political aim of the EFF here. But let's not just invent things or misrepresent things. It makes them lose credibility in my eyes.
What the hell are they even talking about here? Since when has ANY browser been "Fully, 100% W3C Compliant"?? Answer: None. Ever. Seriously.
There are rafts of non-compliant features, both legacy and newly introduced, in every single one of the most popular modern web browsers. (Even Opera!!) Certainly, with the last decade of popular support pushing Browser Vendors towards W3C compliance, the web has been more standards-based than ever before.
But this is just a silly argument. I agree with the political aim of the EFF here. But let's not just invent things or misrepresent things. It makes them lose credibility in my eyes.
Sure, not everything is standards-compliant, nor fully interoperable. But part of the transformative effect of open Internet standards has been that anyone can implement them without permission from others (indeed, the IP policy of the W3C is pretty much engineered to make this the case).
If you want to implement a DRM binary blob with EME, you're going to have to negotiate a compliance contract of some kind with the DRM vendor, probably connected to some hook IP. (See http://en.wikipedia.org/wiki/Compliance_and_Robustness )
If you want to implement a DRM binary blob with EME, you're going to have to negotiate a compliance contract of some kind with the DRM vendor, probably connected to some hook IP. (See http://en.wikipedia.org/wiki/Compliance_and_Robustness )
The problem isn't that browsers do or don't have to implement this "standard"; the problem is that the standard itself isn't enough to actually support the content it claims to support.
It's the equivalent of standardizing the object or embed tags: it's a standard way of getting at non-standard functionality, and sites then depend on specific implementations of that non-standard functionality, the same way they depend on the Flash plugin today in ways that knowing how to implement the object tag doesn't help with.
Standardizing a single fully-specified mechanism for DRM might actually be useful (debatably), but that would break the current model in which DRM is completely unsound and relies on security-through-obscurity. "Standardizing" a means of getting at the myriad non-standard DRM implementations and their non-standard APIs is worse than worthless: it's actively harmful, and it prolongs the death of those technologies.
Right now, content providers have to choose whether to support the open web or DRM. They should continue to have to make that choice, with supporters of the open web reaching a larger audience, until eventually all the holdouts either switch or lose. This is a major step backward for that goal, and the W3C has no business claiming EME has anything to do with the open web.
It's the equivalent of standardizing the object or embed tags: it's a standard way of getting at non-standard functionality, and sites then depend on specific implementations of that non-standard functionality, the same way they depend on the Flash plugin today in ways that knowing how to implement the object tag doesn't help with.
Standardizing a single fully-specified mechanism for DRM might actually be useful (debatably), but that would break the current model in which DRM is completely unsound and relies on security-through-obscurity. "Standardizing" a means of getting at the myriad non-standard DRM implementations and their non-standard APIs is worse than worthless: it's actively harmful, and it prolongs the death of those technologies.
Right now, content providers have to choose whether to support the open web or DRM. They should continue to have to make that choice, with supporters of the open web reaching a larger audience, until eventually all the holdouts either switch or lose. This is a major step backward for that goal, and the W3C has no business claiming EME has anything to do with the open web.
Say you're a netflix customer. You login to watch a video. But Netflix hasn't updated to support your amazing new device that uses a different OS.
Pretty much like Firefox and IE6 activeX sites, or iPhones / android and flash. DRM simply restricts playback devices.
Pretty much like Firefox and IE6 activeX sites, or iPhones / android and flash. DRM simply restricts playback devices.
"From a UX perspective this seems no different from Netflix putting their content behind a login."
That depends on where you think UX ends. That login will work fine from within an open source browser and/or OS you compiled (and possibly wrote or tweaked) yourself.
I haven't read the article, but if that DRM works, it wouldn't run in your browser on your OS, as content providers would not trust them. Chances are that your Chrome, Firefox, or Safari extensions wouldn't even work with the DRM (at best, they would get disabled on protected (from you) pages.)
That depends on where you think UX ends. That login will work fine from within an open source browser and/or OS you compiled (and possibly wrote or tweaked) yourself.
I haven't read the article, but if that DRM works, it wouldn't run in your browser on your OS, as content providers would not trust them. Chances are that your Chrome, Firefox, or Safari extensions wouldn't even work with the DRM (at best, they would get disabled on protected (from you) pages.)
That would be the dystopian outcome if the sites and browsers together diverged from open standards and started forcing DRM on everyone.
What this standard actually specifies however, is only that the browser will respond to a certain tag by looking for some proprietary-ware to play whatever audio and/or video someone wants to restrict.
This is a disappointing move on the part of w3c, because it lends some air of legitimacy to DRM, and because it revives the otherwise dying plugin system under a new name. But it doesn't actually force DRM on anyone or restrict the ability to do anything on the web.
The best case would be that users are unwilling to install the black-box-ware in order to see videos or whatever, and the feature is little used and the copyright exploiters have to either unlock the content or go away with it. None of which would be bad.
What this standard actually specifies however, is only that the browser will respond to a certain tag by looking for some proprietary-ware to play whatever audio and/or video someone wants to restrict.
This is a disappointing move on the part of w3c, because it lends some air of legitimacy to DRM, and because it revives the otherwise dying plugin system under a new name. But it doesn't actually force DRM on anyone or restrict the ability to do anything on the web.
The best case would be that users are unwilling to install the black-box-ware in order to see videos or whatever, and the feature is little used and the copyright exploiters have to either unlock the content or go away with it. None of which would be bad.
This is a bit of an exaggeration, we have had content like this on the web for years with proprietary technologies like flash, silverlight ,activeX and highly obfuscated JS. Not to mention the amount of content locked into walled gardens and proprietary app stores etc.
The W3 proposals suggested do not in fact mandate browser vendors implement any DRM scheme to remain 100% standards compliant. This is myth that gets repeated on HN surprisingly often.
The issue is that some big name content providers don't want to sell you content unless they can also install things on your computer. This fact remains regardless of the technological implementation details.
The overwhelming majority of content on the web is DRM free. These proposals do not mandate nor give any incentive for that content to be protected if it is not already.
The W3 proposals suggested do not in fact mandate browser vendors implement any DRM scheme to remain 100% standards compliant. This is myth that gets repeated on HN surprisingly often.
The issue is that some big name content providers don't want to sell you content unless they can also install things on your computer. This fact remains regardless of the technological implementation details.
The overwhelming majority of content on the web is DRM free. These proposals do not mandate nor give any incentive for that content to be protected if it is not already.
>The issue is that some big name content providers don't want to sell you content unless they can also install things on your computer. This fact remains regardless of the technological implementation details.
Sure, but we don't have to aid them in their quest
>The overwhelming majority of content on the web is DRM free. These proposals do not mandate nor give any incentive for that content to be protected if it is not already.
The practical effect of being able to deliver DRM'd content to every non-technical web user, without first having to get that user to download and install your proprietary software, is just massive. This is one of the biggest falloff points in the conversion funnel, so it makes this new delivery method highly attractive. As it is now, businesses have to balance the cost of losing customers against the cost of not being able to DRM their content. Take that dilemma away and I think you certainly have a new incentive. The practical effects of this are far reaching imo.
Sure, but we don't have to aid them in their quest
>The overwhelming majority of content on the web is DRM free. These proposals do not mandate nor give any incentive for that content to be protected if it is not already.
The practical effect of being able to deliver DRM'd content to every non-technical web user, without first having to get that user to download and install your proprietary software, is just massive. This is one of the biggest falloff points in the conversion funnel, so it makes this new delivery method highly attractive. As it is now, businesses have to balance the cost of losing customers against the cost of not being able to DRM their content. Take that dilemma away and I think you certainly have a new incentive. The practical effects of this are far reaching imo.
"As it is now, businesses have to balance the cost of losing customers against the cost of not being able to DRM their content. Take that dilemma away and I think you certainly have a new incentive."
And the businesses (Hollywood) with the content that Web users want have done that math and decided that DRM through plug-ins and native apps is an EXCELLENT system and they're happy to keep mandating it forever. If Plug-ins go away, as they're slowly but surely doing, then native apps will be the only place to get this content.
Hacker News types, myself included, will cringe at this truth, but most consumers don't give a shit about the Web. They care about the content the Web gives them. If the Web cannot give them the content they want, they'll get it elsewhere, probably from silo'd App Stores where things "just work."
And the businesses (Hollywood) with the content that Web users want have done that math and decided that DRM through plug-ins and native apps is an EXCELLENT system and they're happy to keep mandating it forever. If Plug-ins go away, as they're slowly but surely doing, then native apps will be the only place to get this content.
Hacker News types, myself included, will cringe at this truth, but most consumers don't give a shit about the Web. They care about the content the Web gives them. If the Web cannot give them the content they want, they'll get it elsewhere, probably from silo'd App Stores where things "just work."
If the Web cannot give them the content they want, they'll get it elsewhere, probably from silo'd App Stores where things "just work."
And in this scenario (i.e., the way things are now), someone like me, who doesn't give a shit about "content" but does care about the Web itself, can still avoid DRM by not installing the plugins, not using the silo'd App Stores, etc. But if my browser is the silo'd plugin/App Store, I'm SOL. That is why all this matters: it makes DRM and all of the closed source nastiness that goes with it the default, instead of something people have to choose. I think that's a very, very bad idea.
And in this scenario (i.e., the way things are now), someone like me, who doesn't give a shit about "content" but does care about the Web itself, can still avoid DRM by not installing the plugins, not using the silo'd App Stores, etc. But if my browser is the silo'd plugin/App Store, I'm SOL. That is why all this matters: it makes DRM and all of the closed source nastiness that goes with it the default, instead of something people have to choose. I think that's a very, very bad idea.
This is unlikely to change. Firefox at least is not about to ship with DRM plugins built in, any more than it comes with Flash built in now.
EME is not strictly DRM in your browser: it's a standardised interface to allow your browser to talk to DRM modules.
EME is not strictly DRM in your browser: it's a standardised interface to allow your browser to talk to DRM modules.
> Hacker News types, myself included, will cringe at this truth, but most consumers don't give a shit about the Web. They care about the content the Web gives them. If the Web cannot give them the content they want, they'll get it elsewhere, probably from silo'd App Stores where things "just work."
I don't cringe at that, it's just the way it is. But I promise you no-install browser delivery of DRM'd content which "just works" is very valuable to those businesses. People grab the thing within arm's reach. Sure, if there isn't anything in arm's reach a decent amount of them will still walk across the room for what they want, but I think that's besides the point.
I don't cringe at that, it's just the way it is. But I promise you no-install browser delivery of DRM'd content which "just works" is very valuable to those businesses. People grab the thing within arm's reach. Sure, if there isn't anything in arm's reach a decent amount of them will still walk across the room for what they want, but I think that's besides the point.
> If the Web cannot give them the content they want, they'll
> get it elsewhere, probably from silo'd App Stores where
> things "just work."
That's entirely reasonable. Silo'd 'app stores' are where things like DRM belong, not the World Wide Web.
> get it elsewhere, probably from silo'd App Stores where
> things "just work."
That's entirely reasonable. Silo'd 'app stores' are where things like DRM belong, not the World Wide Web.
It seems odd for HN to be in favour of making technology & content marginally less accessible simply to spite people.
Perhaps there exists a class of people who wanted to implement DRM on all of their content but were just waiting for the W3s blessing but such a class will be extremely small.
Most of the DRM you see comes from mandates from big content firms, most other people could give less of a shit.
Perhaps there exists a class of people who wanted to implement DRM on all of their content but were just waiting for the W3s blessing but such a class will be extremely small.
Most of the DRM you see comes from mandates from big content firms, most other people could give less of a shit.
DRM'd content isn't accessible and that's the entire problem. Adding a standardized hook for DRM modules to use creates the illusion that things got accessible that previously weren't.
Try exercising your fair-use rights on those DRM'd bits for example.
Try exercising your fair-use rights on those DRM'd bits for example.
Browser vendors don't have to implement any DRM scheme, but they will and sites will use them. What this means in practice is that there will be 100% standards compliant, pure HTML5 websites that can only legally be rendered in specific, proprietary browsers. The stated purpose of HTML5 EME is to make it a criminal offence under the DMCA anti-circumvention clause to develop an unauthorised browser or extension that displays the protected content.
If anything this is worse than proprietary plugins because those used documented APIs that any browser could support, whereas this is integrated into the web browser itself.
If anything this is worse than proprietary plugins because those used documented APIs that any browser could support, whereas this is integrated into the web browser itself.
If anything it's the opposite. Defining a standard interface for content decryption allows such a system to be browser agnostic. You install a module and it works in any browser which implements the spec, whether proprietary or open source.
Unless they've changed it since I looked, the only interface the HTML5 EME specification defines is the one between the website and the browser. There is no standardized interface between browsers and DRM modules, nor is there any requirement browsers support external content decryption modules. For example, last I heard IE was only going to support a built-in implementation of Microsoft's PlayReady which isn't available to anyone else.
In fact it's not clear that anyone can use a standardized, open API for decryption modules and meet content providers' security demands. While some of them were historically willing to use Flash which did use standard browser APIs, they've taken this as an opportunity to demand more.
In fact it's not clear that anyone can use a standardized, open API for decryption modules and meet content providers' security demands. While some of them were historically willing to use Flash which did use standard browser APIs, they've taken this as an opportunity to demand more.
There's a good diagram on the w3 page.
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...
It looks like the idea is to implement a system where encrypted content is passed to the browser. The key is then sent through the browser to the CDM, the CDM can take the content and hand back decrypted frames.
It's entirely possible for content vendors to support multiple CDMs for different browser or OS combinations. The advantage of this is that the CDM is a smaller dependency than something like silverlight, so you can have a standard HTML5 video player interface across platforms and just swap out CDMs.
It looks like the idea is to implement a system where encrypted content is passed to the browser. The key is then sent through the browser to the CDM, the CDM can take the content and hand back decrypted frames.
It's entirely possible for content vendors to support multiple CDMs for different browser or OS combinations. The advantage of this is that the CDM is a smaller dependency than something like silverlight, so you can have a standard HTML5 video player interface across platforms and just swap out CDMs.
That won't work. If the restrictions module simply hands back the decrypted data then you could just change the browser to dump the data on your disk.
The only way it will work is if the restrictions module handles everything from decryption, decoding, to rendering. Probably even using a hardware DRM scheme and preventing any interaction of the video data with the JavaScript or any other website elements.
The only way it will work is if the restrictions module handles everything from decryption, decoding, to rendering. Probably even using a hardware DRM scheme and preventing any interaction of the video data with the JavaScript or any other website elements.
If you read the spec: "The Content Decryption Module (CDM) is a generic term for a part of or add-on to the user agent that provides functionality for one or more Key Systems. Implementations may or may not separate the implementations of CDMs and may or may not treat them as separate from the user agent."
So the CDM isn't necessarily seperate from the browser itself - that's left totally as an implementation decision, and at least one widespread implementation (IE11) is integrating the CDM tightly into the browser. Also, even if the CDM is seperate it can render frames directly to the screen without passing through the browser. In particular, note that:
"Where media rendering is not performed by the UA, for example in the case of a hardware protected media pipeline, then the full set of HTML rendering capabilities, for example CSS Transforms, may not be available. One likely restriction is that video media may be constrained to appear only in rectangular regions with sides parallel to the edges of the window and with normal orientation."
So basically, just like with existing plugins, encrypted content is an opaque rectangle plonked on top of the web page that's not part of the browser's normal rendering pathway.
So the CDM isn't necessarily seperate from the browser itself - that's left totally as an implementation decision, and at least one widespread implementation (IE11) is integrating the CDM tightly into the browser. Also, even if the CDM is seperate it can render frames directly to the screen without passing through the browser. In particular, note that:
"Where media rendering is not performed by the UA, for example in the case of a hardware protected media pipeline, then the full set of HTML rendering capabilities, for example CSS Transforms, may not be available. One likely restriction is that video media may be constrained to appear only in rectangular regions with sides parallel to the edges of the window and with normal orientation."
So basically, just like with existing plugins, encrypted content is an opaque rectangle plonked on top of the web page that's not part of the browser's normal rendering pathway.
Yes, but it wont be OS agnostic. So it might work on all browsers on Windows but not in any one FreeBSD.
Not true at all, there is nothing in the spec that mandates the use of any particular OS.
But there's nothing compelling plugin developers to support all OS/browser combinations, so no, in practice it likely won't be OS-agnostic.
This scheme basically just creates a special class of plugins; these plugins clearly won't be OS-agnostic, because they can't -- that's the whole point of the exercise: to restrict playback to devices that are fully authorised/controlled from top to bottom, with the browser piping streams from the web to trusted plugins running on trusted OSes using trusted hardware (TPM etc).
This scheme basically just creates a special class of plugins; these plugins clearly won't be OS-agnostic, because they can't -- that's the whole point of the exercise: to restrict playback to devices that are fully authorised/controlled from top to bottom, with the browser piping streams from the web to trusted plugins running on trusted OSes using trusted hardware (TPM etc).
Isn't this the same with all software? There is never anything mandating that anybody supports your OS or browser of choice.
If I want to watch netflix or play GTA5 on my haiku box I'm SOL as it is unless there is a business case to be made for doing the port.
This actually makes things easier. For example netflix currently uses silverlight for their streaming, this means that in order to watch netflix you need something that supports the entire silverlight stack.
With this proposal all you need is modern browser and a compatible CDM which is a much smaller chunk of code.
If I want to watch netflix or play GTA5 on my haiku box I'm SOL as it is unless there is a business case to be made for doing the port.
This actually makes things easier. For example netflix currently uses silverlight for their streaming, this means that in order to watch netflix you need something that supports the entire silverlight stack.
With this proposal all you need is modern browser and a compatible CDM which is a much smaller chunk of code.
Much smaller, I don't think. It will still have to grab the screen and render directly onto it. It's basically the same thing a regular plugin would do except a little bit of identity validation, from what I understand.
Technically speaking it's almost the same as the status quo, but a little bit of DRM principles have now been enshrined in the foundations of our web. Depending on what your view of DRM is, of course, this is good news or bad news; but from a technical point of view, it changes very, very little.
Technically speaking it's almost the same as the status quo, but a little bit of DRM principles have now been enshrined in the foundations of our web. Depending on what your view of DRM is, of course, this is good news or bad news; but from a technical point of view, it changes very, very little.
Indeed, this changes nothing technically. But what it does is harm the idea that standards should promote the the open web. You may or may not agree to this idea of course.
> Isn't this the same with all software?
That's exactly the point, the case is NOT so with HTML and JavaScript. A webapp I write in HTML and JavaScript is OS agnostic!
That's exactly the point, the case is NOT so with HTML and JavaScript. A webapp I write in HTML and JavaScript is OS agnostic!
It's not the same because HTML5 EME is designed to ensure anyone who manages to get media working on unauthorized platforms can be arrested under the anti-circumvention provisions of the DMCA and other similar laws. As in, this was actually one of the stated requirements.
This is simply incorrect, can you show a w3 document that supports this in any way?
Is there anything in the spec that ensures compatibility with more than one OS?
Is there anything in the TCP/IP spec that ensures compatibility with more than one OS?
TCP/IP is an open standard, DRM are not.
Your statement is as wrong technically as stating that encryption cannot be open source. What matters are the keys, not the code.
The purpose of encryption is to secure communications between two trusted endpoints against untrusted intermediaries. Since all parties to the exchange are trusted and the intent is for both parties to have access to the data, an open source encryption system works.
DRM's purpose is similar, but one of the endpoints is in the physical control of an untrusted entity: you. Since the point of DRM is to prevent the user at one of the endpoints from accessing the data, if you have the source and keys to the destination endpoint (e.g. TPM, HDCP-enabled GPU), the endpoint can't be trusted, you can get the data, and the DRM fails at its purpose.
DRM's purpose is similar, but one of the endpoints is in the physical control of an untrusted entity: you. Since the point of DRM is to prevent the user at one of the endpoints from accessing the data, if you have the source and keys to the destination endpoint (e.g. TPM, HDCP-enabled GPU), the endpoint can't be trusted, you can get the data, and the DRM fails at its purpose.
If Digital Restrictions Management gets added to HTML5 then it makes it far easier for content hosts to add restrictions. This is a huge risk.
But more importantly the idea of HTML5 was to get rid of proprietary closed source plugins like Flash. Adding DRM to HTML5 will make it rely on proprietary closed source plugins.
I hope the W3C reconsiders. If somebody feels the need for DRM then they should implement their own stuff outside of the open web.
But more importantly the idea of HTML5 was to get rid of proprietary closed source plugins like Flash. Adding DRM to HTML5 will make it rely on proprietary closed source plugins.
I hope the W3C reconsiders. If somebody feels the need for DRM then they should implement their own stuff outside of the open web.
We've already got Silverlight, Flash, Java, so on and so forth... denying DRM entry to HTML won't stop DRM web content, and allowing it might just make the experience less miserable.
It will make it more miserable, because EME is not a standard DRM, it's a plug-in interface for launching browser-specific/vendor-specific DRM plug-ins. DRM plug-ins are allowed to do whatever they want, and proponents at W3C want to completely bypass the browser and have DRM all the way from TPM to HDCP.
Makers of Flash and Silverlight were a 3rd party in the DRM battle. They had to worry about their plugins' marketshare and could not implement too user-hostile DRM. They had to balance pleasing media corporations and users.
Now there won't be anything stopping MPAA's CEOs wet dreams running in your OS's kernel. Media corps have Netflix and Google (Play Store) in their pockets and can force them to ship all kinds of nastiness — under W3C's brand name.
Makers of Flash and Silverlight were a 3rd party in the DRM battle. They had to worry about their plugins' marketshare and could not implement too user-hostile DRM. They had to balance pleasing media corporations and users.
Now there won't be anything stopping MPAA's CEOs wet dreams running in your OS's kernel. Media corps have Netflix and Google (Play Store) in their pockets and can force them to ship all kinds of nastiness — under W3C's brand name.
Here's the membership list of the W3C: http://www.w3.org/Consortium/Member/List
It would be great if anyone opposed to this would contact an organization on this list, ask them why they're endorsing and funding DRM and the end of the free Web, and if not, when they will be resigning from the W3C.
Every name you can get stricken from the list is up to around $70,000 per year defunded from what is now most effective driver of DRM in the world. [1] Getting some public statements from the membership would be educational, if nothing else.
[1] http://www.w3.org/Consortium/fees?countryCode=US&quarter=10-...
It would be great if anyone opposed to this would contact an organization on this list, ask them why they're endorsing and funding DRM and the end of the free Web, and if not, when they will be resigning from the W3C.
Every name you can get stricken from the list is up to around $70,000 per year defunded from what is now most effective driver of DRM in the world. [1] Getting some public statements from the membership would be educational, if nothing else.
[1] http://www.w3.org/Consortium/fees?countryCode=US&quarter=10-...
Does the W3C have any authority over web standards or is it just a bunch of circle jerking corporations pretending to have town halls?
How do you think Sony and the EFF will respond?
This is poison and against everything the W3C is set to do according to their own mission statement.
Everything we've spent the last 20 years building and standardising. Now ruined. Tainted.
They have now lost all legitimacy among anyone who calls themselves a proponent of the open web. We need a new leadership as the old one can't be trusted. We need an open web action group to start over.
Thanks for fragmenting the web, W3C. Thanks for nothing, assholes.
Everything we've spent the last 20 years building and standardising. Now ruined. Tainted.
They have now lost all legitimacy among anyone who calls themselves a proponent of the open web. We need a new leadership as the old one can't be trusted. We need an open web action group to start over.
Thanks for fragmenting the web, W3C. Thanks for nothing, assholes.
A bit melodramatic.
The W3C was always a pay-for-play organization led by corporate interests. The full time staff of the W3C were MIT academics trying to foster conversation so that the openness of the web could be preserved among the reality that most funding for browsers was between competitors looking to make a buck. It took enormous pressure and nearly a decade (1994-2004) to foster web standards to the competent mediocrity they are today.
The WHATWG only solidified the corporate interests, by making browser makers The Only Ones Who Matter: Google (who also funds Mozilla), Microsoft, and Apple.
You can claim you want new leadership, but who has the credibility and legitimacy you claim has been lost? Students? Government workers? All competent engineers are working for for-profit companies (or are funded by them) that want to monetize your eyeballs. You could look to academia and government-funding, I suppose, like the original web. But the web is here, now. It's likely not going to be replaced.
Starting over is a loser's game.
The W3C was always a pay-for-play organization led by corporate interests. The full time staff of the W3C were MIT academics trying to foster conversation so that the openness of the web could be preserved among the reality that most funding for browsers was between competitors looking to make a buck. It took enormous pressure and nearly a decade (1994-2004) to foster web standards to the competent mediocrity they are today.
The WHATWG only solidified the corporate interests, by making browser makers The Only Ones Who Matter: Google (who also funds Mozilla), Microsoft, and Apple.
You can claim you want new leadership, but who has the credibility and legitimacy you claim has been lost? Students? Government workers? All competent engineers are working for for-profit companies (or are funded by them) that want to monetize your eyeballs. You could look to academia and government-funding, I suppose, like the original web. But the web is here, now. It's likely not going to be replaced.
Starting over is a loser's game.
This is a clear sign that the W3C now is hostage of the big corporations.. say goodbye to the dream and vision created by the founders of the Web, and what the WWW was meant to be for us all: a democratic place of freedom, education and shareing to all the world.. a world without frontiers, without borders.. infinite as it could be..
All i see now is the corporate internet.. people may not remember this but AOL and the like tried to create privates corporate internet's and lose in the long term.. the world was too big to be contained.. to be controlled..
This is the beginning of the end of what internet was supposed to be?
All i see now is the corporate internet.. people may not remember this but AOL and the like tried to create privates corporate internet's and lose in the long term.. the world was too big to be contained.. to be controlled..
This is the beginning of the end of what internet was supposed to be?
I think you completely have missed the historic charter and nature of the W3C. It always was a pay to play organization, where they highly encouraged corporate or institutional members and dissuaded individual membership. It's very, very different from (say) the IETF.
The intent was to recognize the Web world for what it was: filled with competitive interests with no interest on the integrity of the architecture that had been created. The W3C was a way to bring their engineers together to save the Web from the various marketing departments that were escalating an arms race of proprietary browser features. It was to create a legitimate channel to drive agreements across competitors without antitrust concerns.
It didn't entirely succeed, only somewhat. But this decision is consistent with its history. The W3C is only a reflection of its members.
The intent was to recognize the Web world for what it was: filled with competitive interests with no interest on the integrity of the architecture that had been created. The W3C was a way to bring their engineers together to save the Web from the various marketing departments that were escalating an arms race of proprietary browser features. It was to create a legitimate channel to drive agreements across competitors without antitrust concerns.
It didn't entirely succeed, only somewhat. But this decision is consistent with its history. The W3C is only a reflection of its members.
Actually, they are green-lighting EME, not DRM. EME can be used as part of a DRM system, but it has other possible uses. For instance, one could build a nice system around it to allow a group of friends or family to share private encrypted movies or images.
Fuck the greed, the amount of work that will be wasted from both sides of people trying to implement DRM and others who are trying to bypass DRM should be spent on something more useful like agreeing for once at already implemented standards and making them work cross browser, or implementing new better solutions, but no, it's important to protect Miley Cyrus' songs or the universe will collapse.
Maybe I missed the point here, but firstly, browsers are free to choose to implement some parts of the W3C recommandations right ? and secondly, if the browser you use is implementing the DRM constraint, it's just a browser level restriction right? That mean you can either use a plugin that will fetch the blocked content or use an other browser to do it ?
This is doomed before being born (or I missed something).
This is doomed before being born (or I missed something).
I refuse to engage in blind trust, either that content will remain available (including that of historical or functional significance) or that -- encased in an opaque block -- it will be safely and fairly delivered.
DRM is a non-starter, for me. Keep your shit out of my peanut butter.
DRM is a non-starter, for me. Keep your shit out of my peanut butter.
So implemented DRM will still need to be supported on different platforms and browsers, and after the H264 crap what are the chances of that happening?
They would be better off having some sort of plugin archetecture that allows this kind of development for specific platforms...
They would be better off having some sort of plugin archetecture that allows this kind of development for specific platforms...
Oh, hi Minitel (http://en.wikipedia.org/wiki/Minitel), long time no see.
They got perfectly subverted. I hope they revoke it, can somebody open a petition? I'll sign it!!!
> W3C green-lights adding DRM to the Web's standards
I think I threw up a little in my mouth when I read that.
I think I threw up a little in my mouth when I read that.
The WC3 has sucked for ages. I can't wrap my mind around why anyone follows there lead anymore. Everything that comes out there is overly complicated and totally misses the larger picture. Sound like they've also sold out on top of that now. I say frail them.
Aaaaaaand the W3C is now officially irrelevant.
Web is all about hollywood now, it seems!
OMFG!
How will this work with open-source browsers like Firefox? After all, what's to stop somebody from publishing an extension or even a modified version of the browser itself? DRM seems fundamentally unenforceable, after all.
Are the people pushing for this hoping it's just too much hassle?
These questions aren't rhetorical: I'm interested in what exactly the DRM people are pushing and how they expect it to work. Just not interested enough to read about it myself :D. (Also, I think this makes for a great conversation topic.)
Are the people pushing for this hoping it's just too much hassle?
These questions aren't rhetorical: I'm interested in what exactly the DRM people are pushing and how they expect it to work. Just not interested enough to read about it myself :D. (Also, I think this makes for a great conversation topic.)
In most DRM systems the information is distributed encrypted. The decryption keys are given to technology developers who have specifically promised to obey the DRM rules, as well as to make their technology hard for users to understand or modify so that the users can't easily undo the restrictions or extract the decryption keys.
Hence a browser developer or OS developer or developer of whatever software is in question wouldn't be permitted (by the DRM system's inventor or administrator) to get decryption keys if they didn't promise to implement these restrictions.
Some of the people who invented the modern DRM business ecology called this "the intersection of technology, law, and commercial licensing" (the title of a 1996 article by Dean Marks and Bruce Turnbull). Here, the "technology" is DRM implementations -- including software obfuscation and other measures; the "law" is anticircumvention laws like the DMCA §1201 that make it risky for people to use the decryption keys in ways that industry dislikes; and "commercial licensing" is the permission from a DRM developer to interoperate with that DRM, including "compliance" rules (about the functionality of the technology product) and "robustness" rules (about tamper-resistance), that result in the licensee being issued decryption keys.
In my view (I worked on EFF's objection) this is a deliberate attack on software interoperability: the whole point is to allow someone to try to prevent interoperability with software that hasn't been "approved". And it's also in extreme tension with the idea of having browsers that end-users can modify (their individual instances of).
Hence a browser developer or OS developer or developer of whatever software is in question wouldn't be permitted (by the DRM system's inventor or administrator) to get decryption keys if they didn't promise to implement these restrictions.
Some of the people who invented the modern DRM business ecology called this "the intersection of technology, law, and commercial licensing" (the title of a 1996 article by Dean Marks and Bruce Turnbull). Here, the "technology" is DRM implementations -- including software obfuscation and other measures; the "law" is anticircumvention laws like the DMCA §1201 that make it risky for people to use the decryption keys in ways that industry dislikes; and "commercial licensing" is the permission from a DRM developer to interoperate with that DRM, including "compliance" rules (about the functionality of the technology product) and "robustness" rules (about tamper-resistance), that result in the licensee being issued decryption keys.
In my view (I worked on EFF's objection) this is a deliberate attack on software interoperability: the whole point is to allow someone to try to prevent interoperability with software that hasn't been "approved". And it's also in extreme tension with the idea of having browsers that end-users can modify (their individual instances of).
I see no way how an open source system can implement any effective DRM standard while staying open source.
If a proper open source system has a component that enforces DRM, and is functional when I download it, then it includes those keys; but gives me an unconditional right to use and modify it. And I am physically able to modify it, un-implementing those restrictions.
If part of the system cannot be modified by me, then the whole is not open source, and any open source system such as Firefox shouldn't include that part or standard.
If a proper open source system has a component that enforces DRM, and is functional when I download it, then it includes those keys; but gives me an unconditional right to use and modify it. And I am physically able to modify it, un-implementing those restrictions.
If part of the system cannot be modified by me, then the whole is not open source, and any open source system such as Firefox shouldn't include that part or standard.
I agree. In previous discussions about this, some people emphasized the idea of open source development, as opposed to giving an open source software to an end user. For example, you could run a binary through an obfuscator after compiling in a decryption key -- from source code that had been published and distributed under an open source license. If the license isn't a reciprocal/copyleft license, this is probably not a license violation, but it seems wrong to say that the user who receives the binary is being given open source software.
This issue reflects the way that people have had very different ideas about what the point or purpose of free and open source software is (in some ways, reflecting the split between people who preferred to say "free software" over "open source" and vice versa).
It's also a very concrete issue today in whether people call, say, the Chrome browser "open source". Most of their source code is downloadable, derived from the fully open-source Chromium project, but in Google's current practice, users never get the complete source code to the Chrome binaries that they run. If you're focused on the development process, it might almost make sense to call Chrome "open source" because almost all of its source code is distributed, licensed, and developed in an open source manner -- but if you're focused on what users can do with the software, it's obviously just a proprietary application (with a proprietary EULA, to boot).
This issue reflects the way that people have had very different ideas about what the point or purpose of free and open source software is (in some ways, reflecting the split between people who preferred to say "free software" over "open source" and vice versa).
It's also a very concrete issue today in whether people call, say, the Chrome browser "open source". Most of their source code is downloadable, derived from the fully open-source Chromium project, but in Google's current practice, users never get the complete source code to the Chrome binaries that they run. If you're focused on the development process, it might almost make sense to call Chrome "open source" because almost all of its source code is distributed, licensed, and developed in an open source manner -- but if you're focused on what users can do with the software, it's obviously just a proprietary application (with a proprietary EULA, to boot).
> For example, you could run a binary through an obfuscator after compiling in a decryption key -- from source code that had been published and distributed under an open source license.
Of course, if you do that you may as well just not release the source code at all, because there's no way for the user to tell that the binary does actually correspond to the source without also being able to extract the encryption key and break the DRM.
Of course, if you do that you may as well just not release the source code at all, because there's no way for the user to tell that the binary does actually correspond to the source without also being able to extract the encryption key and break the DRM.
I think that verifiability is an important security benefit from publishing source code and I hope to talk more about that soon.
Some people think that publishing source code is first and foremost a way to get other people to collaborate on its development, not to ensure any particular rights or knowledge or safety for people who end up using the software. For example, you could imagine a consortium of people who each make a super-proprietary locked-down thing and they publish and collaborate on the code of some libraries that their respective locked-down things need. They actively do want other locked-down thing makers to comment on how to make the code better and contribute patches, but they actively don't want customers to use that knowledge to make the thing less locked-down (or to be able to verify what it does or doesn't do).
This is a situation that we often encounter in the real world, and in fact some of the locked-down thing makers are even surprised when people say the contrast in their behavior with respect to these audiences is strange or hypocritical, because they didn't know or didn't remember that other people think software freedom is partly or mainly meant to benefit users.
Some people think that publishing source code is first and foremost a way to get other people to collaborate on its development, not to ensure any particular rights or knowledge or safety for people who end up using the software. For example, you could imagine a consortium of people who each make a super-proprietary locked-down thing and they publish and collaborate on the code of some libraries that their respective locked-down things need. They actively do want other locked-down thing makers to comment on how to make the code better and contribute patches, but they actively don't want customers to use that knowledge to make the thing less locked-down (or to be able to verify what it does or doesn't do).
This is a situation that we often encounter in the real world, and in fact some of the locked-down thing makers are even surprised when people say the contrast in their behavior with respect to these audiences is strange or hypocritical, because they didn't know or didn't remember that other people think software freedom is partly or mainly meant to benefit users.
I've certainly noticed some people do that, but in essence isn't that just a way to get other people to do their development work for them for free, without giving those developers any of the benefits that come from true open source software in exchange?
> If part of the system cannot be modified by me, then the whole is not open source
"Open Source" definition does not include any clauses that require hardware manufacturers to provide you encryption and/or signing keys, so you could run your code. GPLv3 and "Free Software" are what you're looking for.
"Open Source" definition does not include any clauses that require hardware manufacturers to provide you encryption and/or signing keys, so you could run your code. GPLv3 and "Free Software" are what you're looking for.
The Free Software Definition doesn't require free software to be copylefted or to include measures against TiVoization or against proprietary or restrictive downstream products. GPLv3 does this and the BSD license doesn't, and both are free software licenses.
As I said in another comment, people who usually say "free software" are more likely to think that preventing restrictive downstream products is an important goal than people who usually say "open source". But that doesn't mean it's part of the definition of what it means to be free software.
EDIT: I also think the comment the parent replied to was right to say "then the whole is not open source". BusyBox is both free and open source even though its license allows it to be included in the locked-down TiVo -- but the TiVo as a whole is not open source.
As I said in another comment, people who usually say "free software" are more likely to think that preventing restrictive downstream products is an important goal than people who usually say "open source". But that doesn't mean it's part of the definition of what it means to be free software.
EDIT: I also think the comment the parent replied to was right to say "then the whole is not open source". BusyBox is both free and open source even though its license allows it to be included in the locked-down TiVo -- but the TiVo as a whole is not open source.
> If part of the system cannot be modified by me, then the whole is not open source
So would you say that firefox is open source now? If they implement this as a plugin, what makes it technically different from using Flash?
So would you say that firefox is open source now? If they implement this as a plugin, what makes it technically different from using Flash?
Content keys do not have to be shipped with the browser. They are provisioned on a per-user and possibly even per-use basis for the specific content.
But if the content keys work with actual open source software, then that software can always be modified to decode the content and remove any restrictions that the publisher might wish to apply.
That's why they have to obfuscate things at the code level too.
That's why they have to obfuscate things at the code level too.
In past years in my career I worked in game development. I can say without hesitation that anything client side can be reverse engineered and hacked. Any limitation built into a browser can be circumvented, and it will happen in a matter of days from release.
Does it mean that Firefox could not both implement DRM and remain open source?
Excellent!
Excellent!
They want to propose an API which would allow proprietary closed source binary blobs to display videos. In other words: They are pushing "yet another Flash" into HTML5.
A "Flash" without the (in)security footprint of an entire runtime duplicating Web standards, I think you mean.
At least Flash was used widely enough that the vulnerabilities were found. EME means there are several competing vendors of proprietary DRM plugins that talk directly to video card drivers, all with unknowable security characteristics.
With the insecurity of being a closed source binary blob that has to duplicate a lot of the Web standard.
A better Flash? Yes, please, and thank you.
Not a better Flash. The same crap but this time embedded in what used to be an open web standard.
The DRM isn't actually implemented by the browser its more of a plugin architecture (Encrypted Media Extensions) which commercial closed source DRM plugin can fill.
If it's just going to end-up plug-ins, I don't understand why DRM is being treated specifically at all instead of tweaks to the existing general-purpose plug-in architecture. If you want DRM, deal with Microsoft Silverlight or Adobe Flash or roll your own.
The existing plugins are heavy and don't integrate well with other web technologies. In addition, the NPAPI interface is not standardized (I believe). Thus, the point is to narrow down the scope of plugins from everything that Flash and Silverlight do to just a piece of code focused on DRM. Everything else that people use Flash and Silverlight can be replaced by standards and directly implemented in the browser. However, DRM, by its nature depends on closed-source compiled binaries, which means that it has to remain in a plug-in.
You can, of course folks have, but then you can't use the video/audio tags. (or you need a pretty significant js shim)
But this still effectively limits the rendering of content to blessed implementations. Why introduce a standard that isn't open when there are already other options.
I imagine the client-side stuff won't really matter. I think in the end there will be a DRM API that will not trust the client. "Does this user have a valid key or username/pass to access this content" won't be answered on the client-side, but on the server-side.
Probably with a client-side file (or binary?) that gets delivered to the browser from the server and accessed locally in a sandboxed environment. This handles keys, auth, etc natively with the browser. This might be seamless to the end user.
Probably easily crackable like, say SteamWorks, but good enough to keep low-hanging fruit safe and copyright holders happy as we begin to retire flash entirely. Joe User won't be able to 'right-click and saveas' but he'll be able to view HTML5 video.
I think TBL is stuck between a rock and a hard place, just like Gabe Newell was with Steam. Users hate DRM, but he can't sell games without it. Some crowd-happy DRM scheme that's unobtrusive might be the only winning move here.
Probably with a client-side file (or binary?) that gets delivered to the browser from the server and accessed locally in a sandboxed environment. This handles keys, auth, etc natively with the browser. This might be seamless to the end user.
Probably easily crackable like, say SteamWorks, but good enough to keep low-hanging fruit safe and copyright holders happy as we begin to retire flash entirely. Joe User won't be able to 'right-click and saveas' but he'll be able to view HTML5 video.
I think TBL is stuck between a rock and a hard place, just like Gabe Newell was with Steam. Users hate DRM, but he can't sell games without it. Some crowd-happy DRM scheme that's unobtrusive might be the only winning move here.
DRM is not in the browser. The browser just acts as a gateway to allow the website to talk to a DRM component in the OS (or potentially in hardware).
Take for example a DRM protected video. That video is being send to the framebuffer of my video card. If I use an open source OS and open source Browser, what on earth is stopping me from capturing that video output?
The website targets specific DRM schemes that they approve. Since your open source OS doesn't have any DRM schemes you're SOL.
[deleted]
Nothing, which is why this whole proposal even exists.
With this standardized, we will continue to be legally and/or practically blocked from native consumption of protected content on general purpose GNU/Linux distributions.
With this standardized, we will continue to be legally and/or practically blocked from native consumption of protected content on general purpose GNU/Linux distributions.
Absolutely nothing. DRM is pointless. Everything ever published in video form is already available to pirate.
DRM just makes lawyers happy. I say, let them eat cake.
DRM just makes lawyers happy. I say, let them eat cake.
Open source OSes will probably not have CDMs available, except when prepackaged into a proprietary widget (Android, ChromeOS, B2G is Mozilla decides to play ball)
If an open source system can run the CDM and is packaged in a proprietary widget; then I am allowed to take that open source system out of the widget, modify it to behave exactly as if it is still in the widget (so that it can still run the CDM) and redistribute the system to everyone.
You might even not be able to use it elsewhere. For example, the current ChromeOS CDM apparently only runs on approved hardware that's locked down from the hardware up to prevent you running any unauthorized code - if you enable developer mode it disables playback, possibly even at the hardware level.
It's very hazy. If the userland (running atop of the Linux kernel) is closed source then there's few things you can do. Also, you can't just rip out binaries and redistribute them at will, EULAs usually forbid it.
As I specifically mentioned, "If an open source system can run the CDM.." - the CDMs run inside a browser, and for an open source browser such as Firefox or Chromium I definitely can modify it and redistribute the modifications; and if Firefox and Chromium can't run the CDMs, well, then they won't get used much since that's the majority of users.
CDMs will most likely communicate with closed-source hardware that implements the decryption (e.g. Blu-ray's AACS requires video card support for AES and HDCP).
So at some point in the transaction you have to click "Allow" and install this component, similar to how a java applet works now?
No, the DRM is built into the operating system or the browser. Microsoft, Apple, and Google all have their own DRM schemes. There is no installation.
This is incorrect. The DRM may be shipped with the browser or whatnot, but it's fundamentally a plugin architecture. The Widevine plugin, for example, is the CDM plugin used by both Google Play and Netflix to provide DRM-protected video on Android and ChromeOS.
Most likely there was a lot of lobbying for this to happen. People with big money but no clue about how the internet really works.
I'm quite surprised to see Tim Berners-Lee approve this in fact, I wonder what made him say yes to this.
I'm quite surprised to see Tim Berners-Lee approve this in fact, I wonder what made him say yes to this.
It's actually mostly Netflix wanting this. They don't want to rely on SilverLight forever.
At least Sliverlight works in Linux with netflix-desktop.
That stopped working for me several months ago... IIRC Netflix needed an updated version of Silverlight. Have they patched it?
Yeah, still works for me. It was only gone for a few days IIRC.
We should watch closely what his career does next.
DRM people are not interested in how it'll work, in fact DRM often contributes to user of whatever it is implemented in suffering. They just want permission to insert their cluster fuck to keep getting rich.
I'm curious how with the whole open source community how this will be at all enforceable... there's nothing stopping me releasing a browser that says "To hell with DRM, I'm just not going to enforce any of it"... and because it's open source and out there in the wild, there's not a whole hell of a lot anyone can do to shut it down...
The idea is that the browser is going to ask some lower-level DRM system to decode everything, only displaying it to the user. In theory this is supposed to go all the way down to the TPM, so that you cannot subvert it with a debugger or rootkit. In practice, there will probably be bugs that lead to video streams being captured anyway, and the whole thing will only serve to further divide people and make free software harder to use.
See my comment upthread about encrypted media and how licensing is used to control the availability of decryption keys. In existing DRM people are not required to implement it, but they can't achieve interoperability without the decryption keys.
The browser doesn't enforce the DRM, a binary blob in the OS does.
The thing is most Firefox users don't even know what an extension is. If my parents' Firefox ships with support for DRMs, they won't care about it. Once it becomes widespread, there's simply no way to start "un-supporting it".
I don't see it taking too long for someone to make an open source DRM-free browser that just ignores the HTML 5 DRM functionality.
The problem is MPAA & friends will already see this as an "entitlement" and say those other browsers are "facilitating piracy", while the major ones from Google, Microsoft and Apple aren't. Something like that will sound very good to government and authorities.
I really think allowing this to happen in the first place is just like opening the Pandora box. You give these guys an inch, they never stop demanding for more censorship.
I really think allowing this to happen in the first place is just like opening the Pandora box. You give these guys an inch, they never stop demanding for more censorship.
Read the spec. This wouldn't work, specifically because EME is a set of interfaces to proprietary blobs which do the actual content decryption and optional rendering.
Building a browser that ignores EME would be functionally equivalent to building a browser that can't use Flash.
Building a browser that ignores EME would be functionally equivalent to building a browser that can't use Flash.
A browser can save the data after it's been rendered.
A DRM plugin can't tell the difference between an "approved" browser that doesn't do that versus a modified browser that just pretends to be an approved browser.
The CDM may render directly to the underlying platform; it doesn't have to pass decrypted content back to the browser for rendering.
Seriously though, everyone should go just read the spec. Or at the least, take a looksee at this: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...
Seriously though, everyone should go just read the spec. Or at the least, take a looksee at this: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...
Yes, and the underlying platform (OS) can cooperate with the browser to allow easy one-click saving of the rendered data after it's been rendered. Unless the whole stack from hardware through to the DRM plugin is locked down.
Certainly, but that's always true of every non-trusted computing platform. You can do that with Flash or Silverlight or any other video DRM system today. I rather suspect it's a very big part of the reason that CDMs don't get published for Linux, because it would be trivial to modify the system to just jack the content on its way out to the display.
> Unless the whole stack from hardware through to the DRM plugin is locked down.
Which is why you have TPM and the various Microsoft/Apple/Google DRM schemes: Hollywood wants to lock down the full stack, and they're getting there one piece at the time.
For TPM, their enabler was Microsoft and their desire to lock down the boot process to enforce licensing. For this spec, it's Google and Netflix because they think it's the only way their media services will survive in the long run.
Insert here smart quote about expert frog-boiling.
Which is why you have TPM and the various Microsoft/Apple/Google DRM schemes: Hollywood wants to lock down the full stack, and they're getting there one piece at the time.
For TPM, their enabler was Microsoft and their desire to lock down the boot process to enforce licensing. For this spec, it's Google and Netflix because they think it's the only way their media services will survive in the long run.
Insert here smart quote about expert frog-boiling.
Would that be possible? Then can this still be called DRM?
Edit: How can it be DRM if the algorithms/formats/protocols are open? Or aren't they open?
Edit: How can it be DRM if the algorithms/formats/protocols are open? Or aren't they open?
>How can it be DRM if the algorithms/formats/protocols are open? Or aren't they open?
They're not. IIRC, the only open parts are the hooks the actual DRM plugin (but we're not calling it a plugin!) will utilize.
They're not. IIRC, the only open parts are the hooks the actual DRM plugin (but we're not calling it a plugin!) will utilize.
No, not unless the browser found a way to give false positives when EME asks for DRM validation.
Isn't this good news for video distributors who haven't converted over to HTML5 (native video support) because of lack of support for DRM?
And terrible news for all users.
Distributors may not be happy once they discover that Safari supports FairPlay DRM, Chrome supports Widevine DRM, IE supports WMDRM, Samsung phones support SamDRM, HTC phones couldn't afford to license any DRM, etc.
Yeah. Also, there's no requirement for the different DRM schemes to support the same codecs or containers or encryption schemes, so potentially they'll have to re-encode all their content for each scheme. It's actually less standardized than pay TV encryption believe it or not!
Edit: The interface between the DRM servers and your backend code isn't standardized either, so content providers still have to do a bunch of DRM-scheme-specific development work. Basically, they standardized just enough to allow sites with DRM to claim they're 100% HTML5, it barely improves interoperability at all.
Edit: The interface between the DRM servers and your backend code isn't standardized either, so content providers still have to do a bunch of DRM-scheme-specific development work. Basically, they standardized just enough to allow sites with DRM to claim they're 100% HTML5, it barely improves interoperability at all.
Sure, but is it good news for the users?
Yeah, sure. Some sort of somewhat effective anti digital copying mechanism is a great way to enable video rentals on general purpose computers (especially given the pervasive copyright regime of modern video content).
There are issues to come when consumers only have access to encumbered media, but at the moment, they pretty clearly benefit from the access.
There are issues to come when consumers only have access to encumbered media, but at the moment, they pretty clearly benefit from the access.
> they pretty clearly benefit from the access
Speaking of access, make sure you have the SonyⓇ RootKit™ Updater installed.
Speaking of access, make sure you have the SonyⓇ RootKit™ Updater installed.
Them: You can watch this (shitty) movie in exchange for your freedom.
You: Sure!
Me: No way!
You: Sure!
Me: No way!
We can and should let them die.
Funny how some of the largest sites on the internet can base their entire business model on stolen pictorial content - completely with stripping off the identifying information of the original artists - and nobody at the W3C bats an eye.
But the moment the MPAA muscles their way into the debate, suddenly we're all about DRM.
If you want DRM, you use a plug-in or a separate application. There's no reason that an app like Netflix or whatever can't use pure-HTML for everything but the video-stream and use a plug-in based object for the stream.
Keep HTML free.
But the moment the MPAA muscles their way into the debate, suddenly we're all about DRM.
If you want DRM, you use a plug-in or a separate application. There's no reason that an app like Netflix or whatever can't use pure-HTML for everything but the video-stream and use a plug-in based object for the stream.
Keep HTML free.
>If you want DRM, you use a plug-in or a separate application. There's no reason that an app like Netflix or whatever can't use pure-HTML for everything but the video-stream and use a plug-in based object for the stream.
That's exactly what this standard would allow.
That's exactly what this standard would allow.
That's how it is now without a standard. We don't need a standard for stupid anti-UX features like built in DRM
We already have a standard for stupid anti-UX features built in. It's called NPAPI.
And I seriously doubt with EME that it will change this way. I work for a media company, Flash is used not just for its DRM but because our ad vendors don't care about HTML5 support. It's why we can't move forward with HTML5 outside of mobile.
You do realise that 'mobile' now accounts for > 50% of pageviews?
Which means that your ad vendors actually about HTML5 support. They just do not know it yet.
Which means that your ad vendors actually about HTML5 support. They just do not know it yet.
Except the plugin is the responsibility of the browser, not them. This is effectively a way to shift the maintenance burden on browser and OS vendors.
What happened to the concept of the User Agent being a representative of the user, not the content provider?
It is now a user-double-agent.
I think that many people are drastically underestimating the effect this may have on the open web. The response "oh, well we'll just build a browser that will avoid the DRM" isn't going to work quite as well as one might hope. It's not such a stretch of the imagination that content providers will detect such browsers and refuse to supply any content at all. This would be similar to what many sites do now for users of IE6-8, where a message is displayed prompting them to upgrade. Except in this case a message would be displayed telling you to download an effectively locked-down browser. Ugh.
Impossible, browser detection is easily spoofed. Some browsers come built with the ability to spoof other browsers since its valuable for developers who need to test how their sites appear in other browsers.
But you could easily do feature detection, much like Modernizr, simply changing the user agent is not going to fool anyone.
This will have precisely zero effect on the open web (whatever that is).
Amazing number of commenters fail to realise that:
a) nothing that makes web open is removed. Sorry to disappoint you, but HTML will keep working as it did.
b) technology not being w3c standard does not stop it from being implemented in browsers as history shows.
In the end what browser vendors do matters the most, not what w3c thinks. Just look at the history of WHATWG.
In the end what browser vendors do matters the most, not what w3c thinks. Just look at the history of WHATWG.
W3C - Ruining HTML since... often...
Can someone PLEASE explain to me the following: If my computer is playing the video and playing the audio. How on God's green earth can they stop me from capturing that? ... It's playing right in front of me... I can hear and see it. It's not hidden or secret. Look.
If you ask me, the only reason DRM has worked up to now, is because code/file formats/protocols were secret. People didn't have access to the source. But now they do, in the open source browsers.
But PLEASE enlighten me. I wants to know.
If you ask me, the only reason DRM has worked up to now, is because code/file formats/protocols were secret. People didn't have access to the source. But now they do, in the open source browsers.
But PLEASE enlighten me. I wants to know.
The analog hole will always exist. But please understand: it's ANALOG hole.
Ten years from now (I know it will happen by then; probably sooner), if I grab my Apple smartphone and press "record video" and point it at a piece of DRM-protected content playing on my computer, it will not record. Will not record. There will just be a black spot in your recording. The recording audio will cut out as well, if an audio watermark is detected.
It's an ANALOG hole. Film cameras will always be able to record your screen. Cassette recorders will work fine. But your digital equipment? No.
http://en.wikipedia.org/wiki/EURion_constellation
Ten years from now (I know it will happen by then; probably sooner), if I grab my Apple smartphone and press "record video" and point it at a piece of DRM-protected content playing on my computer, it will not record. Will not record. There will just be a black spot in your recording. The recording audio will cut out as well, if an audio watermark is detected.
It's an ANALOG hole. Film cameras will always be able to record your screen. Cassette recorders will work fine. But your digital equipment? No.
http://en.wikipedia.org/wiki/EURion_constellation
What makes you think DRM has worked up to now? Which content is unavailable for pirating because of DRM?
As far as I can tell DRM has only ever punished, and still only punishes, legitimate users.
As far as I can tell DRM has only ever punished, and still only punishes, legitimate users.
It only punishes users if it is badly implemented. I doubt many users of Steam or Netflix feel punished.
I can't watch my Netflix account on Linux without using some Wine distribution because of the Silverlight DRM. I'd say I feel pretty punished on that end.
Yeah well your use case doesn't fit the "many" qualifier that was mentioned in the comment you replied to.
Ever heard of http://en.wikipedia.org/wiki/Cinavia ? Sure you can record in the analog hole, but the playback of copies will becut or limited.
Imagine a browser refuse playback video or audio clip based on Cinavia DRM plugin, and also a website requiring such plugin -- via the DRM API -- to provide any content.
Imagine a browser refuse playback video or audio clip based on Cinavia DRM plugin, and also a website requiring such plugin -- via the DRM API -- to provide any content.
From that link: "When media with the watermark is played back on a system with Cinavia detection, its firmware will detect the watermark and check that the device on which it is being played is authorized for that watermark."
So I just make a media player that ignores the watermark, based on the open source code I found in the browser... DRM hacked.
So I just make a media player that ignores the watermark, based on the open source code I found in the browser... DRM hacked.
HDCP does a 'pretty good' job of achieving that. There's a protected path all the way to the display, that can't be accessed by other software.
Pretty good job, until the key was leaked. [0][1]
[0] http://www.engadget.com/2010/09/14/hdcp-master-key-supposedl... [1] Key: http://pastebin.com/kCA3dFDv
[0] http://www.engadget.com/2010/09/14/hdcp-master-key-supposedl... [1] Key: http://pastebin.com/kCA3dFDv
If it's encrypted all the way to the hardware, then it get's a bit more believable. But that really can't be done on the web, can it? "You no have DRM chip? No tubez for you!"
"You no have DRM chip? No tubez for you!"
That is actually their plan.
That is actually their plan.
1. Your cellphone can't watch YouTube without hardware decoding.
2. An issue closer to home can be seen http://wiki.xbmc.org/?title=Raspberry_Pi/FAQ#Video_and_audio... .
3. Companies target audiences and not platforms. For example, Netflix on Linux.
2. An issue closer to home can be seen http://wiki.xbmc.org/?title=Raspberry_Pi/FAQ#Video_and_audio... .
3. Companies target audiences and not platforms. For example, Netflix on Linux.
Come to think of it, in theory the Raspberry Pi could support a DRM scheme that's entirely "open source" in the same way that their graphics drivers are already. Basically, the GPU is actually a fairly powerful processor running a binary blob that receives messages from the ARM CPU - if it did all the decryption the CPU-side code could be entirely open.
It doesn't matter unless the website acknowledges your DRM scheme.
The parts of the browsers that support the DRM would probably have to be delivered as binary blobs in order to be standards compliant.
The W3C hasn't been a good "guardian" of HTML for a very long time. This is pretty much why they're not even the only guardian around - there's also WHATWG.
For example, 12 years ago W3C attempting to push "RAND" patent licensing into HTML:
http://lists.w3.org/Archives/Public/www-patentpolicy-comment...
This was 100% against the concept of a free, open web, and it took a huge effort to stop it happening. It's crazy that it even got that far.
So it's no surprise that they're pushing industry interests again today. I lost all confidence in that group safeguarding HTML a long time ago, and it looks like the they haven't changed.
For example, 12 years ago W3C attempting to push "RAND" patent licensing into HTML:
http://lists.w3.org/Archives/Public/www-patentpolicy-comment...
This was 100% against the concept of a free, open web, and it took a huge effort to stop it happening. It's crazy that it even got that far.
So it's no surprise that they're pushing industry interests again today. I lost all confidence in that group safeguarding HTML a long time ago, and it looks like the they haven't changed.
Let them. I'll build my own browser and it won't respect this shit in the slightest.
We'll make a new W3C. One that can't be bought so easily.
We'll make a new W3C. One that can't be bought so easily.
I'll go build my own W3C, with blackjack and hookers!
New coined term: DRM-HTML.
'By contrast, W3C has now put its weight behind a restrictive future: let's call it "DRM-HTML".'
'By contrast, W3C has now put its weight behind a restrictive future: let's call it "DRM-HTML".'
I don't understand why everyone is up in arms about this. Some content cannot go anywhere without DRM. That's not going to change. Do you think the Universal is just 6 months away from streaming the latest blockbuster with VP8 in a video tag?
Right now we have Flash and Silverlight everywhere and it's a PITA. How open are those two? This adds the option of moving this stuff out of plugins. If you want to live in some everything-is-free utopia, just never visit netflix.com.
Right now we have Flash and Silverlight everywhere and it's a PITA. How open are those two? This adds the option of moving this stuff out of plugins. If you want to live in some everything-is-free utopia, just never visit netflix.com.
"Some content cannot go anywhere without DRM"
Why should we care? The web is not supposed to restrict users. If Universal does not like it, they can go somewhere else -- they have the cable TV system with all its restrictions and anti-freedom design.
Why should we care? The web is not supposed to restrict users. If Universal does not like it, they can go somewhere else -- they have the cable TV system with all its restrictions and anti-freedom design.
No, the web is all about restricting users. It's baked into several HTTP error codes (403 and 401 off the top of my head). SSL is also rather popular.
I assume you mean that the browser shouldn't restrict users? Like, if I stream a movie from Netflix, I should be able to also save it locally so I can take parts of it to use in my fair use arts project? Sorry. Never going to happen. Forcing this use case that _people want_ off into plugins isn't going to make anything more "free".
That's like selling a Roku box that can only play Ted and Youtube videos and saying that it's better because it's totally free, and open, and doesn't restrict its users. Well, sure, that is the best kind of correct. But only because you yanked everything that wasn't free. You didn't actually add any value over the standard Roku box that plays Netflix and Amazon.
I assume you mean that the browser shouldn't restrict users? Like, if I stream a movie from Netflix, I should be able to also save it locally so I can take parts of it to use in my fair use arts project? Sorry. Never going to happen. Forcing this use case that _people want_ off into plugins isn't going to make anything more "free".
That's like selling a Roku box that can only play Ted and Youtube videos and saying that it's better because it's totally free, and open, and doesn't restrict its users. Well, sure, that is the best kind of correct. But only because you yanked everything that wasn't free. You didn't actually add any value over the standard Roku box that plays Netflix and Amazon.
> No, the web is all about restricting users. It's baked into several HTTP error codes (403 and 401 off the top of my head). SSL is also rather popular.
This is obtuse. The HTTP and HTML specs provide standards for interoperation. Some modes of operation are forbidden for some users, and the specification provides a way for that to be communicated. It sounds like you're taking a whole-system approach to freedom, which is certainly valid (see the AGPL for a "free" response). But it's orthogonal to the issue at hand, which is interoperability. Any client can still implement the specification.
That said, I'm completely at a loss as to how you believe SSL "restricts users".
> I assume you mean that the browser shouldn't restrict users? Like, if I stream a movie from Netflix, I should be able to also save it locally so I can take parts of it to use in my fair use arts project?
The browser should implement an interoperable standard. That standard should be accessible to everyone. Any browser vendor should be able to, once they have properly implemented the specification, stream a movie from Netflix (this is the very thing that EME makes impossible).
> Sorry. Never going to happen. Forcing this use case that _people want_ off into plugins isn't going to make anything more "free".
This does not have to be reality, no matter what vendors say. There's a reason digital restriction management was forced out of the music space: it's ineffective, it's consumer-hostile, and it hinders innovation. Many of us are mad precisely because the vendors played hardball in their negotiations, and the W3C wimped out. Vendors need the web more than the web needs the vendors, but the W3C didn't take an equally hard line back and we're left with a decision that screws everyone but media companies.
> That's like selling a Roku box that can only play Ted and Youtube videos and saying that it's better because it's totally free, and open, and doesn't restrict its users. Well, sure, that is the best kind of correct. But only because you yanked everything that wasn't free. You didn't actually add any value over the standard Roku box that plays Netflix and Amazon.
The problem is, this decision hinders innovation. It is now much harder for a Roku competitor to exist, because before they can get off the ground they have to comply with byzantine demands of old media companies. "totally free, and open, and doesn't restrict its users" is the future of communication and computing (at least technically, politically is a different story). This decision is mired in the past.
Let's circle back to this:
> Forcing this use case that _people want_ off into plugins isn't going to make anything more "free".
This is exactly what EME does. The digital restriction management "extensions" are plugins. They are binary blobs, tied to specific hardware implementations. This regresses the web back to the "best viewed on Windows in IE 2.3" days, where interoperation is dead and cross-platform compatibility is a hippy dream.
And that's why people are mad at the W3C for no longer representing what the web is supposed to be.
This is obtuse. The HTTP and HTML specs provide standards for interoperation. Some modes of operation are forbidden for some users, and the specification provides a way for that to be communicated. It sounds like you're taking a whole-system approach to freedom, which is certainly valid (see the AGPL for a "free" response). But it's orthogonal to the issue at hand, which is interoperability. Any client can still implement the specification.
That said, I'm completely at a loss as to how you believe SSL "restricts users".
> I assume you mean that the browser shouldn't restrict users? Like, if I stream a movie from Netflix, I should be able to also save it locally so I can take parts of it to use in my fair use arts project?
The browser should implement an interoperable standard. That standard should be accessible to everyone. Any browser vendor should be able to, once they have properly implemented the specification, stream a movie from Netflix (this is the very thing that EME makes impossible).
> Sorry. Never going to happen. Forcing this use case that _people want_ off into plugins isn't going to make anything more "free".
This does not have to be reality, no matter what vendors say. There's a reason digital restriction management was forced out of the music space: it's ineffective, it's consumer-hostile, and it hinders innovation. Many of us are mad precisely because the vendors played hardball in their negotiations, and the W3C wimped out. Vendors need the web more than the web needs the vendors, but the W3C didn't take an equally hard line back and we're left with a decision that screws everyone but media companies.
> That's like selling a Roku box that can only play Ted and Youtube videos and saying that it's better because it's totally free, and open, and doesn't restrict its users. Well, sure, that is the best kind of correct. But only because you yanked everything that wasn't free. You didn't actually add any value over the standard Roku box that plays Netflix and Amazon.
The problem is, this decision hinders innovation. It is now much harder for a Roku competitor to exist, because before they can get off the ground they have to comply with byzantine demands of old media companies. "totally free, and open, and doesn't restrict its users" is the future of communication and computing (at least technically, politically is a different story). This decision is mired in the past.
Let's circle back to this:
> Forcing this use case that _people want_ off into plugins isn't going to make anything more "free".
This is exactly what EME does. The digital restriction management "extensions" are plugins. They are binary blobs, tied to specific hardware implementations. This regresses the web back to the "best viewed on Windows in IE 2.3" days, where interoperation is dead and cross-platform compatibility is a hippy dream.
And that's why people are mad at the W3C for no longer representing what the web is supposed to be.
There's a difference between a closed plugin and a closed browser. Let the DRM content stay in their plugins in their paywalled sites, while the web in general remains open and benefits from the creativity and innovation that flows from that openness.
EME CDMs are closed plugins for open browsers. It's literally the status quo except with a smaller breakage surface due to a more specialized purpose.
I don't think anyone said that the DRM code will be closed source.
You don't complain when you can't decrypt PGP, even though PGP implementations are open source. This is the same thing.
You don't complain when you can't decrypt PGP, even though PGP implementations are open source. This is the same thing.
If it's open source, I can just swoop in, inject some code and make a copy of the decrypted data stream for 'archival purposes'. Won't take a day for a PoC.
I can still do this with closed source DRM blobs, but it will take much longer. And there will probably be pointless anti-debugger tricks, system wide hooks that break countless other software, kernel drivers that BSoD your system..
That is precisely why this proposal is such a terrible idea. It writes into a standard that it is okay to produce software that is actively hostile to its user, while having absolutely no security gain whatsoever (because the concept is fundamentally broken: if the data is being decrypted on my system, I will get it).
I can still do this with closed source DRM blobs, but it will take much longer. And there will probably be pointless anti-debugger tricks, system wide hooks that break countless other software, kernel drivers that BSoD your system..
That is precisely why this proposal is such a terrible idea. It writes into a standard that it is okay to produce software that is actively hostile to its user, while having absolutely no security gain whatsoever (because the concept is fundamentally broken: if the data is being decrypted on my system, I will get it).
But you can do that with any DRM - the unencrypted stream will always be in memory at some point.
Yes, that is my point. That is why any DRM plugin will be closed-source and probably filled with landmines and obfuscation: its the only sliver of a chance they have to make getting the unencrypted data hard.
Not if the decryption is handled by hardware that refuses to give an unencrypted video stream back to the CPU.
An extra hardware chip is a closed system. You control all the input that comes in. It is just a more annoying form of obfuscation at that point.
Nothing in the W3C's DRM spec provides for anything better than a closed hardware chip.
> Do you think the Universal is just 6 months away from streaming the latest blockbuster with VP8 in a video tag?
They should be. Because I'm going to continue getting my DRM free video from the Pirate Bay until they do. They might have a chance at revenue if they'd just get over themselves. Dinosaurs.
They should be. Because I'm going to continue getting my DRM free video from the Pirate Bay until they do. They might have a chance at revenue if they'd just get over themselves. Dinosaurs.
I don't believe that. Music industry said the same thing, no one supported DRM and now music is DRM free. It was only a matter time before Netflix/Amazon Prime/Hulu went DRM free.
The movie/television industry wasn't crippled piracy, and most likely will never be. These guys print money and it seems they will print money for time to come, and Netflix/Prime/Hulu generates pennies compared to the TV/Movie industries billions.
Simply put, the movie/television is much more diverse than the music industry and won't see its lunch eaten.
The biggest hurdle in getting DRM content in the contract games that are being played with all the major providers right now (remember the TWC/CBS dispute). In these contracts are clauses for all content to be DRM'd. Even if everyone understood that DRM is bad UX, no one gives a shit about fighting those clauses when TWC is removing CBS over contract disputes. It just currently doesn't make sense to risk hundreds of millions of dollars for a moral issue that 99% of users simply don't care about.
Simply put, the movie/television is much more diverse than the music industry and won't see its lunch eaten.
The biggest hurdle in getting DRM content in the contract games that are being played with all the major providers right now (remember the TWC/CBS dispute). In these contracts are clauses for all content to be DRM'd. Even if everyone understood that DRM is bad UX, no one gives a shit about fighting those clauses when TWC is removing CBS over contract disputes. It just currently doesn't make sense to risk hundreds of millions of dollars for a moral issue that 99% of users simply don't care about.
HTML5 DRM video makes sense, and it might force content producers to modernise their distribution methods. This would be nice for consumers, many of who are forced to pirate simply because content isn't available in their country or don't have cable subscriptions.
It won't stop piracy, even if it means holding a camera up to the screen to capture the data.
However locking down the browser itself is simply ridiculous. it reminds me of snopes.com disabling right click.
It won't stop piracy, even if it means holding a camera up to the screen to capture the data.
However locking down the browser itself is simply ridiculous. it reminds me of snopes.com disabling right click.
I don't get it. If they want a plugin, they should build a plugin. Why would any sane person (1) create redundant infrastructure for DRM plugins (2) get all the same security problems and more just because some hipsters at Netflix get a hardon when they can't use HTML5 video tags and have to embed a plugin? We certainly shouldn't offload Netflixs woes with content producers onto every browser maker in existence.
What a bizarre discussion. Should have been laughed out from the first proposal.
What a bizarre discussion. Should have been laughed out from the first proposal.
Should have been laughed out from the first proposal.
And yet it wasn't. Can certainly make you wonder about the health of the W3C as a whole.
And yet it wasn't. Can certainly make you wonder about the health of the W3C as a whole.
This could have really huge and ugly long term consequences for search engines.
OTOH, with a little help from the OS to guard the path through to the HDMI spigot (which is probably already in place) I may be able to see all my Amazon Instant Prime content via my browser in HD. :-)
There's an upside to the downside. Some things will be closed by this and some things will be opened. The impact on the non-pirating media consumer will mostly be positive.
The impact on the cable companies and other parasitic channels through which content must now pass will, to our benefit, be negative since content producers will need them for nothing to maximize the returns on their investment. Many hands that dip into the revenue stream between the producer and the consumer to merely protect the stream can be easily eliminated. The same is true of all the various music channels from the labels through iTunes to Spotify.
I like this because artists and producers will be able to negotiate with us directly which will lower the cost and the motivation to pirate. I'm all for artists and producers making money on their work, but not all the various middle men this can remove from the picture.
I'm very concerned, however, about the possibly negative effect on things other than media content like the general flow of news and information. Any item of information can now easily carry a price for internet access independent of the channels through which it moves.
Verdict: mixed bag.
OTOH, with a little help from the OS to guard the path through to the HDMI spigot (which is probably already in place) I may be able to see all my Amazon Instant Prime content via my browser in HD. :-)
There's an upside to the downside. Some things will be closed by this and some things will be opened. The impact on the non-pirating media consumer will mostly be positive.
The impact on the cable companies and other parasitic channels through which content must now pass will, to our benefit, be negative since content producers will need them for nothing to maximize the returns on their investment. Many hands that dip into the revenue stream between the producer and the consumer to merely protect the stream can be easily eliminated. The same is true of all the various music channels from the labels through iTunes to Spotify.
I like this because artists and producers will be able to negotiate with us directly which will lower the cost and the motivation to pirate. I'm all for artists and producers making money on their work, but not all the various middle men this can remove from the picture.
I'm very concerned, however, about the possibly negative effect on things other than media content like the general flow of news and information. Any item of information can now easily carry a price for internet access independent of the channels through which it moves.
Verdict: mixed bag.
Look! The prison's so big you can't even see the walls! How nice.
Wow. This isn't just adapting DRM, they're literally saying that they can change the HTML5 standard at a whim and we'll only have access to the CC0 licensed spec.
Time to fork HTML5.
Time to fork HTML5.
As someone that learned a lot using view source. this is just upsetting
isnt this the equivalent of greying out the "view source" menu item or removing the developer menu item?
You can still get the entire page, it comes in over the wire. If they do this, I would assume we can just capture the raw data, and new apps that decode that raw data and give the same tools as the browser developer tools offer.
If not, hopefully there are browsers who refuse to implement, and hopefully it takes less time than it took Adobe to learn their lesson.
You can still get the entire page, it comes in over the wire. If they do this, I would assume we can just capture the raw data, and new apps that decode that raw data and give the same tools as the browser developer tools offer.
If not, hopefully there are browsers who refuse to implement, and hopefully it takes less time than it took Adobe to learn their lesson.
Let them spend their money and time there.
That's money and time they will not spend doing something useful for their interests.
That's money and time they will not spend doing something useful for their interests.
One should think twice before supporting Netflix in any way after this.
I don't mean this as a defense of EME, but I think this is more rabble-rousing and fear mongering than anything else. What the EFF and this article are saying is that EME opens the door for this kind of stuff to make its way to the spec. EME on its own does absolutely none of this.
EME is not DRM. It's a standard spec for plugins that provide DRM. Essentially it means that someone like Netflix could still use the HTML5 video element for playback while interacting with a browser plugin just to handle the DRM aspect of things.
EME is not DRM. It's a standard spec for plugins that provide DRM. Essentially it means that someone like Netflix could still use the HTML5 video element for playback while interacting with a browser plugin just to handle the DRM aspect of things.
For those who don't know what "EME" means:
http://en.wikipedia.org/wiki/Encrypted_Media_Extensions
It's DRM legitimised as a concept in a supposedly open standard. it's a slippery slope.
with video DRM having a foot inside, who dares to venture a guess at what the next victim will be? DRMed js? DRMed html?
with video DRM having a foot inside, who dares to venture a guess at what the next victim will be? DRMed js? DRMed html?
How is the EME slope any more slippy than it is right now with Flash or Silverlight? Both allow sites to serve code in an obscured and non-open way. And yet no one serves a Flash-only or Silverlight-only site.
I totally understand what you're saying (and agree), my point was that a lot of people posting here seem to think that all of these scary "nexts" are what was approved by the W3C.
Yes, it would be a travesty if those things actually happened. Yes, I think DRM is ultimately pointless and silly. Keep in mind, though, that this is just a transition from one method of DRM playback to another, not a leap to DRM for things that didn't previously have it.
Yes, it would be a travesty if those things actually happened. Yes, I think DRM is ultimately pointless and silly. Keep in mind, though, that this is just a transition from one method of DRM playback to another, not a leap to DRM for things that didn't previously have it.
Ok, it sounds to me like this is way, way, over blown. First, the DRM is NOT going to be built into the browser it self. It's basically a new name for a plug in system, nothing more. So, to everyone who thinks they can roll their own browser and avoid the DRM, no you will not be able to.
It's not bad or good for consumers, at best, it's about the same. It's very simple, studios will not allow you to rent their movies without DRM. Netflix will not be able to function without DRM. Neither can steam. It's not up to them, it's up to the content providers, not companies like Netflix.
Is it stupid? Yes. My high school teacher, with no technical knowledge what so ever had a way to brake almost any video DRM. He would play the video on his TV, and record the image with his HD Cam. Stupid? Yes. Effective? Also yes.
The point is, as long as its a plugin type of architecture, not part of the browser binary, what's the big deal. How is it different from Flash or Silverlight?
Oh, and to everyone that proclaims that DRM is bad. Many of you are developers for startups. Is your startup all open source? Why not? Isn't compiling code or running it only on your servers just another type of DRM? Ask your self, would you have a job if your company was forced to share all the code you write? All of it, even the stuff that you write from scratch and only run on your servers.
I think many people hate DRM because of how bad it's implemented, not because of the fact that its there in the first place. Well implemented DRM should be completely transparent to the end user who paid for the content. Steam and Netflix do a pretty good job of it.
It's not bad or good for consumers, at best, it's about the same. It's very simple, studios will not allow you to rent their movies without DRM. Netflix will not be able to function without DRM. Neither can steam. It's not up to them, it's up to the content providers, not companies like Netflix.
Is it stupid? Yes. My high school teacher, with no technical knowledge what so ever had a way to brake almost any video DRM. He would play the video on his TV, and record the image with his HD Cam. Stupid? Yes. Effective? Also yes.
The point is, as long as its a plugin type of architecture, not part of the browser binary, what's the big deal. How is it different from Flash or Silverlight?
Oh, and to everyone that proclaims that DRM is bad. Many of you are developers for startups. Is your startup all open source? Why not? Isn't compiling code or running it only on your servers just another type of DRM? Ask your self, would you have a job if your company was forced to share all the code you write? All of it, even the stuff that you write from scratch and only run on your servers.
I think many people hate DRM because of how bad it's implemented, not because of the fact that its there in the first place. Well implemented DRM should be completely transparent to the end user who paid for the content. Steam and Netflix do a pretty good job of it.
No, the DRM is going to be built into the browser itself. Browser vendors could in theory implement it as a plugin but they don't seem to be planning to and the W3C doesn't specify any kind of plugin mechanism. IE11 at least integrates it into the browser executable.
That's just not true, for exactly the example provided above.
It'd make no sense to let people roll their own browsers that circumvent DRM.
It'd make no sense to let people roll their own browsers that circumvent DRM.
Among other reasons, people dislike DRM because it involves someone else effectively making your computer do something which you can't control, or even observe. Schemes vary, but the stronger ones can't even be run under a VM. This is a level beyond merely being "closed source".
Consider that of the four major browser vendors (Mozilla, Apple, Microsoft, Google) three are also major DRM vendors (Google's Widevine, Microsoft's PlayReady, and Apple's FairPlay).
What exactly do you think will prevent them from building their already-existing in-house DRM (three different systems, note!) into their own browsers?
What exactly do you think will prevent them from building their already-existing in-house DRM (three different systems, note!) into their own browsers?
I guess I don't understand what the problem with that would be.
Would that somehow lead to Hacker News or Facebook encrypting their site's source code with that DRM? I sort of doubt it. They could do that now with Flash if they wanted to, but no one thinks Flash websites are a good idea.
Would that somehow lead to Hacker News or Facebook encrypting their site's source code with that DRM? I sort of doubt it. They could do that now with Flash if they wanted to, but no one thinks Flash websites are a good idea.
The main possible problems are twofold:
1) EME as currently proposed is video only, but will the W3C try to do the same for images? For text? There are certainly constituencies who would live simple turnkey DRM for those on the web. And they don't do it in Flash _precisely_ because Flash websites are not a good idea.
2) If the above happens, there is no incentive for Netflix, say, to try come up with a setup that works with open-source browsers and still satisfies the rightsholders for the content they distribute. If people complain they'll just be told the spec says browsers need to implement DRM, and if that means no open-source browsers tough luck.
1) EME as currently proposed is video only, but will the W3C try to do the same for images? For text? There are certainly constituencies who would live simple turnkey DRM for those on the web. And they don't do it in Flash _precisely_ because Flash websites are not a good idea.
2) If the above happens, there is no incentive for Netflix, say, to try come up with a setup that works with open-source browsers and still satisfies the rightsholders for the content they distribute. If people complain they'll just be told the spec says browsers need to implement DRM, and if that means no open-source browsers tough luck.
The problem is that free and open-source browsers will not be able to show more and more content on the web. That is already true but it was not encouraged or endorsed by W3C so far. That has changed.
Actually Netflix and Stream could both operate without DRM. If content providers don't want to provide their content to open systems, that is their concern, not that of the middle men. Adding a DRM standard just placates to corporate wishes to control content. This has the chilling effect to prevent fair use, or worse it can be used to lock up content that should otherwise be open and free.
It is the concern of the middle men, though. If content providers aren't willing to provide content, then the middle men will have no reason to exist. You can't have Netflix without any movies or shows on it.
If content owners want to leave money on the table, that is their prerogative. Assuming there was no Netflix, et al., it would just drive more gray market piracy. That isn't something content providers want. As it happens, DRM or not, piracy happens. I don't see this standard changing that.
You are also assuming that there would be no available content without DRM, but if traditional content providers couldn't sell their product to consumers anymore, I think it is more likely that non-traditional content providers, those that agree to distribute content that isn't encumbered with DRM restrictions, would become more successful. It is a shift from having content force feed to us by corporations, to a system where independent creators have greater exposure.
I don't need their content and I'm less likely to consume it if they insist on locking it up. I do believe in paying for the content I receive, and I would continue to do so if the stream didn't have DRM.
You assume they're leaving money on the table by rejecting DRM, i.e. that there is more money in avoiding it than in supporting it to some degree. I'm not so sure.
You're also assuming that consumers give a crap about DRM. They generally don't, if they get the content they want is available at a good price (i.e. mostly free w/ advertising if it's low-engagement, or at cost if it's high-engagement), and good a user experience (i.e. I can consume it on my chosen device platform, in my chosen setting, without having to stand on my head).
DRM became a detractor for consumers in the music industry because they went to war with their own customers. Music has a multi-decade long culture of sharing and trading. Then the industry retroactively tries to state that all of this is illegal. You couldn't easily copy purchased files across devices due to their paranoia. Even iPods could only be sync'd to one library at a time (part of their settlement with Apple in the early 00's). They even tried to claim CD ripping was illegal (that didn't fly). This is why Apple advocated to get DRM removed altogether from iTunes and eventually won - it was just a crappy experience all around.
The TV/movie industry thus far has avoided the fate of the music industry through a mix of low-barrier access to content within the US (Hulu, iTunes, Netflix TV station websites, etc.) and DRM to erect some exclusionary barriers to the content. DRM in this sector is more like a horse race that doesn't quell piracy but keeps it at least somewhat inconvenient. They also didn't go to war with their customers, and were more selective of how they chose to use legal avenues.
I don't foresee death in their future, just winner-take-all competition if they don't keep up with what their customers want.
Ultimately, the nature of most information goods being non-excludable is changing the game in ALL industries that make and sell information from one of distributing the information to a hybrid market-gift-economy. You can have previews, clips, etc. to experience my stuff, perhaps even stream it for free for a limited time, but to get the best overall experience, they'll gate the access... i.e. you can't have my stuff unless you line up and pay a ticket. This is even how RedHat works (you need to pay to get into RHN, or their cloud... which are the best experiences of maintaining a RedHat server, even though the software itself is free).
Or they focus on something that is excludable: a consumer's time and attention... i.e. free TV streaming, or Facebook surfing time. And make money on the content with advertising.
You're also assuming that consumers give a crap about DRM. They generally don't, if they get the content they want is available at a good price (i.e. mostly free w/ advertising if it's low-engagement, or at cost if it's high-engagement), and good a user experience (i.e. I can consume it on my chosen device platform, in my chosen setting, without having to stand on my head).
DRM became a detractor for consumers in the music industry because they went to war with their own customers. Music has a multi-decade long culture of sharing and trading. Then the industry retroactively tries to state that all of this is illegal. You couldn't easily copy purchased files across devices due to their paranoia. Even iPods could only be sync'd to one library at a time (part of their settlement with Apple in the early 00's). They even tried to claim CD ripping was illegal (that didn't fly). This is why Apple advocated to get DRM removed altogether from iTunes and eventually won - it was just a crappy experience all around.
The TV/movie industry thus far has avoided the fate of the music industry through a mix of low-barrier access to content within the US (Hulu, iTunes, Netflix TV station websites, etc.) and DRM to erect some exclusionary barriers to the content. DRM in this sector is more like a horse race that doesn't quell piracy but keeps it at least somewhat inconvenient. They also didn't go to war with their customers, and were more selective of how they chose to use legal avenues.
I don't foresee death in their future, just winner-take-all competition if they don't keep up with what their customers want.
Ultimately, the nature of most information goods being non-excludable is changing the game in ALL industries that make and sell information from one of distributing the information to a hybrid market-gift-economy. You can have previews, clips, etc. to experience my stuff, perhaps even stream it for free for a limited time, but to get the best overall experience, they'll gate the access... i.e. you can't have my stuff unless you line up and pay a ticket. This is even how RedHat works (you need to pay to get into RHN, or their cloud... which are the best experiences of maintaining a RedHat server, even though the software itself is free).
Or they focus on something that is excludable: a consumer's time and attention... i.e. free TV streaming, or Facebook surfing time. And make money on the content with advertising.
I'm just curious about what all of you opposed to this would offer as an alternative to companies like Netflix or other streaming sites. No DRM? That's simply not going to fly.
If you really want to undermine DRM in an honest and ethical manner, you should leave those DRM'd properties to their owners and support non-DRM media.
How many of you listen to itunes media and are raging about this...
If you really want to undermine DRM in an honest and ethical manner, you should leave those DRM'd properties to their owners and support non-DRM media.
How many of you listen to itunes media and are raging about this...
DRM-free is the way to go, and has been the way for music on iTunes since March 2009 (http://www.macworld.com/article/1137946/itunestore.html and http://en.wikipedia.org/wiki/ITunes_Store#Movement_against_D...)
I seem to remember reports that iTunes sales increased quite a bit as they removed the DRM, indicating that removing DRM does indeed make the most business sense, not just the most moral sense or whatever. The best source I've been able to come up with quickly is this: http://www.theinquirer.net/inquirer/news/1022890/emi-drm-fre...
I seem to remember reports that iTunes sales increased quite a bit as they removed the DRM, indicating that removing DRM does indeed make the most business sense, not just the most moral sense or whatever. The best source I've been able to come up with quickly is this: http://www.theinquirer.net/inquirer/news/1022890/emi-drm-fre...
They only went DRM free in response to pressure from Amazon who began selling DRM free MP3s. I am not a fan of DRM at all but I believe that if a "content owner" wants to encumber their own creation with it, they should have that right and freedom.
No, they should not have that "right and freedom", because being a "content owner" is not some natural god given right.
Copyright is something that is granted to someone by society for a purpose. Encumbering a creation with DRM defeats that purpose.
Sure, anyone has the "right and freedom" to add DRM to anything. But in that case anyone should also have the right and freedom to break the DRM and redistribute the content.
Copyright is something that is granted to someone by society for a purpose. Encumbering a creation with DRM defeats that purpose.
Sure, anyone has the "right and freedom" to add DRM to anything. But in that case anyone should also have the right and freedom to break the DRM and redistribute the content.
DRM does not defeat the purpose of copyright. Both copyright and DRM are just means to erect partial-excludability for an information good to encourage a market economy around the exchange of that good. One is a legal barrier, the other is technological.
We do this with physical goods through laws around theft, and police to enforce those laws. Information goods however, are non-rival, thus aren't subject to theft, just copying. So, generally, society doesn't enforce "excludability breaking" with information as stringently as we would with a rival good. Sometimes it does go completely, and inexcusably overboard: see Aaron Swartz.
We haven't had a lot of time to think through what we really want as a society here. Information economics concepts like transparency, excludability and rivalry are still very new to people. The nature of information goods is not a market economy, it's a gift exchange economy. Yet we've built 300 years of progress on a market economy. So we're evolved to a hybrid of market-gift economies in the information sector, but no one really knows where it will end up in the long run.
Amusingly, the most free country on breaking and redistributing digital content is China. I remember the old saw that Adobe Photoshop used to cost $0 in China, but $300 for the manuals. Almost every other country frowns upon such behaviour and tries in some way to make it illegal.
We do this with physical goods through laws around theft, and police to enforce those laws. Information goods however, are non-rival, thus aren't subject to theft, just copying. So, generally, society doesn't enforce "excludability breaking" with information as stringently as we would with a rival good. Sometimes it does go completely, and inexcusably overboard: see Aaron Swartz.
We haven't had a lot of time to think through what we really want as a society here. Information economics concepts like transparency, excludability and rivalry are still very new to people. The nature of information goods is not a market economy, it's a gift exchange economy. Yet we've built 300 years of progress on a market economy. So we're evolved to a hybrid of market-gift economies in the information sector, but no one really knows where it will end up in the long run.
Amusingly, the most free country on breaking and redistributing digital content is China. I remember the old saw that Adobe Photoshop used to cost $0 in China, but $300 for the manuals. Almost every other country frowns upon such behaviour and tries in some way to make it illegal.
Well no, being a content owner isn't a natural god given right... please list the natural god given rights that humanity has decided a consensus on?
W3C is on HAL's side...
http://www.youtube.com/watch?v=yYqkU1y0AYc
I wish a browser vendor would step up and say no to this. As in "we won't support a DRM future in the browser". Firefox, Chrome?
Mozilla (makers of Firefox) campaigned strongly against this in the W3C. But they haven't promised never to support DRM in their browser, and they are not likely to as it would marginalize their browser. What is more likely to happen is that they won't be able to pay the licensing fees for the DRM software and therefore won't include it, and then their browser will become marginalized. ("Firefox: the browser that can't view YouTube or Netflix.")
For a preview of how this approach would turn out for Mozilla, look at the H.264/WebM debacle. Mozilla refused to implement H.264 for a long time, but after Google reneged on its promise to drop support, Mozilla finally caved to keep its userbase.
I doubt they'd even try again, seeing as they've already seen this movie and know how it will end.
I doubt they'd even try again, seeing as they've already seen this movie and know how it will end.
The main reason Mozilla didn't add H264 was because of royalties, which they couldn't pay. I don't know how much ideology was also behind the decision. Their solution was to use the OS to decode H.264, bypassing the need to implement the codec, and pay royalties. So I'm not sure how much of it was "caving", and how much was finally implementing the solution.
Chrome might be difficult because Google has already implemented it in ChromeOS and is a coauthor of the EME specification.
the hell? What were they thinking when they decided this would be a good idea ??
While DRM is generally annoying, if the technology exists, it might be interesting to use it for ERM -- being able to prevent copying of documents which are editable in-browser would be potentially a better way to work than the VDI or dedicated hardware used now.
If you have to distribute the key to the client (dvd player, browser, etc) isnt it just a matter of time before the key is discovered and the content can decrypted at will?
How does this standard prevent that?
How does this standard prevent that?
"So long, and thanks for all the GIFs."
Just have a label in Firefox that says:
CLOSED SOURCE
icon
on top so that we know we are about to visit a site where we can't see the source of the javascript that is being run on our computer.
The idea is to develop a culture for people to prefer OPEN SOURCED site vs a CLOSED SOURCED one.
CLOSED SOURCE
icon
on top so that we know we are about to visit a site where we can't see the source of the javascript that is being run on our computer.
The idea is to develop a culture for people to prefer OPEN SOURCED site vs a CLOSED SOURCED one.
If this means companies like Netflix use HTML5 rather than Silverlight to stream films it will ultimately make the world a better place.
makes no difference , you'll still need to install some 3rd party plugin or buy authorized hardware in order to run the media.
Doesnt change anything for the client.
The providers will swap an object tag for a video one ,that's what it is all about.
It's basically a Flash or Silverlight for video and sound only.
Doesnt change anything for the client.
The providers will swap an object tag for a video one ,that's what it is all about.
It's basically a Flash or Silverlight for video and sound only.
All of this is just the symptom of not providing a goddamn good service. If these media companies would provide a good service DRM wouldn't make sense even in their minds. But no, they're stuck in the dark ages, with their heads up their asses.
I mean, look at what Steam has done to the video game industry; or iOS/Android app stores. When it's easier to buy the copy pretty much nobody is going to bother stealing it.
I mean, look at what Steam has done to the video game industry; or iOS/Android app stores. When it's easier to buy the copy pretty much nobody is going to bother stealing it.
Only that steal is such a strong word for that..
i dont think digital goods can be stealed, cause steal is to subtract somebody of something.. if i get your watch without your consent, you will be without it.. thats steal..
With a digital good you can copy over and over, and never subtract the original author of its own copy..
The industry itself tried to implant this wrong concept on the peoples mind so they would think its the same.. only its not..
i think the best approach from them would be to accept that new reality in the digital age.. and try to collect money from good customers, the buyers, and try to collect from the people that have made copies of the work by stating they have obligations, and expenses to do that work, and ask for the users the support..
i think thats pretty much what microsoft did with windows.. trying to fight with a possible customer treating him as the enemy, will only hurt them in the long term..
They need to think with a new perspective, not with the same ideas as the XX century.. it will only cause them more damage than good.. people will see them as the enemy, much like we are seeing now
With a digital good you can copy over and over, and never subtract the original author of its own copy..
The industry itself tried to implant this wrong concept on the peoples mind so they would think its the same.. only its not..
i think the best approach from them would be to accept that new reality in the digital age.. and try to collect money from good customers, the buyers, and try to collect from the people that have made copies of the work by stating they have obligations, and expenses to do that work, and ask for the users the support..
i think thats pretty much what microsoft did with windows.. trying to fight with a possible customer treating him as the enemy, will only hurt them in the long term..
They need to think with a new perspective, not with the same ideas as the XX century.. it will only cause them more damage than good.. people will see them as the enemy, much like we are seeing now
How does allowing a proprietary tech into the browser do anything more than harm the system?. Didn't this just open up the browser to possible secure channels for botnets? Do DRM concerns trump security?.
"A Web where you cannot cut and paste text; where your browser can't "Save As..." an image; where the "allowed" uses of saved files are monitored beyond the browser; where JavaScript is sealed away in opaque tombs; and maybe even where we can no longer effectively "View Source" on some sites, is a very different Web from the one we have today. It's a Web where user agents—browsers—must navigate a nest of enforced duties every time they visit a page. It's a place where the next Tim Berners-Lee or Mozilla, if they were building a new browser from scratch, couldn't just look up the details of all the "Web" technologies. They'd have to negotiate and sign compliance agreements with a raft of DRM providers just to be fully standards-compliant and interoperable."
They suggest the W3C may be digging itself into another hole like the one that led to the formation of WHATWG. A good read.
[1] https://www.eff.org/deeplinks/2013/10/lowering-your-standard...