Comment by sktrdie | Hacker News Reader

Comment by sktrdie | Hacker News Reader

Tim is right in a way. Most users don't care of DRM, they don't even know what it is. They just want to be able to watch hollywood movies on the Web.

So on one hand W3C can ignore the user's need of wanting to watch movies, by not supporting DRM. Users would then continue downloading plugins. And developers would have no way of interoperating with these black boxes.

On the other hand W3C could do something about it. Users would then have no need to download plugins. And developers would have a much more interoperable system.

Sure we all agree that video should be like HTML, where you can view its source and copy it around and play around with it. But the reality is that movies are exponentially more valuable in today's market than any other digital medium, so it's obvious that their creators are less willing to give them out without any protection.

Yes you might be willing to open-source your jQuery plugin that you've built for your e-commerce startup. But are you willing to open-source your entire project?

Tim is as wrong in every way as he can possibly be wrong.

Open source browsers where what introduced heterogenity to an IE6 monopoly on the web and it made the modern web as we know it possible in the first place. A heterogenous browser landscape is a vital component for a healthy web.

Open Source browsers will not be able to use EME, because the CDM (the proprietary blob part) of it, cannot give random programs (like browsers, which need the raw bytes for layouting/compositing of the content) access. Because then the program could just dump the content in plain to disk.

Hence, Open Source browsers would need to be excluded from accessing the CDM. As a result, Open Source browsers will begin their march towards oblivion as the proliferation of DRM on the web will render them incapable of serving up the content and they will become known as "those browsers that don't work".

Open source browsers will access the CDM just like proprietary browsers do, in a one-way fashion. The decrypted video stream will be sent straight to the display driver, likely on an HDCP protected pathway where available.

That doesn't work. You don't seem to understand how a webpage is composited.

The browser aquires all the bytes it needs to composit the page, and then it layers/animates them by whatever is a suitable compositor (software, hardware accelerated, whatever).

This involves elements on top or behind other elements with various levels of alpha and/or other effects.

The browser cannot do its job if it can't get access to the content.

I certainly understand how a webpage is composited.

Do you think that browsers can currently "get access to the content" being displayed by plugins like Flash and Silverlight?

If browsers don't, your window managers surely do. So you can capture the screen with ease. In order to avoid that, Windows created a whole chain of DRM which prevents user from accessing it. This will never be possible on free software systems.

Yes. The embedd API defines a way for the browser to pass a framebuffer for flash to draw in (a framebuffer is just a buffer of pixels). It uses this 60x a second to composit with the page.

Open source OSes do not and will not implement "protected pathways", it violates the nature and expectations for those OSes. MS enabled this junk deep in its system. That's why the mere fact of using Windows already means using DRM.

It's not the "source" of a video that's in question here. And having HTML at the bottom of everything by no means guarantees "source". Just because HTML is often used to convey source doesn't mean that anything conveyed with HTML is source. Another misconception perpetrated by web types.

Reply on news.ycombinator.com