Hacker News Reader

Comment by trunnell | Hacker News Reader

Wow, Cory's article is totally over the top... as are some of the comments in this thread.

Let's start with the facts. Here's the spec. It's called Encrypted Media Extensions (EME).

https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...

The EME spec isn't that long, and the introduction has a nice diagram. Go check it out.

The W3C spec does not put "DRM in browsers." It allows browsers to use "decryption modules" that already exist elsewhere, like in the OS platform. There are APIs to determine what sorts of "decryption modules" are available and to use them to decrypt media.

If we're going to transition to a plug-in free web then we need HTML5 video to support these extensions. Sure, it'd be nice if the big media companies stopped insisting on using encryption to distribute their videos. But that's not likely to happen anytime soon. Premium video on the web requires either plug-ins or EME. I think most of us would pick premium web video + EME, rather than premium web video + plug-ins, or (perish the thought) no premium video on the web at all.

BTW, open source browsers can easily implement this spec since it doesn't require the browser to implement a "decryption module" themselves. Also, there is a mode called "clear key" that can be used if the underlying platform doesn't have any "decryption module" available.

Disclosure: I work at Netflix on streaming video in browsers.

View on HN

> If we're going to transition to a plug-in free web then we need HTML5 video to support these extensions.

The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow should not be encumbered because of contractual obligations of today. I fail to see the technical reason why encryption is necessary for Netflix. HTML5 is a technical spec. It does not need to be riddled with extensions to fulfill business needs.

I can't view a stream if I'm not a paying member logged in to the website or XBox/Roku/AppleTV device. Once I am able to view the stream, encryption or not, I can record it through a number of hardware/software mechanisms if I am technically savvy. If I'm not technically savvy, I can't record it regardless of encryption. If I can somehow access the stream without logging in, say the files are stored on CDN and available to everyone over HTTP(S), then you should work on preventing that.

W3C/HTML5 are designing specs for the long haul. I am pretty sure I will be writing web apps in a decade too, like I did a decade ago. iTunes no longer has DRM'ed audio. Who knows, in a decade, Hollywood will give up DRM too, with pressure from Netflix, Apple, Amazon, and Google. But if engineers at these very companies that should be pushing for open-web, insist on burdening the spec to cope with DRM, I doubt we'll ever see that future.

> The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow should not be encumbered because of contractual obligations of today.

And when we live in your Star Trek-style technoutopia, then we won't have to worry about business concerns in specs. Specs have had business concerns in them since... ever.

I agree with you that business needs give rise to specs. That's pretty much how most of the specs are born. MS wanted to make Outlook Web Access behave more like the desktop version and came up with XMLHttpRequest - which went into the spec and made the web of today suck significantly less. That wasn't my point.

I'm talking about adding in mechanisms to support restrictions because of current legal situation. If you add in extensions that help DRM video, why not start adding in support for extensions that can prevent SSN or medical history from being displayed on the screen unless the local machine sends a valid fingerprint signature to the server? Of course that sounds ridiculous. Something like that doesn't belong in the spec. I fail to see the difference between that and EME.

> XMLHttpRequest... made the web of today suck significantly less.

I would argue the exact opposite.

I am curious. What are your arguments?

Likely referring to web-apps that require Javascript support and have no fail over code.

This is more a problem with the developer of said site and not an issue with XMLhttprequest as you can build apps that are progressively enhanced for it and don't fail completely when JS/XMLHTTP is disabled.

If you've upvoted or downvoted anyone here on HN, you have benefited from XMLHttpRequest.

HN doesn't use XMLHttpRequest. View source to see that.

    Specs have had business concerns in them since... ever.

Good specs haven't.

Good specs do. You might write a spec that describes the functional requirements of a claims processing system, because your current system is 20 years old and can't cheaply be modified to comply with legislative changes.

An obvious "business concern" is that any replacement system will accommodate future legislative changes. This has nothing to do with the functional (user) requirements (form design and submission process), and yet might dramatically change how you design and write such a system.

