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.
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'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.
I would argue the exact opposite.
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.
Specs have had business concerns in them since... ever.
Good specs haven't.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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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 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.
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.
My original point stands.
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.
I'm done here, have a nice day.
For a change, here is my favorite story about pitfalls of intrusive preemptive policing:
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??
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...
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 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.
http://thepiratebay.se/search/house%20of%20cards/0/99/0
I don't see Netflix going out of business because of this.
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.
Besides Youtube is a free service, that everyone basically assumes will continuously be there. You're bringing up non-related factors.
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.
That's because YouTube content can be trivially shared with other people.
Stop the sharing and pretty sure you would start to see piracy.
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)
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.
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.
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.
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.
> 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).
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.
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. :(
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.
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.
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?
Why would whoever's developing these CDMs (each individual site I'd assume?) suddenly invest the resources into providing Linux versions?
Which already has a linux plugin. That is why they are pushing for the standard as well.
> 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?
Is there any precedent of anything being closed source behind standards implementations from the W3C? That seems unlikely, this seems terrible.
"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."
Sorry, that's worse, not better.
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.
So, a plugin-free web that requires plugins?
Personally, I'm glad Flash is dying and am not in any real hurry to replace it.
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.
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.
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.