Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Except Flash was at least used for stuff other than just DRM, so there was an incentive to get it working across all OSes. Linux is going to struggle once this is adopted, at least open browsers will, and that makes me sad


The openness of the browser has nothing to do with it, the browser provides an interface to the DRM mechanism which could be open or closed source. Open source browsers like firefox already support proprietary plugins such as Flash.

If anything this makes Linux support easier, because you no longer have to provide support for an entire virtual machine and all APIs such as Flash or Silverlight. The only software required will be the DRM module itself as everything else can be provided by the browser.


The DRM mechanism can't really be open source. You could simply change it to write the unencrypted video data to the disk if it were.

A plugin DRM module will also have to do all of the video rendering and displaying. Because if it just hands the unencrypted stream back to the browser then you could change the browser to simply write it to disk.

The relevant DRM mechanisms will come from Apple, Microsoft, Google, and Adobe. Both Apple and Microsoft have no interest in supporting GNU/Linux. You won't get their DRM on GNU/Linux no matter how simple it is. Google seems to ship their DRM now on the GNU/Linux version of Chrome. But I don't know if the license allows using it in other browsers. Which would be hindered by the fact that Google uses their own unspecified PAPPI. Adobe wants to provide a DRM module for Firefox EME mechanism. But we all know from enough bad experience how well Adobe does GNU/Linux support. Flash on GNU/Linux was even worse than on any other system until they simply stopped it. They recently even stopped distributing Acrobat Reader for GNU/Linux. So yeah, great hope there. Even if they compile the module for GNU/Linux because Mozilla asks them to then we can expect the typical Adobe software safety and quality... Remember HTML5 was supposed to rid the world of Flash, Silverlight, and such things. Not force those binary blobs into the spec.


Having an EME spec allows for competition in the DRM market, it creates a business opportunity for a company (or potentially a solo dev) to develop a cross platform solution.

EME means you rely less on Adobe code than you did previously as they are no longer shipping an entire runtime, just the content protection module.


You are completely wrong here. Please note that the EME proposal does _not_ specify a plugin interface for the Restriction module! It only specifies how the Restriction module is exposed to JavaScript. How the Restriction module is implemented or connected to the browser is up to the browser developer. Both Google and Microsoft are involved in the creation of the spec and Apple is also supporting it. All three companies make up a large share of the web browser market. And all three companies have their existing DRM solutions which they are using for their EME implementation. None of them have announced a plugin interface to allow other companies to provide a DRM module.

The only browser vendor who wants to implement EME via a plugin is Mozilla. Simply because there can't be a free software Restriction module implementation (and consequently due to the W3C's efforts there defacto can't be a fully free software web implementation). And Mozilla already made a deal with Adobe to provide the Restriction module.

So no, there won't be a market. It will actually close down the market. Content providers will have to support those four DRM solutions if they want to offer their content on all those platforms. They won't have any choice.


That browser vendors will bundle their own solutions doesn't really close down the market and I don't understand how it would necessarily hurt cross platform adoption?


Of course it closes down the market. There won't even be a market. There is not going to be a plugin interface (except for Firefox) to provide a different Restriction module.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: