Hacker News Reader

Comment by josteink | Hacker News Reader

This DRM proposition definitely needs all the resistance it can get. We cannot allow DRM into our wonderful, open standards. This is not an option. Not at any price.

I'm honestly surprised that Mozilla haven't been more vocal about this issue. Have they issued any statements what so ever?

Seeing what amazing things the web have enabled the last few decades, purely by being open, who are we to deny the future the same possibilities by locking it all down now? What sort of short-sighted asshole would propose such a thing?

To those who yammer on about Netflix: Allow me to paraphrase Benjamin Franklin. He who gives up freedom for comfort deserves neither.

If this goes through though, what I see others are calling out for is a new consortium. If the W3C is hellbent on forking and fragmenting the web, then lets have it. But let's have it on our terms: By creating a new open web standards consortium.

View on HN

"Open standards" are about documenting interfaces in such a way as that any person could develop a compatible implementation, nothing more.

There is already a massive amount of proprietary tech running the web. From internet explorer to the secret algorithms used by google. Pretending that the web is some hippy utopia is not accurate.

This proposal simply describes a standard protocol for a DRM system to be able to talk to a web browser. If you don't want to use it, simply choose a browser that ships with it disabled or disable it yourself.

You're not going to lose access to your favorite sites because of this. The sites that would want to do this are already implementing paywalls or existing DRM systems.

There is already a massive amount of proprietary tech running the web. From internet explorer to the secret algorithms used by google. Pretending that the web is some hippy utopia is not accurate.

That's a bogus argument and misses the point completely.

That you have closed source systems deployed on the open web is completely OK. That you have closed sourced browsers interpeting markeup is also completely OK. As long as the markup and code produced and published is compliant to the open standards we have all agreed upon.

Because then anyone with the specification can interact with that content. That means that anyone, of any size, can sit down and implement a fully valid and compliant web-browser.

This latest proposal from W3C means an end to that. Having the HTML specification will not be enough to create software able to render all the content on the web. Your browser will need to be "sanctioned" and "supported" by the DRM-vendors in order to work on the web.

New platforms (FirefoxOS, Tizen, etc), new browsers, any new players at all and all open source endeavours are effectively shut out from this new web the W3C is drafting. That is unacceptable.

This is a disastrous departure from any former W3C specification and directly in opposition to the W3C's own mission statement.

We are only left to guess what sort of corruption has lead to W3C sinking this low. Whatever happened to allow this rot, a new consortium seems like a good way to solve it.

Not at all, your browser does not need to be sanctioned.

Anybody can build a browser that speaks HTTP and can send HTML pages around.

There is no mandate that you integrate DRM to be standards compliant, it's perfectly valid to write a browser that simply says "no" to any requests to perform DRM functions.

https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...

You can simply implement a "clear key" system which does not require any CDM.

That misses the point. While anybody can built partial web-browsers, they can't build competitive alternatives to those sanctioned by DRM-vendors.

Just speaking HTTP and partially parsing HTML pages does not a web-browser make.

Yes, you can.

You are free to support whichever content protection systems you want to support. The only DRM mechanism which is part of the standard is clearkey which is DRM in the same way that SSL is DRM, i.e not at all.

https://news.ycombinator.com/item?id=5791579

You mean you are free to implement a second class citizen on this new, closed down and Hollywood-driven web.

Yeah. That sounds really sexy. That sounds like the pinnacle of achievements for open standards.

Hollywood does not have jurisdiction over the majority of web. They cannot force you to use DRM.

They can lock you out, when you are not using DRM.

They can only lock you out of their content (as they are already doing). They can't lock you out of HN for example.

This is problem for you, if you are browser creator: "your browser sucks, I cannot watch Hulu".

You are free to implement whatever content protection systems the developers of the content protection systems allow you to implement, so long as it doesn't conflict with their contracts with content providers (which it probably will in many cases).

The HTML5 ECE spec is intended to make sure it's a criminal offence to implement any "content protection" scheme without permission. In the eyes of both W3C and its proponents, that's a non-negotiable feature.

How is it a criminal offence to implement a content protection scheme? Who's permission does one need?

If I write a content protection scheme that runs everything through ROT13 I don't understand why anyone would care.

Because if you don't have a permission to do so, you're basically 'circumventing' DRM which is illegal under copyright laws in many countries around the world.

Why would I need permission to implement my own CDM? I would not be circumventing unless I attempted to reverse engineer someone elses.

Is for implementing someone's other CDM. It's the "your browser is great, but I cannot watch Hulu in it, therefore it is unusable" scenario.

Why would you implement it yourself? Just integrate this standard and now your browser can talk to Hulu's CDM.

The CDMs are not OS independent.

