Live data from Hacker News

EFF Makes Formal Objection to DRM in HTML5

eff.org

191–200 of 280 posts

Re: EFF Makes Formal Objection to DRM in HTML5

#191

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…

"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 t…

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.

Re: EFF Makes Formal Objection to DRM in HTML5

#192
post #83

Earlier quoted context omitted.

I am not sure of the official position, but I seriously doubt Mozilla will EVER implement this. They've been opposing H.264, which is a lesser evil (patents) than outright DRM.

They stopped opposing H.264 once they needed it for Firefox OS. I'd expect Mozilla to support the W3C DRM stuff as soon as someone makes Netflix a requirement for their Firefox OS phone. Maybe it won't be Mozilla but someone shipping Firefox OS will do the work. Then Mozilla will feel pressure to take the patch they provide. They're in a difficult position now that they're in the mobile phone OS market.

Or the very real possibility that Netflix (etc.) won't even be on the Firefox OS platform without EME.

Since Firefox OS builds on an Android userland there could be overlap in the hardware-mediated playback of protected content with Android devices based on the same SOC.

To be clear, after reading the EME spec it's primary a vehicle for transmitting the state of third-party module to Javascript, that module being permitted access to the media element backing a video or audio tag and to perform the final rendering of the content to an output device.

Those who are saying this spec precludes open implementations of a user agent (web browser) should probably read the spec. Some CDM vendors will restrict their plugin from working on open browsers, but there is no reason to do that as the CDM can be the unit processing the protected stream and rendering it. This means that open browsers can implement this spec and use CDMs that conform to an open ABI without compromising the protection of the content.

The CDM if used this way will be responsible for rendering a video or audio stream, not a shared graphics context like Flash or Java, and overlay graphics and UI will be implemented in standard HTML not in the closed CDM module.

Re: EFF Makes Formal Objection to DRM in HTML5

#193
post #37
post #4

The Web is going to get DRM one way or another. Now we can do this the easy way, with standards that are agreed upon across vendors -- or the hard way, with proprietary plug-ins that only work in Windows and Internet Explorer.

> The Web is going to get DRM one way or another. Wrong. The Web already has DRM - Silverlight and other junk. The subject is about not dragging this garbage into the HTML standard. > Now we can do this the easy way, with standards that are agreed upon across vendors -- or the hard way, with proprietary plug-ins that only work in Windows and Internet Explorer. EME won't make DRM "easier" for users - it will still req…

You've hit it: standardization speeds proliferation, and there's no reason at all for the W3C to speed the proliferation of lock-in, effectively supporting a digital arms race.

There may be rationalizations for DRM by certain individuals or companies, just as there are "reasons" from warlords to expand their empires, but none of them necessarily benefit everyone justly. For that matter, there are straight-forward arguments that DRM cannot benefit everyone justly (for example, DRM prevents users from controlling their equipment, or it prevents innovation thereby distorting the market), and if it can't: why on earth is it worth promoting?

Saying DRM should be in HTML 5 is like saying the freedom to murder should be a human right. IMHO, both cross a line that make them (clearly) no longer objectively in the public interest.

The ability to embed plugins is as close to that line as necessary - and that has already been standardized. There is no reason to go farther than that and to proliferate a tool that is not in the public interest (for all intents and purposes a "weapon" against the public).

Re: EFF Makes Formal Objection to DRM in HTML5

#194

Earlier quoted context omitted.

Because not doing so concedes this type of market to Microsoft. Open standards are a way to ensure no specific company has control over stuff like this.

I sound like a stuck record here but: the proposed EME standard in no way standardises the underlying DRM mechanisms in individual vendors' CDMs.

Are you aware of any plan to standardize the API/ABI of the CDM modules. It would be possible to do this without exposing content as the current proposal (EME) just specifies the existence of an API for passing around CDM specific data, such as initialization data derived from streams. It may actually make sense to specify this API/ABI outside of the EME spec, such as through WHATWG. Having a small footprint in the API/ABI might help assuage fears that this is a backdoor to general DRM in HTML5.

Are you aware of the argument for providing the simple clear key encryption or making it a requirement of the spec, or for optionally providing the clear form of the media stream back to the Javascript application? I would argue that the Clear Key scheme won't have applications in the content protection space as it's simple to bypass, but creates an opening for backdoor encryption of general content that has been encoded into a media stream which could be used to protect HTML documents and not just rendered media resources of a document.

Take this example, I'm a MooC with upstream providers that want protections on their textbooks. I choose to deliver my textbooks though HTML5 but not allow them to be copied, such as by intercepting mouse and key events which invoke the native copy and paste options on a web page. I also don't want someone to be able to save the content with a view source or save as command. My implementation is store the content in the media frames of a WebM file and require a certain CDM be installed. I then playback the stream and intercept the unencrypted packets, rendering them into the DOM as innerHTML. I have successfully implemented most of an HTML5 DRM system.

It might seem counter intuitive, but even RMS argued that software that violates ethics (the freedoms, etc.) should be contained in hardware with a clear interface with the rest of the system as preferable to a "blob" which can access the rest of the main CPUs software. In a similar vein, video processing offload chips such as the Crystal support open drivers because they have all of the patent-encumbered elements contained within the firmware of the chip. The chip itself processes MPEG transport streams. We can speak all we wish about "DRM-infested" systems like Windows Vista (also present in Windows 7 and most likely 8), but these are protections occurring at the same level as video codecs and not directly implemented in the browser. Anything supporting DirectShow codecs can support these DRM protected streams. The same is true for systems like Widevine and hardware offloaded video playback in devices like smartphones.

Personally, I'm still trying to understand where in the HTML5 spec it specifies how to render video and audio content on a page, such as what elements are supported in video streams, how macroblocks are decoded, etc. I don't believe it does.

[EDIT: I found the reference I used for the comment about RMS, this is the quote from and article based on an interview with him (at http://cedarandthistle.wordpress.com/2010/06/08/some-blobs-a...):

   But later, Stallman said something that I found very surprising. He said that he has no problem with the firmware being burned into the hardware (via a ROM chip or the like). He said that he wanted a “black box”, and it’s obvious that he has no problem with proprietary firmware as long as it’s permanently embedded in the hardware rather than being loaded into it at boot time.

]

Re: EFF Makes Formal Objection to DRM in HTML5

#195

Earlier quoted context omitted.

"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 t…

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 lon…

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.

Re: EFF Makes Formal Objection to DRM in HTML5

#196
post #57
post #53

Earlier quoted context omitted.

Sure it does. "Don't" is a perfectly reasonable solution here. It won't satisfy all parties, but not all parties are worth satisfying.

The future of everyone being able to view online video (e.g. Netflix/Hulu/BBC) without a plugin is not getting anywhere closer.

The W3C DRM plug-in standard requires proprietary plugins to work.

So you're right.

Re: EFF Makes Formal Objection to DRM in HTML5

#197

Earlier quoted context omitted.

"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 t…

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 lon…

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.

Re: EFF Makes Formal Objection to DRM in HTML5

#198

Earlier quoted context omitted.

Why don't people vote with their time? Don't watch something, for example. I'm not quite sure you understand the idea of voting. It's about making your preference known, and it doesn't quite work when your action has no impact on anyone else.

I disagree. If you don't like the policies of a studio, boycott their content. This is not a new concept by any means[1][2]. If a content provider lacks an audience, it's going to hurt them financially. It doesn't matter if its paid media like a movie or ad based media like a TV show. [1] http://betanews.com/2008/07/08/angry-youtube-users-boycott-v... [2] https://www.google.com/search?q=movie+studio+boycott

Even better - make your own content and distribute it freely without any DRM. Surely that would be a more constructive approach - and more fun!

Re: EFF Makes Formal Objection to DRM in HTML5

#199

Earlier quoted context omitted.

> Because not doing so concedes this type of market to Microsoft. Bullshit. 1) I am able to gleefully avoid it these days, but in the past flash worked with Linux. Furthermore, all relevant DRM systems work with Apple devices including OSX. Netflix works on Android, and on Google's ChromeOS. 2) Even if it did, who gives a shit? I'd rather have people who absolutely must watch netflix on their laptop do it with window…

Netflix actually already "works" in Linux, or at least did back when I last looked it up, and most probably their CDM would as well. I'm of course speaking of using wine. (Having not actually tested the solution, I cannot verify it nor tell about its shortcomings.) Or perhaps they would rely on secure/trusted path this time. I doubt that - the hardware simply isn't there for their customers. Anyhow, I certainly would…

Netflix only sort of maybe works with Wine + Firefox. If you're lucky.

Re: EFF Makes Formal Objection to DRM in HTML5

#200
I would never use a browser that implements DRM. As the EFF stated DRM is a back box with the intent of taking control from the user so why the hell should i allow it in my computer.

If their content is so important to them they can keep it just stay the hell out of my browser.

I value my privacy more then i covet their content.

Post reply on HN