Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reconciling Mozilla’s Mission and the W3C EME

andreasgal.com

Post reply on HN
Print view View original

31–40 of 195 posts

Re: Reconciling Mozilla’s Mission and the W3C EME

#31

Post by mindcrime »

JoshTriplett wrote: post #22
mindcrime wrote: post #4

and in the near future this should allow us to retire plugins altogether. I don't see this as a universally "Good Thing". The Web has evolved to a comprehensive and performant technology platform and no longer depends on native code extensions through plugins. You mean the Web has evolved into a Doctor Frankenstein's monster like hodge-podge of kluged together hacks, layered on top of layers of other hacks, layered o…

Replacing unsandboxed plugin APIs like NPAPI that can directly access the OS with sandboxed plugin systems like NaCl and emscripten that support sandboxed native code seems like a major improvement. The browser is quite enough attack surface area; let's not expand it further by having plugins. That said, while the article's described sandboxing approach to EME works better than the alternatives (assuming content prov…

Don't get me wrong, I'm not saying we should keep NPAPI around forever... and I acknowledge security as a legitimate concern. But power and extensibility are legit concerns as well, and I worry about an overly restrictive environment where the evolution of media on the web is forced into lockstep with the evolution of browsers, without even the option of going "off the reservation" and using something radically different.

Of course, at the end of the day, this is one HUGE advantage of OSS, and with many of the major browsers being OSS, someone could always fork a browser with whatever kind of plugin support they want if they really need it (and are able to support it).

Re: Reconciling Mozilla’s Mission and the W3C EME

#32

Post by JoshTriplett »

AnthonyMouse wrote: post #27
JoshTriplett wrote: post #22

Earlier quoted context omitted.

Replacing unsandboxed plugin APIs like NPAPI that can directly access the OS with sandboxed plugin systems like NaCl and emscripten that support sandboxed native code seems like a major improvement. The browser is quite enough attack surface area; let's not expand it further by having plugins. That said, while the article's described sandboxing approach to EME works better than the alternatives (assuming content prov…

> Replacing unsandboxed plugin APIs like NPAPI that can directly access the OS with sandboxed plugin systems like NaCl and emscripten that support sandboxed native code seems like a major improvement. Until you want to write a plugin with a legitimate reason to directly access the OS.

Legitimate reasons to directly access the OS are typically "there isn't a browser API for this yet". We have multiple Open Source browsers now; submit a patch to one or more of them to add a new API, and ideally start working to standardize it. The result will be far better and more secure than a one-off custom plugin to pass through specific OS functionality.

Re: Reconciling Mozilla’s Mission and the W3C EME

#34

Post by davexunit »

>We have come to the point where Mozilla not implementing the W3C EME specification means that Firefox users have to switch to other browsers to watch content restricted by DRM.

Then so be it. If Mozilla's mission is to improve and defend the "open" web, then EME should never have been considered for implementation. They shouldn't sacrifice their goals for the sake of market share.

Re: Reconciling Mozilla’s Mission and the W3C EME

#35

Post by AnthonyMouse »

chimeracoder wrote: post #16
nawitus wrote: post #7

>preventing users from saving the content How can an open source software prevent users from saving the content? If the CDM decrypts to plaintext, it should be trivial to modify the open source sandbox to save the plaintext data. (Obviously the software can prevent saving the content by default).

According to Mozilla's official statement[0], it will not be open-source (it will be an open-source wrapper around the closed-source binary) There is still the question of the analog hole[1], but that's a separate matter (unrelated to open source vs. proprietary binary blob). [0] https://blog.mozilla.org/blog/2014/05/14/drm-and-the-challen... [1] https://en.wikipedia.org/wiki/Analog_hole

Nobody really uses the analog hole. It's actually easier to do it digitally, and will remain so, because securing a device against arbitrarily many attackers with physical access and arbitrarily large amounts of time and resources is a practical impossibility. The analog hole is just the formal proof that DRM can never be effective, because if you can see it or hear it you can record it.

Re: Reconciling Mozilla’s Mission and the W3C EME

#36

Post by bsmedberg »

makomk wrote: post #8
cwyers wrote: post #3

I understand Mozilla's philosophical objections to the EME, but if the alternative is Flash/Silverlight (and it's pretty clear that is, in fact, the alternative), I don't think Mozilla's mission loses out by implementing the EME.

In practice, so far the EME implementations that content providers have actually been willing to support have been far more tightly locked down than Flash or Silverlight. The Microsoft one supports hardware-level protected playback paths and unlike Silverlight no-one's managed to get it to run under Wine, and the Google one only runs on locked-down official Chromebook hardware which users can't run any non-Google pro…

The major DRM platform out there is Netflix on Silverlight, and it's not particularly locked-down at all.

Of course there are others, but they hardly matter at all in terms of marketshare.

Re: Reconciling Mozilla’s Mission and the W3C EME

#37

Post by mdeslaur »

nawitus wrote: post #7

>preventing users from saving the content How can an open source software prevent users from saving the content? If the CDM decrypts to plaintext, it should be trivial to modify the open source sandbox to save the plaintext data. (Obviously the software can prevent saving the content by default).

DRM is more about having leverage over the provider of the playback device and casual piracy than it is about protecting the content against hardcore piracy.

Re: Reconciling Mozilla’s Mission and the W3C EME

#38

Post by ds9 »

wmf wrote: post #24
abcd_f wrote: post #20

It is naive to expect that decrypted media stream will ever be leaving CDM module as so optimistically shown on that illustration. Microsoft dropped and neglected a bunch of great features when shipping Vista, but it went out of its way to drag Protected Media Path into it. PMP is fronting a major industry effort to create trusted software and hardware framework that on one end accepts encrypted stream and on other d…

It will be laughable to think that CDM won't be PMP-based. Even on Linux and OS X?

Edit: It's said to be a downloadable extra at user option.

The Moz page description of the sandbox says the CDM won't have any system access, so it could not distinguish whether PMP is there or not, except maybe by flags in the input from the browser. So either the Mozilla sandbox-CDM can't work as described or PMP won't be required.

Someone correct me if I've missed something there.

Re: Reconciling Mozilla’s Mission and the W3C EME

#39

Post by AnthonyMouse »

JoshTriplett wrote: post #32
AnthonyMouse wrote: post #27

Earlier quoted context omitted.

> Replacing unsandboxed plugin APIs like NPAPI that can directly access the OS with sandboxed plugin systems like NaCl and emscripten that support sandboxed native code seems like a major improvement. Until you want to write a plugin with a legitimate reason to directly access the OS.

Legitimate reasons to directly access the OS are typically "there isn't a browser API for this yet". We have multiple Open Source browsers now; submit a patch to one or more of them to add a new API, and ideally start working to standardize it. The result will be far better and more secure than a one-off custom plugin to pass through specific OS functionality.

If Firefox had an API that allowed you to do anything the OS allows you to do then there would be no sandbox. If it doesn't then there are things you can't do with the browser API that you could do with direct access to the OS.

Re: Reconciling Mozilla’s Mission and the W3C EME

#40

Post by ygjb »

davexunit wrote: post #34

>We have come to the point where Mozilla not implementing the W3C EME specification means that Firefox users have to switch to other browsers to watch content restricted by DRM. Then so be it. If Mozilla's mission is to improve and defend the "open" web, then EME should never have been considered for implementation. They shouldn't sacrifice their goals for the sake of market share.

Improving and defending the open web is not just about fighting the good fight on DRM. The Mozilla mission also calls for us to fight for users right to make choices[0] as well.

Mozilla could choose not to implement EME, and draw that line in the sand, but that means denying users the option of continuing to use Firefox to access content they choose to access.

My preference (both as a long time Firefox user, and a Mozillian) is to see Mozilla allow me to access content, and continue to support the Mozilla mission rather than switch to an alternate browser to access content[1].

[0] http://www.mozilla.org/en-US/about/manifesto/ [1] PS... you can argue that I shouldn't access encumbered content, but you are wasting your breath (or bits) ;)

Post reply on HN