DRM, or rather the encryption scheme that makes it DRM, is much the same in that a design that supports it could similarly support related but more benign capabilities, such as compression or translation.

That too will influence an implementation, and makes such a non-functional requirement as important as a functional requirement.

The media companies know we'll always eventually be able to bypass any DRM they place on their media. But they still feel obligated to use it, partly for legal reasons. If they make their content available through a completely unrestricted video stream and then try to sue someone who infringes on their copyright, the defense's first question will be "well if you didn't want someone copying your content why didn't you place any of the available restrictions on it?" I don't think this would be a valid argument but it's not a risk many media companies would probably want to take.

> If they make their content available through a completely unrestricted video stream

That was my point. Why is it completely unrestricted? How hard is it to check a cookie and 401 if I'm not logged in? And if someone can fake an HTTPS cookie, they can do a lot more damage than download a video.

> Wow, Cory's article is totally over the top...

What makes you think it's over the top? We have a public-interest organization pushing DRM, a technology that is decidedly against the public interest.

I'm surprised that this is upvoted to the top of the thread, when you haven't done anything except say "this is over the top" and given us a link that explains what DRM is---as if the DRM's detractors don't already know what it is or how it works.

> Sure, it'd be nice if the big media companies stopped insisting on using encryption to distribute their videos. But that's not likely to happen anytime soon.

That's only true because technologists continue to lie to media companies, telling them that DRM is feasible and not harmful to their interests (even though, in addition to being against the public interest, it tends to cause monopolization of their distribution chains---just ask the music industry happened with iTunes).

Look, these media companies are looking to us for advice; We're doing both them an ourselves a disservice by continuing to sell them DRM snake oil.

> you haven't done anything except say "this is over the top" and given us a link that explains what DRM is

The link is the Encrypted Media Extensions (EME) spec. EME is not DRM. It allows access to a decryption system outside of the browser.

That is different than what Cory and others are claiming.

It is precisely DRM. The entire point of it is to protect media streams from copying, and the BBC has specifically demanded that it be robust enough DRM enough to trigger anti-circumvention laws and allow them to have anyone who does manage to copy the decrypted streams arrested and jailed.

EME merely allows access to a DRM system. I know this distinction sounds overly precise, but the fact that EME does not mandate a DRM system makes a big difference if you want to implement this spec in a browser.

Were EME to actually specify the DRM then this spec would never have been jointly proposed by Google, Microsoft, and Netflix.

It is an effective but incorrect bit of rhetoric when Cory equates EME to DRM in the article.

It's all just an empty demagogy in lawyers style. EME is about DRM, but the language was made generic to avoid mentioning DRM. So to make things fair and clear - EME is intended to serve the cause of those who push DRM on the Web. And it's enough of a reason to oppose EME.

Look at ABC as an example. You can watch their video content via a Flash plugin, or via a native app for IOS. They do not let you watch their content via a browser without Flash. This is fairly common for media companies.

Now think of the implications of not having EME. It creates a situation that pushes users away from the open web and onto native apps and proprietary plugins. EME is needed so that users don't move away from browsers to native apps. Users will go where the content is, no matter how vigorously you shout your ideology.

Aren't those plugins used already by those who rely on DRM? So what do you prefer, to make DRM (a dying unethical trend) part of the HTML5, or to retain its area of influence to plugins? Users know that plugins should be better avoided. They represent external, not very trustworthy entities for the web experience. This goes along with DRM which should be avoided for similar reasons. Pushing DRM into the browsers would only obscure this matter. EME is therefore not serving any good purpose for the open web and should be opposed. It's not like users who use DRM will suddenly get pushed into plugins or external applications. They already use them! And those who don't use and don't want to use DRM don't need that junk in the browser.

And for publishers it should be a lesson to stop using all that DRM for good if they want to be part of the open web.

