Hacker News Reader

Comment by dazbradbury | Hacker News Reader

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.

[1] - http://blog.lovefilm.com/uncategorized/why-were-switching-fr...

View on HN

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.

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

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?

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.

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.

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.

Reply on news.ycombinator.com