Reconciling Mozilla’s Mission and the W3C EME • Hacker News Board

Re: Reconciling Mozilla’s Mission and the W3C EME

#71

Post by nileshtrivedi » Wed, May 14, 2014, 7:51 PM UTC

shmerl wrote: post #64

Netflix is considered the main driver behind this DRM madness. In the context of Netflix, an often voiced reason for DRM is the fact that it rents movies, rather than sells them. Besides DRM being completely ineffective to prevent piracy, the concept of rentals itself doesn't make any sense for digital goods. The core logic behind a rental (for physical goods) is reusability. Physical goods have a fixed cost of produ…

> why would renting cost any different than buying?

So that you can segment the buyers into two: Those who want to see a movie only once and those who want to see it more than once. This way, you can double charge the second segment and use those funds to reduce the price for the first segment. Classic market segmentation.

As long as there are customers of both kind, rentals (even for digital goods) will make sense.

Re: Reconciling Mozilla’s Mission and the W3C EME

#72

Post by jaxytee » Wed, May 14, 2014, 7:52 PM UTC

shmerl wrote: post #64

Netflix is considered the main driver behind this DRM madness. In the context of Netflix, an often voiced reason for DRM is the fact that it rents movies, rather than sells them. Besides DRM being completely ineffective to prevent piracy, the concept of rentals itself doesn't make any sense for digital goods. The core logic behind a rental (for physical goods) is reusability. Physical goods have a fixed cost of produ…

>There is completely no need to prevent users from retaining a copy once they watched it.

For Netflix there's one big reason to: PROFIT

Re: Reconciling Mozilla’s Mission and the W3C EME

#73

Post by fiatmoney » Wed, May 14, 2014, 7:52 PM UTC

It's very important that users be able to disable ALL of this functionality with a simple compiler flag. Not just disabling it in the process.

We've seen the failure of "sandboxing" over and over again, and especially with a closed-source, certain-to-be-compromised payload, it's guaranteed that at some point it will be breached.

Re: Reconciling Mozilla’s Mission and the W3C EME

#74

Post by ibotty » Wed, May 14, 2014, 7:53 PM UTC

fiatmoney wrote: post #73

It's very important that users be able to disable ALL of this functionality with a simple compiler flag. Not just disabling it in the process. We've seen the failure of "sandboxing" over and over again, and especially with a closed-source, certain-to-be-compromised payload, it's guaranteed that at some point it will be breached.

did you read the blog post? you have to actively consent in installing that plugin to use it. without plugin the sandbox is code without attack surface.

Re: Reconciling Mozilla’s Mission and the W3C EME

#75

Post by shmerl » Wed, May 14, 2014, 7:54 PM UTC

nileshtrivedi wrote: post #71

shmerl wrote: post #64

Netflix is considered the main driver behind this DRM madness. In the context of Netflix, an often voiced reason for DRM is the fact that it rents movies, rather than sells them. Besides DRM being completely ineffective to prevent piracy, the concept of rentals itself doesn't make any sense for digital goods. The core logic behind a rental (for physical goods) is reusability. Physical goods have a fixed cost of produ…

> why would renting cost any different than buying? So that you can segment the buyers into two: Those who want to see a movie only once and those who want to see it more than once. This way, you can double charge the second segment and use those funds to reduce the price for the first segment. Classic market segmentation. As long as there are customers of both kind, rentals (even for digital goods) will make sense.

No, it doesn't. My point is there is no need for such segmenting and overcharging those who want to see it more than once (except greed). Because there is no big difference in expenses for the distributor between these two use cases, except for the fact that the second can use the service more. But they already charge the monthly fee.

Anyway, it's not even the case here! Netflix has no plans for purchasing, so there is no segmenting there at all.

Re: Reconciling Mozilla’s Mission and the W3C EME

#76

Post by shmerl » Wed, May 14, 2014, 7:57 PM UTC

jaxytee wrote: post #72

shmerl wrote: post #64

Netflix is considered the main driver behind this DRM madness. In the context of Netflix, an often voiced reason for DRM is the fact that it rents movies, rather than sells them. Besides DRM being completely ineffective to prevent piracy, the concept of rentals itself doesn't make any sense for digital goods. The core logic behind a rental (for physical goods) is reusability. Physical goods have a fixed cost of produ…

>There is completely no need to prevent users from retaining a copy once they watched it. For Netflix there's one big reason to: PROFIT

What profit? Netflix offers rentals only, and no sales. And Netflix DRM doesn't prevent any piracy since users who want to illegally retain the copy can do it either way. So what is the reason for them using it? They can simply use sales and have the same profit.

Re: Reconciling Mozilla’s Mission and the W3C EME

#77

Post by oscargrouch » Wed, May 14, 2014, 7:59 PM UTC

All the system is rot from the bottom up.. The Honcho's (tm) are putting their dirty hands and corrupting all over .. even the things we take for granted as community driven and serving for a greater good

Dont use Netflix, Dont support DRM, fight for DRM free software..

We took millions of years to make copy and cloning of any information free(as in freedom and in beer) and now some bastards want to turn this into a crime just because they want to profit?

Its just the beggining of something really bad that can corrupt all of the good things we take for granted now, as free education, knowledge sharing and the free flow of information

Re: Reconciling Mozilla’s Mission and the W3C EME

#78

Post by rasz_pl » Wed, May 14, 2014, 8:05 PM UTC

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.

Alternative is TPB

Re: Reconciling Mozilla’s Mission and the W3C EME

#79

Post by MacsHeadroom » Wed, May 14, 2014, 8:06 PM UTC

jamesgeck0 wrote: post #51

davexunit wrote: post #47

Earlier quoted context omitted.

Sure, the user may want to access DRM-encumbered content, but we shouldn't promote such a thing. You're not denying the users anything by refusing to implement EME, the media companies are denying the users freedom by insisting on using malware to deliver content! Just because users want Netflix in Firefox doesn't mean that it's the right thing to provide.

Is supporting a EME the same thing as promoting it?

One does not preclude the other, no.

Re: Reconciling Mozilla’s Mission and the W3C EME

#80

Post by fiatmoney » Wed, May 14, 2014, 8:06 PM UTC

ibotty wrote: post #74

fiatmoney wrote: post #73

It's very important that users be able to disable ALL of this functionality with a simple compiler flag. Not just disabling it in the process. We've seen the failure of "sandboxing" over and over again, and especially with a closed-source, certain-to-be-compromised payload, it's guaranteed that at some point it will be breached.

did you read the blog post? you have to actively consent in installing that plugin to use it. without plugin the sandbox is code without attack surface.

It's unclear to me from the post that the sandbox code will be unbundled from Firefox. Furthermore, it should be possible to distribute a compiled version of Firefox that doesn't have the ability to install the module in the first place, with a minimum of effort.

If you don't enable it by default, but the first time a user visits any website with a video ad they get a clickthrough that downloads and installs it, a huge portion of the user base will end up with it installed. This is less than desirable if you care about security.

I'm sure security- or ideological-focused distros will do a version of this anyway, but it should be supported upstream to segment the code as much as possible so as few vulnerabilities leak into the "main" codebase as possible.