8 ms·
W3C Proposal from MS, Google, Netflix for adding copy protection API to html5
- ldite 15y agoProposal includes a good FAQ section; http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#faq http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-medi...
- AndrewDucker 15y agoPresumably this is to avoid the need for Flash for video streaming. I believe the two main advantages of Flash over the Video tag are that Flash can encrypt, and flash can do adaptive rate streaming - and adaptive rate streaming is also going through the standards process at the moment.
- ldite 15y agoAn MPEG standard for adaptive streaming (DASH) has just been ratified: http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=79382 http://www.streamingmedia.com/Articles/ReadArticle.aspx?Arti... http://dashpg.com/?page_id=25 http://dashpg.com/?page_id=25 Firefox and Chrome both seem to be working on implementing it: https://bugzilla.mozilla.org/show_bug.cgi?id=702122 https://bugzilla.mozilla.org/show_bug.cgi?id=702122 https://code.google.com/p/chromium/issues/detail?id=109652 https://code.google.com/p/chromium/issues/detail?id=109652
- kennu 15y agoIf I understand correctly, this is to protect the content during delivery over Internet. But the user agent is free to do whatever it wants with the content once it gets the decryption key. I suppose servers could decline to give the keys out to untrusted user agents.
- beggi 15y agoHmm, i haven't read the draft but doesn't just https cover what you're saying?
- Tuna-Fish 15y agoHTTPS streams cannot be cached, and encrypting large media streams on the fly to all your clients would be rather expensive.
- dthunt 15y agoThe expensive part of https is session creation.
- Tuna-Fish 15y ago... only because the typical http session is a few tens kilobytes. When you want to stream gigabytes of data for each client, for millions of clients at a time, you are going to start caring about the overheads you create elsewhere in the pipeline.
- dthunt 15y agoSorry. I should be more clear. The initiation of an HTTPS session is expensive because it consumes a large chunk of CPU for a real-world-measurable chunk of time, all at once, in most libraries. Everything beyond that point you're dealing with <use algorithm of choice> over <max of 32kb> of data. It does indeed consume CPU. It does indeed consume perhaps 8x MORE memory than a typical http connection - but the memory side here is completely dominated by the fact that we're trying to cache multiple gigabytes of data. You can serve HTTP faster than you can serve HTTPS with less CPU - this is objective fact. But if we're talking about CPU utilization? I can't speak to whether this argument has traction right now, for large connections, relative to the claimed 'non-problem' position of several companies who serve small sessions dominated by that connection time, but as time passes it's going to be even less coherent a position than it is right now.
- dhx 15y agoIt may be possible under the proposal but is distant from the intended or anticipated uses. This proposed extension appears to provide a means for distributing keys between DRM chips/implementations (BD+/AACS/etc) and a remote license server. The reason this is a HTML specification extension is that Netflix and Google want to use <video> within HTML -- thus the browser environment must become responsible for interfacing between the DRM implementation and license providers. Knowing the "keys" being transmitted is not useful because they'll be encrypted using public key cryptography. A heavily protected/tamperproof[1] DRM chip will have access to the actual keys required to decrypt the content. This could take the form of a Trusted Platform Module (TPM) as part of the widely criticised "Trusted Computing" initiative (is this one of the reasons why Microsoft is involved with the proposal?). Some of the motivations of pushing towards this heavily restricted and inaccessible method of delivering content could include: 1) Ability to lock content to particular devices (iPhone users can access a TV show 2 weeks before anyone else). 2) Taking control over the purchasing cycle of consumers by forcing constant hardware upgrades. 3) Renting content for short durations of time under very specific conditions and limitations. 4) Pricing content on a per-user basis (some users pay more than others for the same content) [1] Security Engineering, Edition 1, Chapter 14 by Ross Anderson - https://www.cl.cam.ac.uk/~rja14/Papers/SE-14.pdf https://www.cl.cam.ac.uk/~rja14/Papers/SE-14.pdf
- alan_cx 15y ago"It may be possible under the proposal but is distant from the intended or anticipated uses." Always a scary sentence.
- alanh 15y ago> untrusted user agents All user agents are untrusted, and for that matter, are often not the UA they claim to be. C’est la vie.
- vog 15y agoFrom the proposal's abstract: No "DRM" is added to the HTML5 specification, and only simple clear key decryption is required as a common baseline.
- dhx 15y agoPlease explain why the specification makes continued use of the word "license" -- a word that has little meaning outside the context of Digital Restrictions Management. Why did they feel the need to use the word "license" and not just "key"?
- dave1010uk 15y agoCan anyone explain how this differs from HTTPS in terms of features and goals?
- ecaron 15y agoIt is providing a mechanism to make it significantly more difficult for the end-user to directly copy/retain the video as it is being streamed to them. 7.3 in the spec is the best example demonstrating how the license model of this implementation differs from how SSL behaves.
- Tuna-Fish 15y agoHTTPS is fundamentally uncacheable. This specification seems to allow encrypting the media once, and streaming that to everyone.
- dthunt 15y agoI take issue with some of the thoughts I see echoed by this and other comments - that the real goal of encrypting video content is to prevent third parties from watching it off the wire, or that the reason we should have DRM is so that video files may be cached. The goal here is to break the end-user's ability to access the material at will.
- ldite 15y agoHTTPS is is fundamentally incompatible with caching proxies, CDNs, etc. This scheme would (amongst other things) allow secure exchange of keys (and other data, such as license) while distributing the bulk of the content via http. This means that the heavy lifting of distributing video can be done by CDNs, with the high-value keys/licenses going over secure links. And there's more to this than just the transport encryption: it provides a standard API for decryption modules in the client, so a browser doesn't have to understand the details of every technology.
- ldite 15y agoThis means that if a provider such as Netflix wanted to, they could supply you with (say) a USB crypto dongle that you would plug in to your PC, which could then interact with your browser to authenticate you, and potentially even decrypt content (or rotating media keys) on the fly. This is, I believe, pretty much what a lot of cable access cards do.
- dazbradbury 15y agoI'm glad this is being discussed. It's is an important proposal, and as long as it's thought about carefully, will help move our web video service forward. My experience recently is with Lovefilm, where they switched to silverlight delivery of content citing "anti-piracy measures" [1]. If we want to move to a www with HTML5 only video, an addition to the standard is required. Whilst there will no doubt be people opposing any copy protection, I'm sure many can cite examples where it's exclusion is hampering the web. [1] - http://blog.lovefilm.com/uncategorized/why-were-switching-from-flash-to-silverlight.html http://blog.lovefilm.com/uncategorized/why-were-switching-fr...
- dhx 15y agoThe proposal is an additional layer of cruft that doesn't assist copyright holders in any way with protecting their content. Content protection should be as simple as refusing the stream content to unauthenticated and unauthorised clients. 1990's era HTTP specifications are perfectly acceptable (and widely supported) means to accomplish this. This proposal _is_ DRM in the sense that it makes it much harder for paying legitimate users to access and control what they've purchased. It continues to provide incentive for users to pirate content using far simpler and more accessible channels.
- dazbradbury 15y agoWhilst I agree with your argument, there is clearly something missing, as it's not how it's being executed. The point is that if you are authenticated to view streaming content, you may not also be authenticated to copy and distribute it. This is flawed thinking on the content providers part, and has always been the case (recording the radio, using a VCR, etc.) I'm not stating that I agree with the concept of this kind of protection, I'm merely suggesting that it exists, and needs to be accommodated. Clearly there will always be a way to circumvent whatever protection is in place, but there is no reason for a reliance on third-party plug-ins to do the job.
- VMG 15y ago> Content protection should be as simple as refusing the stream content to unauthenticated and unauthorised clients. This is about copy protection. You can argue that that is practically impossible to do, but this isn't about about client authorization.
- bwarp 15y agoHow does this fit in with an open source model? Surely you can just extract the keys/license without reverse engineering anything then? It's daft.
- rbanffy 15y agoRestricting what you can do with data doesn't fit well with open-source. If you can read a stream and decode it to a screen or speaker, you'll also be able to save it to a file. If you can't change the software to do whatever you want it to (and download copy-protected streams is one thing you may want) it's not open-source.
- wmf 15y agoThe DRM components won't be open source.
- bni 15y agoI guess Mozilla could implement this and still allow the user to save the .mp4 in Firefox. For DRM to be "effective" you have to control the client and not allow arbitrary implementations. Or what am I missing here?
- dthunt 15y agoThe DRM stack is outside the browser.
- pgeorgi 15y agoHow is that different from some binary-only browser plugin (with limited availability on platforms that the DRM vendor doesn't want to support)? All it does is giving credibility to DRM ("but the W3C has a standard for that!")
- tomjen3 15y agoBut so what? The browser needs access to the picture to display it, so there is no way to prevent the browser from saving the picture to a file.
- grep2 15y agoThis proposal reminds me of the RFC specifying a security flag in the IPv4 header. http://www.ietf.org/rfc/rfc3514.txt http://www.ietf.org/rfc/rfc3514.txt
- rbanffy 15y agoYes, but it was published a couple weeks too soon. Someone may take it seriously.
- dthunt 15y agoSince nobody else is saying it. The issue with this proposal is that it it creates a segmented web, whereby if a vendor does not ship a "CDM" for a particular platform, you will never see DRM'd web content for that platform. To those of you who are thinking "Woo! Now there's any easy way to get my license keys!" you have missed the part where there's a media layer interacting with a DRM stack - this is essentially the same situation as today. The only thing this does is give blessing to break principles of universal computing. I am opposed.
- MatthewPhillips 15y agoWhat's your alternative?
- dchest 15y agoNo DRM?
- MatthewPhillips 15y agoThat was already an alternative. One of the editors on this proposal is a Netflix employee; that should tell you something about the viability of that option.
- dchest 15y agoOf course Netflix wants to control video steaming. They are free to accomplish their business goals by any other means: making their users download some software, shipping locked hardware to users, or sending employees to people's homes to make sure they don't copy anything. They are not free, however, to break the Web.
- freehunter 15y agoThey're free to try, though, as we all are. It's up to W3C to find value or not.
- realschool 15y agoThis sort of thing has to happen, as great as the idea of media embedding in HTML5 is there needs to be copy protection.
- dchest 15y agoNo, there's no need for copy "protection".
- kennu 15y agoI think the "need" comes from the content owners, who refuse to license their material to services that don't implement a form of DRM that they approve of. It would of course be much easier if the content owners some day understood that DRM solves absolutely nothing, only makes the UX worse, and the content is still being copied freely out there, despite all the protection.
- rmc 15y agoI think the "need" comes from the content owners, who refuse to license their material to services that don't implement a form of DRM that they approve of. Poppycock. If I were unwilling to come to work unless I was to get €1,000,000 per day and the system wasn't set up to do that, then I would have to stay at home all day. I would have no right to insist that just because I find the current system unsuitable that it should be changed.
- Silhouette 15y ago> If I were unwilling to come to work unless I was to get €1,000,000 per day and the system wasn't set up to do that, then I would have to stay at home all day. I would have no right to insist that just because I find the current system unsuitable that it should be changed. And if you were unwilling to consume content unless you were to get it without any technical measures to enforce the terms on which it is offered and the system wasn't set up to do that, then you would just have to do without the content. You would have no right to insist that just because you find their current business model unsuitable that it should be changed.
- malandrew 15y agoPersonally I see this as a short-term gain for MS, Google and Netflix and a long-term loss for everyone else. If we implement this, then we delay a web where copyright enforcement, except in cases involving the most egregious violations prosecutable in court, is viewed as the exception rather than the rule. I am opposed. Leaving out DRM helps establish new social norms that benefit the commons over individual players. We all end up richer in the end.
- Legion 15y agoThat doesn't work if you can't get content providers in the door. My attitude towards DRM changed somewhat when I saw what happened with the online music stores. DRM was absolutely required for Apple to get major labels to the table. Then, over time, DRM was chipped away, to the point where the iTunes Music Store is DRM-free, Amazon's MP3 store is DRM-free, etc. If we can skip the DRM phase entirely, sure, I'd be on board. But is that realistic?
- derekp7 15y agoBut is the Apple-DRM thing repeatable? The circumstances there were: 1) Apple had a majority market share on portable music players. 2) The only DRM that worked on those players was Apple DRM. And the other way around -- Apple DRM was not available on any other players. This led into a lock on the market, where the music industry had to play by Apple's rules. So to break out of that, the only option was to go DRM-free (so they could sell music through Amazon, etc). In the case of other content, for the most part it is either streaming only (most of the movie content, Netflix etc), or there are multiple players in the device market -- Amazon, B&N, Sony, etc. for ebooks. I would hope that DRM goes away for all other media, but I don't see the other industry players giving in anytime soon.
- AJ007 15y agoI view DRM as a toy or trinket that has been used to get content providers to agree to digital distribution. It would kind of be like securing your house by placing a sign on the front door saying, "sorry this door is locked" I think the real intention here is MS, Netflix, etc, wanting to distribute & sell video to iOS users without paying Apple a cut, and they need DRM outside of apps.
- 51Cards 15y agoI wonder if this proposal (which was inevitable eventually) is a direct result of a couple things. - Apple decides (wrong or right) to not support Flash on a wildly popular mobile platform - Flash begins its demise in general (again inevitable but IMO a little too soon) - Adobe cedes further development on Mobile Flash - secure video content deliverers are immediately faced with loosing the only existing "secure" video "standard" on the web and having to develop platform specific solutions - a proposal is put forward to put DRM into HTML5 video (which it is going to have to get eventually for ubiquitous adoption, like it or not) That's the chain I see.. which may have pushed this HTML5 DRM thing to the forefront before it has been properly hashed out. Not placing fault on any of the parties there, just a chain of events to me.
- eli 15y agoDon't forget the brief rise and fall of Silverlight
- mindslight 15y agoDon't forget the popularity of netflix/hulu/itunes and however else people are duped into supporting the content cartels. The 'web' was on its way to becoming a receive-only ghetto as soon as 'apps' started to replace static pages. The money to be made by giving the masses a hip new cable TV is a nasty accelerant.
- icebraining 15y agoThe 'web' was on its way to becoming a receive-only ghetto as soon as 'apps' started to replace static pages. I disagree completely. It's now much easier to create and distribute your own content than it ever was, in great part exactly because of the new interactive websites. Youtube alone is a great example. Sure, it has plenty of old media content (and plenty of abusive takedowns), but how many hours of amateur stuff is being viewed every single day? Probably orders of magnitude more than there ever was on the web ten years ago. Then there's Flickr, Tumblr, Wordpress, Blogger, deviantART (140k submission/day) and so many more. Sure, Netflix, Hulu, etc are major players, but I don't think user generated content is being replaced - TV is.
- yason 15y agoIt's funny that "unauthorised" copying of not freely available material has value whereas "unauthorised" copying of freely available material has nearly zero value (you could just copy/download the original). So, effectively, by putting up DRM and copy protected content, they make up themselves the whatever value "piracy" has.
- ColdAsIce 15y agoAweful. This stinks. Good bye to a free and open internet, and welcome pay-for-view. Some links are more equal than others.
- sanbor 15y agoOne of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability. http://www.w3.org/Consortium/mission http://www.w3.org/Consortium/mission IMHO, it's against of those principles.
- pslam 15y agoIndeed - this is the first thing I looked up. It's directly against the Mission of the W3C to support proposals such as this. If people want this feature, it is going to have to be a non-W3C standard. I've been commenting against various forms of anti-web proposals such as this for more than a decade. Every 3-4 years somebody proposes to accept RAND (non-free) licensing terms. This time around it's non-free content distribution. Let's hope the W3C remembers who they are, and what they're for, once again.
- chjj 15y agohttp://lists.w3.org/Archives/Public/public-html/2012Feb/0274.html http://lists.w3.org/Archives/Public/public-html/2012Feb/0274... Hixie's response: "I believe this proposal is unethical and that we should not pursue it." It's safe to say I'm very happy with Hixie being the editor of the html5 spec.
- smackfu 15y agoBenevolent dictatorships are great as long as you agree with the dictator.
- dthunt 15y agoI do rather wish he'd elaborate.
- dthunt 15y agoAs it turns out, he did elaborate (as did others): https://www.w3.org/Bugs/Public/show_bug.cgi?id=10902 https://www.w3.org/Bugs/Public/show_bug.cgi?id=10902 There's some vitriol from various parties in there as well, and all the points you would expect from people trying to create an open, accessible, and compatible presentation standard. Standards at its finest!
- kuahyeow 15y ago"The proposal above does not provide robust content protection, so it would not address this use case even if it wasn't unethical." My thoughts exactly once you view the first diagram on the proposal.
- deleted 15y ago[deleted]
- surrealize 15y agoHollywood tried to get a form of content control into over-the-air broadcasts; they got a lot of pushback and ultimately failed. Now over-the-air broadcasts are done entirely in the clear. Requiring DRM for the web is ridiculous as long as the content is being broadcast in the clear over-the-air. Now it's up to us, the tech community, to push back against this attempt at control. The broadcast situation shows definitively that DRM isn't an absolute requirement for the content industry.