Users will get pushed into native apps. Normal users don't know or care what DRM is. They click on a link to some video they want to watch from ABC, and if they are on a mobile device they are told they have to download the free app to watch it. They do, cause they want to want to watch, and we just helped push users off the open web!

> Users will get pushed into native apps.

I don't see why it is a problem, if we are talking about DRM. DRM free distributors will use HTML, embracing the open web. Obsessed with DRM ones will use shady plugins and malware-like non browser applications. I'm fine with that - it also clearly marks this distinction for the user. Pushing off the Web here relates to DRM and distributors who insist on using it, not to the users who you claim have no idea what's going on.

Maybe, but I think users will go where the content is that they want to watch. I don't think a normal user will associate it with DRM.

Users won't stop using the Web. If some will want to use DRMed content, they'll use those external applications and / or plugins. And users will figure out the difference - between those publishers who respect them and use DRM free channels (including the Web), and those who don't repsect them and insist on stupid DRM and malware prone tools to distribute their content. So this "pushing" IMHO serves only the good purpose to isolate DRM from the normal technologies.

So the bottom line - W3C being the designers of the future Web concepts should focus on pushing distributors off DRM for the sake of open Web by refusing to be associated with it in any fashion, instead of obliging this insulting preemptive policing by pushing DRM onto the users as a "Web standard".

It's unclear if the world will move towards native apps or stay on the open web. Preventing anyone from having a DRM solution for the web makes it more likely the world will move to native apps. That would be a bad outcome in my opinion.

I also fail to understand your ideology. Anyone who creates content should have the ability to decide how they wish to sell and distribute that content. I think DRM is futile, but I don't think it is bad as you seem to believe.

There are applications which are used outside the browsers. And DRM is a perfect example - DRM has no place in the open Web. I don't see a problem with pushing bad technologies off the Web (or altogether off for that matter). Good riddance!

Idea here is rather straightforward. Publishers indeed have a choice to treat their users with respect, or to insult them with DRM. But we aren't talking about them making this choice - it's up to them. We are talking about W3C putting an unethical technology in a Web standard, to oblige some publishers who made that unethical choice. It's unacceptable! It's not different from saying that since malware creators want an ability to affect their users, W3C should standardize malware methods for the Web.

your ideology makes no sense to me.

What exactly? You have hard time understanding that DRM is unethical, or that open Web doesn't need it?

If I'm a musician, and I want to sell my music in a way that prevents the buyer from redistributing it, then I don't think that is unethical. I think the musician has the right to make that choice. You have a right not to buy it in that form.

Can a musician come to your house and start monitoring you to prevent redistribution? No, it's invasive and unethical to do it. It's along the lines of invasive surveillance in a totalitarian police state for the sake of "security". Treating your paying customers in such way is a gross disrespect. DRM does exactly that - it's preemptive policing which violates privacy and treats users as potential criminals by default. It's insulting and unethical to do so.

I'm not even saying that it's pointless, since it doesn't prevent piracy. DRM punishes and insults paying customers who care to buy the content, and does nothing to stop illegal redistribution and doesn't affect those who don't care to buy and pirate the stuff. So what is the point in using it? To upset paying customers by limiting usability of the content and by increasing security and malware risks in shady DRM programs?

Distributors should start treating users with respect if they want any respect back. And it always pays off. In general I get the feeling that actual creators (musicians, authors and etc.) don't care about all this DRM idiocy. Those who push it are publishers/distributors, who can't comprehend a simple thing - DRM has no useful application at all, all it does - it degrades the user experience and punishes paying customers.

I'm sorry, DRM is not like a musician coming to your house and monitoring you. That is where you lose me and probably most people. I also disagree with the idea that protecting content you create is unethical. If I own a store, and put a lock on the door, it is not unethical because I am assuming that someone might try to break in and take stuff. That is roughly what you are saying. Or you know how most pharmacies and grocery stores keep some things behind a locked display? I do not find that to be unethical, yet by your logic we should.

