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.

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.

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.

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.

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.

All they can take away is the sources that actually bring them money.

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.

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.

Or are you also advocating for changes to trademark law?

This TED talk explains it quite well : http://www.ted.com/talks/johanna_blakley_lessons_from_fashio...

http://www.gnu.org/philosophy/not-ipr.html

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.

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.

At least they were.

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.

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.

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.

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.

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.

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.

That's an awesome term for something I never quite had a word for.

http://www.joelonsoftware.com/articles/fog0000000018.html

Browsers have plug-in architectures. DRM systems are inherently proprietary. Leave them to implement proprietary plug-ins.

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.

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."

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.

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.

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 ..."

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.

This is not about making a copyright-friendly web. This is about attacking the openness of the web.

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.

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 )

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.

Pretty much like Firefox and IE6 activeX sites, or iPhones / android and flash. DRM simply restricts playback devices.

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.)

http://www.gnu.org/philosophy/right-to-read.html

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.

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.

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 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.

EME is not strictly DRM in your browser: it's a standardised interface to allow your browser to talk to DRM modules.

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.

> 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.

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.

Try exercising your fair-use rights on those DRM'd bits for example.

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.

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.

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.

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.

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.

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).

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.

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.

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!

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.

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.

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.

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.

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.

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.

Yes. Why? (I don't have a Chromebook, and don't use Chrome OS, for this very reason.)

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'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.

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.

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.

But they're just voices in a large game: Microsoft and Google are co-editors with Netflix of the new DRM spec.