This proposal only defines how the browser communicates with the module. It does not define, how the module communicates with OS and hardware. These modules will use OS facilities like Vista's protected path. If your OS does not support it (and free software OS like Linux cannot support it by definition), good luck getting it. And even if it supported anti-features like that, the owner may not bother with porting ("not enough market share for you").

True, but that's basically the same situation that you have right now.

Not really. The situation now is labeled "proprietary", the situation then will be "we just use standards". It shifts the framing.

Why would that be a problem?

Because then the standards would no longer be open.

> While anybody can built partial web-browsers, they can't build competitive alternatives to those sanctioned by DRM-vendors.

That's true, but it's not connected to the w3c inclusion in the spec.

People hosing DRM encrypted video could stop your third-party browser from consuming their video with or without the w3c spec provision.

The proposal is to have a standard for a way the browser communicates with non-standards compliant DRM encumbered (essentially encrypted) video.

Anyone is still free to write a client which consumes the standards-compliant parts of the page, but will be unable to consume the non-standards compliant DRM encrypted video.

In this way, it is similar to existing non-standards compliant web plugins like flash. For a long time nobody could just sit down and write a client which consumed flash animations (they were bound by the flash license, which prohibited mobile flash runtimes for example).

I don't agree with this inclustion by the w3c myself, but your argument isn't a powerful argument against it. My objections to it revolve around the w3c overstepping their responsibility (why is it THEIR job to cater to one specific plugin family - is it being driven by political pressure), the futility of its inclusion (they expect an open source implementation, which probably isn't possible for this kind of technology), and the self contradictory statements in the original w3c announcement.

PS. Calling an argument bogus and leaving it at that isn't helpful. If you see flaws in an argument you have to identify them point by point.

> Pretending that the web is some hippy utopia is not accurate.

A typical example of when a comment deserve a downvote. Calling the refusal of adding DRM to an open standard, a standard that is about a network of cooperating nodes that any standard compliant software can parse, is not an hippy utopia.

> The sites that would want to do this are already implementing paywalls or existing DRM systems.

The methods used by such systems are very limited. The same web functionality that DRM wants are the exact same ones constantly being limited to reduce malware. Even flash, which wants to allow arbitrary code are being phased out in favor of more precise html 5 functionality. DRM in the standard would be a direct step backward and open up more maleware, more arbitrary code execution, and more control by third-party of the computation of users devices.

It seems that those making the most noise over this haven't spent the requisite 2 minutes reading the actual proposal.

https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...

From the abstract:

"This specification does not define a content protection or Digital Rights Management system. Rather, it defines a common API that may be used to discover, select and interact with such systems as well as with simpler content encryption systems. Implementation of Digital Rights Management is not required for compliance with this specification: only the simple clear key system is required to be implemented as a common baseline."

"The "org.w3.clearkey" Key System indicates a plain-text clear (unencrypted) key will be used to decrypt the source. No additional client-side content protection is required. "

Such API will encourage more DRM to be access through the browser, which in turn lets malware exploit such vectors in similar way that Java applets, active X and flash has been plagued by remote code exploits. The amount of money and greif caused by such malware is very high, and was a major incentive for moving to HTML 5. The draft in question would rather move so we had 10-20 more such lovely (in)secure plugins all being accessed through the API provided by the standard.

But you can believe that anyone objecting to that just hasn't read the draft if that makes your life easier.

Just disable the plugins or don't install them in the first place.

Thats a horrible solution to suggest. It's like suggesting that people go buy body armor to deal with crime. It non-scaling, do not address the issue, and leaves those most vulnerable exposed.

Malware like to target those that are willing to spend money online. That mean those people who are most targeted are also those who won't disable the plugins that makes them vulnerable to attack in the first place. W3C should focus on making people safer, rather than encourage a environment that consumer, producers and even publishers will be hurt by in the long run.

For whatever reason Big Media aren't going to allow you access to their content without the DRM. Not adding support for this standard will not change that.

If you have Silverlight installed or play big budget games from Steam/Origin etc the odds are that your system is already full of DRM crap.

Ultimately either consumers need to reject DRM or the media companies have to decide not to use it. However at the moment people seem quite happy to install it, so W3C are just making their lives marginally easier.

> For whatever reason Big Media aren't going to allow you access to their content without the DRM

What is "Big Media"? This is just pure speculation not based on facts.

There is plenty of high quality, paid-for content on the web already which does not require DRM.

IIRC, there are no more DRM on music on iTunes either.

It's just a matter of negotiating. If a company's better at negotiationg DRM-free content than Netflix, then too bad for Netflix. There's no reason why web users should support these costs.

The fact that you can build a browser which doesn't support DRM doesn't alter that fact that if we allow this in, W3C has officially sanctioned that the web, one bit and one platform at a time, can and shall be DRMed.

So sure. You can build a browser which only supports clear key. And that browser will not be a fully supported browser on this new encrypted and DRMed web. No FOSS-based platform will be a viable option to consume the web.

Now you can say that we have the same situation today, with Flash and Silverlight, so what's worse about this? Well: The fact that it has W3C's seal of "standard" approval written on it.

Congratulations: You just fragmented the WWW and to top it of you claim its a standard.

If we let this pass, in a year or two we will be having the same debate for <audio> and for <img> and for <script>. This is the beginning of the close-down on the web, and the only reasonable place to stop it, is at its root: No DRM, no EME and no CDMs in HTML5.

You can belittle those who disagree with you, saying they don't know what they are talking about. But it may just be that they are not so short-sighted about where this is heading as you seemingly are.

Right now Hollywood needs the web, more than the web needs Hollywood. Hollywood cannot afford not to be on this train. If we say "no DRM" enough times, they will come eventually. The music industry did. Everyone else did. Hollywood will.

Lets not sacrifice our open standards needlessly.

Hollywood doesn't need nor care about the web or the w3c apart from as a marketing avenue. They would be just as happy delivering all content through a standalone application, as they are doing currently.

Most likely the new generation of games consoles provides a more compelling platform for them to send content to you than a web browser.

There are no "CDMs in HTML5" , this is a nonesense statement.

There is no part of the proposal that advocates for any website to integrate any DRM solution, it is entirely a matter for individual site owners, the majority of whom do not want to put up hurdles for people to view their sites. The web will continue to work as it always has.

> Hollywood doesn't need nor care about the web or the w3c apart from as a marketing avenue. They would be just as happy delivering all content through a standalone application, as they are doing currently.

If they do not care, why are they pushing for getting a W3C stamp on their DRM system?

> There are no "CDMs in HTML5" , this is a nonesense statement.

To accept EME because proprietary CDM are outside of the spec is pure hypocrisy. To say that EME is okay because it would be working with clear-key systems too is complete BS, because such systems already exist and do not need EME. Hence the EME spec is only here to get standardised API for proprietary CDMs, which is why no one else but Hollywood, Netflix and Google & al. are pushing for this.

I would not care about EME, if they were not trying to integrate that into the W3C, which should stand for an open web, where free technologies are on equal footing with proprietary ones. EME would de facto force web users to have proprietary software installed in the form of CDM (which is DRM). Unacceptable.

It doesn't force you to install anything, if you don't want DRMd content don't install the DRM..

There is nothing in the spec that mandates you install a proprietary CDM.

The spec without CDM does not do anything at all. This spec goes hand-in-hand with having a proprietary CDM. So ultimately, standardising this at the W3C means having all open web users install a proprietary CDM.

Again, if this whole debate was outside discussing open web standards, this would be valid. But what we're discussing here is inclusion or not in open web standards.

Why are you so vocal about DRM any way? I know why people are against it and I can imagine why others are for it, so yeah, why do _you_ personally favor DRM?

Ahhh the old slippery slope fallacy.

EME doesn't describe an interoperable standard. It's only a tiny JS interface for invoking proprietary, deliberately unspecified CDM plug-ins (that are protected by DMCA, so you can't use them even if you knew how).

It's as if you wrote spec for `<object classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000'/>` tag and said Silverlight is now a W3C Recommendation.

That's even a step back from Silverlight today, because at least it has de-facto NPAPI standard interface that CDMs don't.

Beyond that, it doesn't even define the plugin API side of it, only the JS side. Defining the plugin API would make the proposal less bad (!= good) as then at least the plugins wouldn't be browser specific (though I suspect quickly enough a de-facto standard will appear)

I mean, at least something like NPAPI is (somewhat) documented, so that one can support all NPAPI plugins in any browser (say, Flash, Silverlight on OS X, etc.), even if what the plugins do themselves it totally undocumented…

By allowing DRM to become a standard, it will actually help the open web, because Linux users can then watch stuff like Netflix, HBO Nordic, etc which all use some closed source for displaying content, eg. Silverlight(Netflix) and Widevine (HBO). Currently its either a total hacky solution or impossible to use this on linux. Better have it standardized than a closed source restricted solution.

No they won't. I doubt Linux users could be able to use Linux CDMs to decrypt EME content because they probably won't be released.

What you are saying is completely untrue. Please, read the EME proposal. It is a specification for interop between Javascript and closed-source, proprietary CDMs.

If there is one thing I wish that HN would understand from this entire discussion: EME will not get you Netflix on Linux!

Reply on news.ycombinator.com