I'm a customer, and I don't find DRM insulting to me. I see it as content creators attempting to find a way to continue getting paid for content they create in this new world. I think it is pointless, but that is very different from what you are saying.

I see absolutely no harm in adding the ability to use DRM in html5 video. It has absolutely no affect on the rest of the open web. There is still the ability to put non-DRMed content on the web. If you truly believed that customers would reject DRM, and you seem to think so, then you shouldn't have a problem with giving people the choice and letting consumers vote with their feet.

> I'm sorry, DRM is not like a musician coming to your house and monitoring you. That is where you lose me and probably most people.

Oh really? Should I remind you of this? https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...

>I also disagree with the idea that protecting content you create is unethical. If I own a store, and put a lock on the door, it is not unethical because I am assuming that someone might try to break in and take stuff.

Your analogy is wrong. People buying content is analogous to going to the store, buying something and bringing it home. Protecting the store is all fine with me - it's analogous to creating authentication, allowing only registered users to buy and so on. DRM goes much further than that. If you want to use the store analogy, it would mean that after buying a product, the store sends their police bot with you, which comes to your house and watches what you do, preventing you from potential illegal activity. I find it completely unethical and unacceptable practice. Another analogy would be placing a police camera right in your house, for the sake of preventing situations when you decide to do something illegal. Do you think it's acceptable?

DRM is running on your computer, in your house on your device in your private network. It's a closed black box which you suddenly are supposed to trust? Why so? One shouldn't trust it, especially given the history of abusing these things. Trust always depends on mutuality. DRM means they don't trust you by default assuming you are going to use the content illegally. Why after that you suddenly are supposed to trust them? They should be treated in the same fashion and not trusted by default!

We disagree on the core principle here. You don't consider DRM unethical, so you don't see a problem to put it in the HTML standard. I consider the whole approach unethical and therefore putting it in the standard as unacceptable.

However I brought several arguments why it's pointless even according to your view. One of them - it's a dying trend which is impractical altogether (i.e. it achieves no useful purpose and on the contrary only degrades usability and ignores the issues of fair use and accessibility). Therefore making it a standard is wrong, since it means promoting dying pointless trends on the Web.

That's a giant non sequitur. Sony put a root kit in some software, therefore DRM is unethical.

My original point stands.

> Sony put a root kit in some software, therefore DRM is unethical.

It's not because of Sony's case DRM is unethical. Just the opposite - because DRM is unethical, cases like Sony's are to be expected from it. I.e. Sony's case just demonstrates how easy it is to abuse preemptive policing, and that most users won't even notice it right away.

> My original point stands.

It stands not on the principles of the open Web though. I already explained above that DRM stands on the concepts of Orwellian police state and big brother approach, and that your analogy with protecting the store was incorrect. You didn't answer on the essence of the question so far.

Ok, it wasn't a non sequitur, it's an egregious circular argument. DRM is unethical because Sony put a root it on people's systems, and Sony put a root kit on people's systems because DRM is unethical.

I'm done here, have a nice day.

So far you didn't argue again with the fact that DRM is intrusive, violates privacy and is analogous to police bot in your house, rather than to fence around the store. Dwell on it more, and it'll be pretty clear why DRM should be strongly opposed. Have a nice day too.

For a change, here is my favorite story about pitfalls of intrusive preemptive policing:

http://www.gutenberg.org/files/29579/29579-h/29579-h.htm

>Look, these media companies are looking to us for advice; We're doing both them an ourselves a disservice by continuing to sell them DRM snake oil.

Seems to be working out pretty well for Hulu/Netflix. Or is releasing your $100 million budget film DRM-Free onto the internet now profitable??

Netflix requires a subscription to stream. DRM is irrelevant.

Care to elucidate that point?

