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.
So, much the same as at the moment where if there isn't a version of Flash (or Silverlight) for a particular platform then you can't watch Netflix/Hulu/Whatever.
Netflix/Hulu aren't making these decisions unilaterally. They have to meet DRM requirements set by the Studios.
You seem to want to demonize Netflix/MS/Google/Hulu for this but I'm having a hard time doing so when they seem to be trying to evolve standards to meet current market conditions.
I really, really don't care about their relationship with their business partners. And you should not care about this too. If they are pushing for standards that limit our freedom, I will blame them. From my point of view, they should pressure "Studios" to get rid of DRM for their own good. If they instead make us suffer from DRM I will demonize them as much as I can with the goal of informing public of their evil actions and/or taking them out of business.
I do not see how a "pay monthly" system like Hulu or netflix streaming could work on a system without DRM, where people could simply sign up for one month and download all the videos they could ever want to watch.
Do you have a suggestion, or do you think such systems should simply sink? What should replace them?
People can already download via bittorrent more videos than they could ever watch. Streaming services don't have to compete with that to be successful.
> From my point of view, they should pressure "Studios" to get rid of DRM for their own good.
Presumably they are. Think about it: if you are Netflix, you recognize that DRM adds a lot of technical and business complexity to your product, for a "feature" that your users don't care about or even actively dislike. Why would Netflix sign up for that unless it was the only option?
Not only that, but prominent networks have pulled out of their licensing deals with Netflix recently, which should give you an idea as to the amount of leverage Netflix has with the studios.
There is a standards-compliant way to deliver video. It's not streaming, but their use doesn't require streaming. There's, thankfully, no web standard for DRM.
Just to be pedantic, I experience technical issues with HTML5 playback in Chromium 17 on Linux. The video seems to be playing at 1.5x speed, and sound is extremely choppy. Flash works fine.
The support for the audio and video elements in browsers is still rather basic and unreliable. Shockingly enough, in my experience at least, IE9 has the best support for HTML5 audio / video, with Safari on OS X (not Windows) being second best.
I meant, show me a platform where users can't get Flash for free easily. AFAIR on Windows, Unix and MacOS (I used only the first two) you can just download a free player...
Not accepting it as part of HTML5. Things continue as they - the real cost of these DRM layers isn't the bit of browser glue that issues an http request for a key.
That 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.
Of 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.
As far as I can see, nothing here prevents regular, un-DRM'd content being sent as HTML5 video just as it can be today. This seems to be adding an extra option, which is to send protected content as well.
There is clearly a demand from suppliers for this facility. As a consumer, your options right now are to accept the extra content protected, or not at all. You do not have the third alternative of accepting it unprotected, whether you think you should or not. A content provider is under no obligation to give you their material on your terms just because you would like them to. Declining to give you content at all is not breaking the Web, it's just saying they don't want you as a customer, and if you want to enjoy their content, that's your problem more than theirs.
Ultimately, technology is neutral, and how it is applied is what counts. A standardised version of protected video potentially allows more people access to more content using more diverse business models. Sure, some people will always point at that and say it will be abused in dubious ways. However, the most effective way to defeat any such abuses is to vote with your wallet. If the information-wants-to-be-free crowd are right and there really is plenty of profit to be made on unrestricted content and a large market segment who won't put up with DRM, then the DRM will die.
On the other hand, reasonably effective copy protection also makes low-cost models such as pay-per-view/rental or all-you-can-eat subscription commercially viable. That could very much be in the interests of a lot of people who don't want to pay the full price for a permanent copy of something they'll probably only ever watch once anyway. Such deals are never going to fly in today's culture if the terms are trivially violated, and this has been a serious bottleneck in terms of getting the best content onto on-line providers and ultimately to consumers for them to enjoy.
I'm starting to come over on your side a little bit. I don't care as much about DRM as you do, but I do care about breaking the Web. I'm not convinced this does that though.
To support this a user agent will need to implement one or more CDM that may include communicating with a DRM chip. For devices without the chip the web page won't render properly. We agree that this is undesirable, but it doesn't seem any different to me than the Capture API[1] that only works on devices with a camera or microphone.
Convince me, I'm leaning towards your position here.
One can always simulate a camera or microphone. Maybe you're mute, and you use text to speech software that presents itself to the OS APIs underlying the Capture API as a microphone.
Enshrining technology that has no other purpose than to restrict access to one's own computer into an international "open" standard is unacceptable. At some level in hardware or software there will always be a closed blob to prevent capturing the stream, so there will never be an open software and hardware implementation.
Giving DRM the blessing of the international web community is, effectively, giving Hollywood unfettered permission to be just as obstinate, manipulative, and anti-consumerist as ever.
This is a good argument. I think the difference is that without camera there's absolutely no other technical way a website (that uses cameras) can provide their services. It's an enabling technology, in a sense that it moves progress forward. With DRM chip, there is the other way -- streaming video without restrictions.
I'm just pushing the responsibility of action from Google et al to the W3C. I don't blame Netflix for wanting a better way to stream DRM'd videos. I would blame the W3C if they allowed Netflix to dictate what video on the web will consist of, for better or for worse.
Personally 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.
That 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?
But 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.
I 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.
Content providers will be forced through the door by competition from copyleft and creative commons content.
Competition is the easiest way to combat DRM.
The presence of DRM legitimizes a social norms of restriction. The lack thereof legitimizes social norms of sharing.
DRM is a tangible embodiment of the the tragedy of the commons. DRM is analogous to a series of electric fences partitioning off the commons so that only some cows from some individuals can graze in certain places, but no other cows can graze there. People will invent electric fences for use in chipping away at the commons, but it would be a disaster for society to standardize the electric fences so that anyone can chip away at the commons effortlessly.
I'm of the opinion that if some entity wants to cripple their content with DRM, that is their prerogative, but they shouldn't get help from W3C and other bodies creating open standards.
On top of all that, as a developer, DRM is one more layer of bullish*t to deal with. I'm perfectly happy paying for APIs based on usage. I connect, you measure, you charge. Last thing I want to encounter are APIs which require me to implement a cumbersome layer of DRM to use content.
Lastly, I can only see the presence of DRM reducing accessibility of content for special needs users, such as the blind, because any form of DRM is likely to reduce how you can manipulate content. What if the DRM prevents close-captioning? text-to-speech? Addition of semantic data? etc.
DRM is wrong. It doesn't not produce a better environment for the consumer because it reduces competition.
DRM introduces friction. Friction reduces "liquidity". Lower liquidity results in a smaller market with fewer options.
REST vs SOAP is a perfect example of unnecessary friction in a "technological market". A market with DRM would have the same impact on innovation as a SOAP-based market.
> DRM is wrong. It doesn't not produce a better environment for the consumer because it reduces competition.
The fundamental flaw in your argument is that you assume we would still have the same content available to consume without DRM.
However, the whole reason to allow copyright in the first place is to create an economic incentive for those who can to create and share works. And the whole point of DRM is that people weren't honouring copyrights, so the incentive wasn't working. Clearly there is not sufficient incentive for the major content producers to share their movies via on-line systems without DRM right now, because they have almost unanimously refused to work with such systems, and no-one has been able to force them to do so through commercial pressure.
> A market with DRM would have the same impact on innovation as a SOAP-based market.
The market already has DRM, and there are more (legal) ways to get access to the latest video content today than at any time in human history. But right now, implementing adequate DRM takes more effort than it should, and that has an impact on innovation by at best reducing the efficiency of services working with DRM'd content and at worst rendering services that would otherwise have been successful and beneficial to consumers commercially unviable.
> Content providers will be forced through the door by competition from copyleft and creative commons content.
If this were true, surely we would already see copyleft and creative commons content replacing TV programs and movies, since we've been in the DRM world for so long already. Yet we don't see those things. Why?
* People who really really care and don't mind spending the money have cable or go to the movies or buy Bluray disks
* Many others use Netflix, Amazon and iTunes, which all use DRM for their video content
* For other cases not covered, people either bootleg or just wait till the disc comes out
Free content wonks have been making this same argument for years, and it has yet to come true, so I fail to see why you'd expect it now.
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!
I 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.
Don'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.
The '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.
Sure, the actual volume of publishing and types of content have increased, but the range of abilities has dwindled. Users are only able to interact with each other through opaque centrally controlled services where the middlemen choose how and what the services support and approve (sound familiar?). Having different executable code and a data silo for every implementation of the same idea puts the users at the mercy of the proprietary services (see: any time people whine about a website changing). Their only choice ends up being which company to resign themselves to.
> Users are only able to interact with each other through opaque centrally controlled services, where the middlemen choose how and what the services support and approve
Previously, normal users were unable to interact with each other at all. Do you really think grandma/your uncle/etc would have learned to write HTML, found a place to get hosting, and put it online, if only Facebook hadn't come along?
Oh, and by the way, it turns out you have even more options for putting your HTML content online now [Heroku, AWS, Linode, Wordpress, Jekyll, etc], thanks in large part to the financial and social capital influx that came to the Web during the "Web 2.0" boom.
"Normal users" certainly used email clients, installed web browsers, and used local page-creation tools. That certain technologies have made these tasks easier does not mean that those specific technologies were the only way forward, or that those technologies are without drawbacks. Publishing Turing-complete blobs clearly gives the creator the most freedom and power, but at the expense of limiting the consumers' options to "experience content as intended" or "don't".
My whole point is that this philosophy of server-knows-best is causing the 'web' to revert to the standard creator -> middleman -> passive consumer chain. Of course many different "ways" of publishing are flourishing - those are the middlemen!
If 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.
It 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)
... 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.
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.
HTTPS 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.
This 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.
It 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.
I 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.
Please 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"?
Restricting 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.
One 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
Indeed - 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.
Presumably 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.
I'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.
The 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.
Whilst 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.
I would argue that the problem space reduces to the same thing. Once you hand someone encrypted content along with a way to decode it, you've essentially given them the content and have to trust that they won't copy it. You have no way to protect the content from being copied if you have given out the secret to decoding it.
you can logic all you want. the fact is, content providers want certain implementations of DRM. if "web standards" do not allow for these implementations, then they won't use those standards. you're not going to convince content providers not to have DRM just because its not a web standard - content providers never cared about web standards to begin with.
the question is whether you care more about the adoption of the standard or the purity of that standard. if html5 doesn't include methods for DRM, then hulu and netflix will continue to use proprietary extensions. how much do you care about adoption? if only 50% of sites use it, is it still meaningfully a standard?
I think the penalties associated with using plugins is simply the price DRM advocates should have to pay. I don't think it's the job of the W3C to make it easier on them to maintain this practice. The short-term gain of getting large media players on-board is outweighed by the long-term prolonging of the life of DRM and delaying the advancement of social norms and business practices for media distribution, consumption and ownership.
Looking at the companies that control media today and trying to mold the environment of the web so that they survive is exactly backwards. Instead, I think the W3C should focus on creating the best environment for an open web possible, and let the companies that exist now adapt to it or be replaced by those who can.
None of the open source browsers will be able to include the DRM in their source code anyway, so how different is it from downloading a proprietary plugin?
I assume this will be something that is available in Chrome and Safari but not Chromium and WebKit, etc.
Today you need a proprietary Flash/Silverlight plugin. In this "HTML5 only" scenario (which will probably be implemented regardless of W3C's opinion) you need a proprietary DRM plugin. Nothing has really changed.
Hollywood 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.
It'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.
I 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.
I 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.
> 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.
I like how I get down voted for pointing out an obvious problem with HTML5. Regardless of what world you want to live in, the world we live in is ruled by content owners.
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.