Hacker News Reader

Comment by dhx | Hacker News Reader

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.

View on HN

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?

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.

Reply on news.ycombinator.com