So if netflix streamed their content with no-DRM (which none of the content companies they license from would allow, but we'll skip that fact) you assume no one would just get a subscription, copy their entire catalouge, and freely distribute it? Doesn't sound like a very sustainable business model to me...

The point is, that it is possible for someone who is technically savvy and who has a subscription to copy the streams right now. The reason they can't download the entire catalogue is probably because netflix/hulu have(or at least I hope they do) a system in place which prevents a single subscriber from accessing streams at a speed above what would be reasonably necessary for watching things one movie at a time. Which means that downloading the entire catalogue would take as long as it would take to watch everything which is probably prohibitively too much time.

However, if, say, there's a particular movie that is available on netflix/hulu which you want to distribute freely for whatever reason and you are technically savvy, no DRM(short of netflix/hulu controlling the actual hardware you're watching from) will prevent you from doing so.

Therefore, DRM offers no additional protection beyond what a regular login cookie-based system with rate limiting would offer.

DRM didn't stop House of Cards from appearing on PB:

http://thepiratebay.se/search/house%20of%20cards/0/99/0

I don't see Netflix going out of business because of this.

Yea, but my point is different than a cracked version leaking into bittorrent. That doesn't have a drastically large footprint.

If they streamed videos with no-DRM, everyone with a subscription would easily grab a copy of whatever they want. And all it would take is copying a file and sharing it with friends/family to have it spread. This might not seem like a huge difference, but honestly I think it would be. It would lower the barriers of sharing to the point that everyone could do it. Only those who hold onto a moral belief in not committing copyright infringement wouldn't participate. I think the past has shown that these people are in the vast minority.

How would they? Even ripping DRM-free YouTube videos is beyond most people. I don't see YouTube piracy as a big world problem.

What DRM-free Youtube videos? Youtube uses DRM-enabled flash player and locks down the ability of people to copy videos.

Besides Youtube is a free service, that everyone basically assumes will continuously be there. You're bringing up non-related factors.

YouTube DL works from the command-line. YouTube videos are not DRM-encumbered. They are just harder to get because they can no longer be requested by a simple HTTP call.

http://rg3.github.com/youtube-dl/

I don't believe that someone would cancel Netflix because they happened to have ripped all of the things they are interested in. The value of Netflix is accessing an enormous library, vastly bigger than you could store (changing all the time!) and watching an item that you feel like watching at this time. A Netflix subscriber can't exactly predict every single item they'll be interested in until the end of time, rip them, then cancel.

Even if there were a few people that did this, they would make up an incredibly tiny proportion of paying users, and they'd likely be akin to the digital hoarders that have TB of movies downloaded.

>I don't see YouTube piracy as a big world problem.

That's because YouTube content can be trivially shared with other people.

Stop the sharing and pretty sure you would start to see piracy.

It's easy enough to copy a stream with DRM. Point your camcorder at your laptop stream, press record on your camcorder, press play on your laptop.

It takes ~2 hours to play the film, you can't make any noise in the room during that time, and the resulting picture and sound quality will be terrible unless you've got very expensive recording equipment. Content producers would love to get to the point where that's the only way to 'copy' films.

You're right about the time it takes to copy. Whenever I've encoded video it's always been a time-consuming process so I wouldn't see this as a major obstacle.

As for picture and sound quality being terrible, simply not true. Recording from a projected image is one way to do telecine, and it works fine if you can set it up properly. [1] A half-decent telecine is very different from surreptitiously recording a film in a cinema.

The stream will be re-compressed but this isn't such an issue as many people think. Back when TV was recorded on analog tape in the 90s, you were allowed 8 generations of copying and it would still be considered acceptable for broadcast (for news).

[1] "The quality of a good telecine is generally comparable to a DVD without any post-processing." http://en.wikipedia.org/wiki/Telecine_(copying)

I could copy their entire catalog now, if I wanted to. It would only be very slightly harder because of the DRM.

Yea, you could. But, you aren't going to first of all. And secondly you are a drop in the bucket. Even if you put it on all the bittorrent trackers it's still not a dent in their overall market share.

But if every subscriber could simply right-click on download because they have ZERO DRM that would be very different. I won't drone on because I already stated my case to another comment. I don't see why you guys keep pressing this point about some tech savvy people being able to get through DRM.

YouTube videos are trivial to copy, but you can't right-click on them to download. The thing is, you are holding a mathematically untenable position here.

In order to allow someone to consume your encrypted content, you must give them a valid decryption key, in some form. If you can view the content, it is literally impossible to prevent a determined user from copying it, either digitally or through the analog hole. In current computer systems there is no way to prevent making a high-quality digital copy of an encrypted media stream.

Also, since we've developed a network to propagate information around the planet at a terrific rate, that one determined user's ability to share that content is limited only by the number of people who [a] are interested in the content and [b] have the (lesser) technological skill required to obtain a copy, via file sharing networks or sneakernet.

DRM is pure snake oil. It does not and can not do anything to prevent content distribution. The only possible outcome is to inconvenience legitimate use -- thus degrading the value of your product versus the pirated media. You're already competing with "free", you might want to avoid stacking the deck further against yourself.

The ultimate conclusion here is that enforcing copyrights on digital works is impossible. It's not practical to close the digital hole, and impossible to close the analog one. I'm sorry if that impacts your business model.

Of course someone would do that; even with DRM, people have done that. What content is available on Netflix that is not available on The Pirate Bay?

DRM has completely failed at preventing people from pirating content; and yet, companies selling content seem to be doing plenty well at it. Why do we keep insisting that DRM is necessary or else people will pirate all of the content, and thus making our software and standards more complex, more flaky, and work against the interests of users, when the existence of piracy is obviously not destroying the content providers now?

You know what's preventing them from making more money? The fact that because of complex licensing schemes, DRM, and the like, I can't be guaranteed that if I buy content I can play it on the devices that I choose to use. If I pirate a video, I can play it anywhere. Content producers are shooting themselves in the foot because of their fear of piracy; piracy works better than buying the content directly, and will continue to do so as long as they insist on DRM.

I'm confused why anyone would think it would make it more profitable. You do understand that any content which is unencrypted is mind-numbingly simple to copy, right? That's how bits work. If you think DRM stops any copying or piracy for digital media, you're very confused on how technology works.

> a technology that is decidedly against the public interest.

Hey, not all of us believe that. I'm perfectly fine with putting DRM on streaming video; I certainly don't expect to be able to download all of netflix to my computer for one month's subscription. It's much more of an issue when I pay full price for a movie (after pressing the "Purchase" button) and I find I don't actually own it.

Content decryption modules are plugins by another name. The spec gives no guarantee that a given CDM can be interoperable with all browsers (being a binary it can possible arbitrarily reject to operate with a given browser), Operating system (because it's a binary) or that all browser functions and accessibility features will work with them (CDMs could completely bypass the browser's rendering pipeline and overlay the content using protected paths).

The proposal is a step back for the openness and interoperability of the Web. Substituting plugins with binary CDMs is not progress and I doubt any kind of popular content which rights are held by the big copyright giants will be compatible with clearkey.

I foresee that GNU/Linux users will be shafted and will not be able to access DRM'ed content and the proposal is toxic towards the Web.

Content decryption modules probably won't be plug-ins.

> The spec gives no guarantee that a given CDM can be interoperable with all browsers.

I'm not sure if the CDM is actually part of the spec. They are in the diagram for illustrative purposes. The APIs being proposed on the media element are agnostic to the type of CDM being used.

> The proposal is a step back for the openness and interoperability of the Web.

If you include video from Amazon, HBO Go, Netflix, and others in your definition of "the Web", then I disagree. This spec expands the set of applications that can be implemented in HTML5 and javascript. It doesn't immediately change the interoperability of these applications, which already have limited platform reach, but it at least opens the door for more platforms (like Linux).

>I'm not sure if the CDM is actually part of the spec. They are in the diagram for illustrative purposes. The APIs being proposed on the media element are agnostic to the type of CDM being used.

The spec may not have specifics on the CDMs themselves but that doesn't really matter. A closed-source, platform specific CDM (e.g. one distributed with Windows containing keys for the major media distribution behemoths) is very bad for interoperability. Such kinds of CDMs will probably not find their way to GNU/Linux of BSDs.

>If you include video from Amazon, HBO Go, Netflix, and others in your definition of "the Web"

The Web is the platform itself, not the services offered over it in my book. Companies and business models rise and die all the time but the platform of Web is what remains behind. It should not be saddled by companies like Netflix that use it and try to influence its direction to further their interests. And there is no open door for open-source, CDMs on open-source systems without a "Protected Media Path" or similar.

Simple question:

Do you think EME is actually going to prevent Netflix shows from showing up on thepiratebay?

I don't think it has any chance - DRM on PCs is always pretty quickly bypassed - which is why it frustrates me so: it will likely end up preventing Linux users from accessing content legitimately, or Mac users from AirPlaying content to their TVs, with no actual benefit against piracy. At least where it pertains to high value content, it is little but a lie mutually agreed upon with rightsholders. :(

> Do you think EME is actually going to prevent Netflix shows from showing up on thepiratebay?

No, and that isn't the purpose. The purpose is so that Netflix can show you movies that Hollywood lawyers insist be encumbered with DRM because they won't try and understand that DRM doesn't actually do anything. Maybe one day Netflix will be big enough to push back, like Apple did with mp3 DRM, but until then, this is the only way to show premium content to people without requiring a plugin from Microsoft.

> it will likely end up preventing Linux users from accessing content legitimately,

Actually, the inclusion of EME in HTML5 is exactly what would enable you to watch content on Linux.

So we're including things in the HTML spec just to satisfy hollywood lawyers now? We would be saddling a spec(and any browser wishing to implement it) for what will probably be a decade and possibly more just so hollywood execs/lawyers can cover their asses and protect a dying business model which will probably be outlived by both the spec and implementing browsers.

I find that stupid, to say the least. Especially since, it is highly likely that at some point, some company will be big enough to push back and distribute things DRM-free just like Apple did with iTunes.

But once the model dies, why does it matter if it is in the spec? If a company (say Apple) gets big enough to demand no DRM, like Apple did with music, then no one will use the standard anymore.

So why does it matter if the standard makes it easier to more widely distribute the content, which will only help in hastening its demise by allowing someone to grow big enough to push back?

Given that for EME to not be trivially bypassed, the CDM has to be a blob implementing its own decoders, how is this significantly different than Flash or Silverlight binary plugins?

Why would whoever's developing these CDMs (each individual site I'd assume?) suddenly invest the resources into providing Linux versions?

Google owns this company: http://www.widevine.com

Which already has a linux plugin. That is why they are pushing for the standard as well.

Locks don't prevent cars from being stolen or homes from being robbed. Determined attackers have the advantage. The real problem with DRM is the lack of convenience and user unfriendliness. I must say, however, that the DRM in Netflix is nearly invisible except for the plugins. It looks like this proposal effectively reduces the size of the plugins required.

DRM is not meant to stop the flow of content to thepiratebay, and never has been. Its purpose is to stop casual sharing, enforce region restrictions, and encourage repurchases. That's all.

A few question about the EME proposal:

> BTW, open source browsers can easily implement this spec since it doesn't require the browser to implement a "decryption module" themselves.

Does this mean, that the 'decryption module' is necessary closed source?

And from the spec:

>4.1 "Secure proof of key release must necessarily involve the CDM due to the relative ease with which scripts may be modified. The CDM must provide a message asserting, in a CDM-specific form, that a specific key or license has been destroyed. Such messages must be cached in the CDM until acknowledgement of their delivery to the service has been received. This acknowledgement must also be in the form of a CDM-specific message. "

Perhaps I misread, but the datastream is relayed from the browser to the CDM ( and the browser loads and potentially modifies the CDM), so how does the standard ensure that the proof of destruction is actually a message from the CDM and not from the browser?

>9.1 "Everything from user-generated content to be shared with family (user is not an adversary) to online radio to feature-length movies."

Does this imply that from the standpoint of the proposal the user is an adversary, unless specifically noted?

> Does this mean, that the 'decryption module' is necessary closed source?

Is there any precedent of anything being closed source behind standards implementations from the W3C? That seems unlikely, this seems terrible.

Thanks. I read the spec and saw this regarding open source browsers:

"9.5. Can I ensure the content key is protected without working with a content protection provider?

"No. Protecting the content key would require that the browser's media stack have some secret that cannot easily be obtained. This is the type of thing DRM solutions provide. [...] In addition, it is not something that fully open source browsers could natively support."

Exactly. This illustrates why this W3C spec is not DRM. Some other DRM technology is needed for certain modes.

So it's not DRM, it's just a way for 3rd parties to plug in their own DRM system.

Sorry, that's worse, not better.

Third parties, namely Flash and Silverlight, already plug in their own DRM systems via NSAPI. How is this worse?

Oops, I meant NPAPI (not NSAPI).

Depends. What Flash and Silverlight do is just as bad => This proposal isn't worse.

But Flash and Silverlight are dead or dying and were never public specifications we cared about. What I consider 'worse' here in this proposal is that we'd kind of 'bless' the DRM layer in HTML. I fear a comment like "Hey, it's part of HTML 5 so it has to be good, right?" if nonsense like this is added.

We don't want to make it easier to add DRM. The more painful it is, the better.

> If we're going to transition to a plug-in free web then we need HTML5 video to support these extensions.

So, a plugin-free web that requires plugins?

Smaller specialized standard plugins.

Smaller, specialized, closed-source plugins that are practically guaranteed to become attack vectors.

Personally, I'm glad Flash is dying and am not in any real hurry to replace it.

No, it doesn't require plugins. The EME approach is agnostic to whether the "decryption module" is implemented by the OS, the browser, or a plug-in. Nothing specifies where they come from, but in practice I think they will usually be provided by the OS. We'll have to see what browsers end up doing. There will probably be a variety of approaches.

So in this scenario, what is the “decryption module” likely to be? Software you download? Software that comes with the OS? Hardware baked into the chip or motherboard?

What would prevent determined users from reading, and publishing, any “secret” keys used by such a decryption module? I'm assuming the answer is nothing, since this seems to have happened with every DRM scheme that has been tried.

1. DRM is unethical.

2. DRM is a dying trend.

3. DRM goes against the principles of the open Web which W3C is supposed to promote.

Given the above, it's not the business of W3C to promote DRM on the Web let alone to standardize it. Quite on the contrary, W3C should prevent DRM proliferation. And it's simply dumb to standardize the dying trends. Why doesn't someone propose to make Flash a Web standard for example? It's still widely used, but it's a dying trend for the Web.

> The W3C spec does not put "DRM in browsers." It allows browsers to use "decryption modules" that already exist elsewhere, like in the OS platform. There are APIs to determine what sorts of "decryption modules" are available and to use them to decrypt media.

See the W3C mail list. It is about putting DRM in the browsers. The language was watered down on purpose, but it doesn't change the reality.

The bottom line - those who think they need DRM - let them stick with what they have. Those who want to move to open web - don't need plugins and don't need DRM either.

So, if these decryption modules are already in the OS, what's to stop people from straight up ripping the streams?

Will EMEs be a new attack surface for security exploits? Who will be creating them and will we be able to rely on them to fix bugs responsibly and in a timely manner?

Netflix doesn't deserve respect for obliging the movie industry in pushing DRM to the Web.

Reply on news.ycombinator.com