1144903 - [EME] EME-free repack based on Firefox

Status: RESOLVED FIXED

(Release Engineering :: Release Requests, defect, P1)

Description

[Javaun Moradi [:javaun]]

We have a requirement to offer a DRM-free Firefox for those users who oppose DRM and choose that option. The bar to clear is:
1. a pure, untouched Firefox where no CDM binaries have been downloaded or ever will. 
2. That we can repatriate these users back to the mainline GA version, maintaining their "EME/DRM is totally off" status, if at a future time mainline Fx be able to meet this "totally DRM free" bar in the future. 

We are shipping EME in 38, and CDMs will download automatically, so the solution needs to turn this off, block all CDM downloads before they ever happen, and turn off any UI options to turn it back on. 

The approach we've settled on is a partner repack, with downloader and UI elements pref'ed off.

Comment 1

[Javaun Moradi [:javaun]]

Stephen, I believe we're dependent on bug 1140263 landing so that you can pref things off. Can you specify the work that needs to precede the repack, including any patches and the prefs to turn off to disable CDM download as well as the Add-on manager UI?

Dolske: can you specify all prefs to hide all EME UI and also to opt-out of EME (i.e "Play DRM" is off).

Comment 2

[Javaun Moradi [:javaun]]

Our ideal is to use Fx 38 for the repack, and this assumption is based on us being able to do everything in prefs. We are not entertaining and code changes/separate build. If this is not the case, we consider doing the repack off of ESR 31

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

How disabled do you want it to be? Preffed off, or completely absent? We can use 'ac_add_options --disable-eme' if you want EME to not even be compiled into Firefox. That would mean that users could not chose to re-enable it later however, they'd need to install a new build with EME to get EME.

Comment 5

[Stephen A Pohl [:spohl]]

(In reply to Javaun Moradi [:javaun] from comment #1)
> Stephen, I believe we're dependent on bug 1140263 landing so that you can
> pref things off. Can you specify the work that needs to precede the repack,
> including any patches and the prefs to turn off to disable CDM download as
> well as the Add-on manager UI?

I'd like to uplift bug 1140522 and bug 1140523 which have already landed on trunk. As you stated, I will also need to land and uplift bug 1140263 once it has been reviewed. Once this is done, we will need to set "media.eme.enabled" to false for the partner repack. This will disable the downloader as well as any related UI in the addons manager.

Comment 6

[Chris AtLee [:catlee]]

(In reply to Chris Pearce (:cpearce) from comment #4)
> How disabled do you want it to be? Preffed off, or completely absent? We can
> use 'ac_add_options --disable-eme' if you want EME to not even be compiled
> into Firefox. That would mean that users could not chose to re-enable it
> later however, they'd need to install a new build with EME to get EME.

We don't want to have to do a separate build for this. A pref which prevents them downloading the CDM bits on startup is fine.

Comment 7

[Javaun Moradi [:javaun]]

What Chris AtLee said, strictly prefs. We've engineered such that we can disable the CDM download mechanism, prevent DRM binaries from ever hitting the browser, turn off all UI elements, and turn off the switch to turn it back on (UI pref) without forking our codebase. That's better for sustainable maintenance and better for users. Users could theoretically go into into about:config and turn it back on by flipping several prefs, but they can do *all kinds* of damage if they lift the hood and start messing with the engine.

Comment 8

[Justin Dolske [:Dolske]]

I'm a little sad that we're doing this, because I worry that it creates a weird message about there being a good and bad version of Firefox. And that we're maybe overreacting, preemptively, by offering a whole new download for something that's just a pref flip. But OK.

I think the 2 relevant prefs to change are:

  browser.eme.ui.enabled
  media.eme.enabled

It would be good to make sure that we're doing the right thing if someone has regular Firefox installed (with a CDM that has already downloaded), hears about the "DRM-free" version, and installs it over their existing install... Are we expected to notice on startup that the prefs changed and uninstall CDM bits? Or until we're able to actually uninstall, how do those CDMs show up in the addon manager?


There's also the edge case of how our preferences work -- we only store *changed* prefs in the user's profile. So prefs can end up resetting when switching between builds with different default settings. For example, consider the following sequence:

  0) Regular Firefox install, EME prefs are default so nothing in the profile's prefs.js.
  1) User explicitly disables EME. We stores media.eme.enabled=false in the profile's prefs.js.
  2) User installs EME-free Firefox and runs it. Because the default is now false, the next write of
     prefs.js will no longer contain media.eme.enabled=false because it would needlessly duplicate the
     app's default setting.
  3) User installs regular Firefox again. EME is enabled by default, and there's no longer a different
     value in the profile's prefs.js.
  4) DRM is enabled and CDMs download and install.

This occasionally bites people switching between Nightly and Release (when some pref is different between channels, and the user changes it). And a similar issue came up when we changed the default search engine to Yahoo (see bug 1121252 comment 5). Users can perceive it as us deliberately changing their choice, where it's really just a weird side effect of how the prefs system works.

I don't think it's likely to be a common problem, but wanted to call it out.

Although it does mean we should think carefully about how the "repatriation to mainline" will work because that could easily cause the same thing. (Do we know when that's likely to happen?)

Comment 9

[Stephen A Pohl [:spohl]]

(In reply to Justin Dolske [:Dolske] from comment #8)
> It would be good to make sure that we're doing the right thing if someone
> has regular Firefox installed (with a CDM that has already downloaded),
> hears about the "DRM-free" version, and installs it over their existing
> install... Are we expected to notice on startup that the prefs changed and
> uninstall CDM bits? Or until we're able to actually uninstall, how do those
> CDMs show up in the addon manager?

We are unable to uninstall CDMs at this time (or we probably wouldn't be doing this repack in the first place). However, once bug 1140263 lands (which is expected to make it into this EME-free repack), all CDMs will be hidden in the addons manager when "media.eme.enabled" is set to false. To be clear, they will remain on disk but will not be shown in the addons manager and no future updates will be applied as long as the pref remains set to false.

Comment 10

[Robert Kaiser]

(In reply to Stephen Pohl [:spohl] from comment #9)
> We are unable to uninstall CDMs at this time (or we probably wouldn't be
> doing this repack in the first place). However, once bug 1140263 lands
> (which is expected to make it into this EME-free repack), all CDMs will be
> hidden in the addons manager when "media.eme.enabled" is set to false. To be
> clear, they will remain on disk but will not be shown in the addons manager
> and no future updates will be applied as long as the pref remains set to
> false.

Hmm, that makes me fear that some extreme freedom advocates (of the likes of Stallman) will tout out that "Mozilla lies, they put unethical binary DRM bits on your disk and then hide that fact" (unfortunately, the "unethical" is not my creation but Stallman's, he called out Mozilla as having "no ethics at all" just because we implement EME).

Comment 11

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment 0 has the requirements. A DRM free version of Firefox. Dolske does raise some interesting questions in comment 8. We should ensure that we know what will happen if you use an existing profile that is both <38 or >=38.

Comment 12

[Lawrence Mandel [:lmandel] (use needinfo)]

Tracking for 38 as this is a requirement for the release.

Comment 13

[Javaun Moradi [:javaun]]

NI'ing Chris and Coop. Stephen and Dolske flagged the needed prefs. Do we need to do anything else to make the DRM-free repack happen? Thanks, J

Comment 14

[Chris AtLee [:catlee]]

It's my understanding that we're going to have EME enabled for 38 at all, is that correct?

In any case, to create this DRM-free repack, we need to add this as a "partner" in this repository:
http://hg.mozilla.org/build/partner-repacks

Comment 15

[Chris Cooper [:coop] (he/him)]

(In reply to Chris AtLee [:catlee] from comment #14) 
> In any case, to create this DRM-free repack, we need to add this as a
> "partner" in this repository:
> http://hg.mozilla.org/build/partner-repacks

I can whip up the partner repack patch pretty easily. Given that this bug isn't private, I'm going to assume it's OK for me to publish that config to the repo.

Comment 16

[Henri Sivonen (:hsivonen)]

(In reply to Justin Dolske [:Dolske] from comment #8)
> I'm a little sad that we're doing this, because I worry that it creates a
> weird message about there being a good and bad version of Firefox. And that
> we're maybe overreacting, preemptively, by offering a whole new download for
> something that's just a pref flip.

I also think that offering a repack like this is an overreaction. Furthermore, I think instead of soothing concerns of the constituency that's opposed to Firefox integrating with a DRM plug-in, I think offering such a repack can make the concerns worse due to the optics.

Doing something as drastic-looking as offering different builds (from the outside, the distinction between builds and repacks is probably lost) makes it look like Mozilla thinks that the DRM integration is super-bad to merit such a drastic-looking measure to be available. I think offering different downloads will lead to no end of narratives of the sort "Mozilla's DRM integration is true evil! Even Mozilla itself thinks their DRM integration is so terrible that they feel it's necessary to provide different builds without it!" and there's no way us to counter that narrative by pointing out that this is really just about pre-flipping a pref so that people who are super-opposed to even briefly have a DRM DLL/dylib/so start downloading can prevent the download from even starting when with a normal build the download would likely start before the user can reach the pref to turn the downloads off, but user would have that opportunity before the code ever *runs*.

Moreover, I think it's a bad idea to offer this kind of alternative version without turning off NPAPI in that version, too. If people who download the alternative version are not sufficiently clued to realize that Flash and Silverlight contain similar (in the case of Flash, the same!) DRM and the users actually want to use services that DRM in Flash or Silverlight enabled without realized that that's what's going on, we'll end up self-sabotaging our opportunities to migrate off NPAPI.

Additionally, I think bug 1136707 makes this strategically even worse. The current implementation of the pref turns off *EME* instead of just turning off *EME-based DRM*. That is, the EME API and the non-DRM Clear Key CDM are turned off also instead of just turning off the Adobe CDM. If you want to persuade streaming providers not to use *DRM*, it's probably easier to persuade them to move to Clear Key, which is Free Software-implementable non-DRM encryption, which is technically equivalent to HLS with keys in the clear, which is already familiar to the providers and makes stream ripping with curl or wget take more effort, than to persuade them to drop media file-level encryption completely as the first step. In that sense, having the anti-DRM constituency use a browser that doesn't have Clear Key makes it harder to get streaming providers to make a shift off-DRM, which is presumably what the anti-DRM constituency wants!

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #11)
> Comment 0 has the requirements. A DRM free version of Firefox.

When the requirement was formulated, was the issue of offering separate downloadables giving the impression that the default downloadables are more terrible than they actually are planned to be addressed? How?

Comment 17

[Chris Cooper [:coop] (he/him)]

(In reply to Chris Cooper [:coop] from comment #15)
> I can whip up the partner repack patch pretty easily. Given that this bug
> isn't private, I'm going to assume it's OK for me to publish that config to
> the repo.

First stab at repacks are here:

http://people.mozilla.org/~coop/partner_repacks/EME-free/

Comment 18

[Chris Cooper [:coop] (he/him)]

Attachment: [partner-repacks] Add EME-free repack

(In reply to Chris Cooper [:coop] from comment #17) 
> First stab at repacks are here:
> 
> http://people.mozilla.org/~coop/partner_repacks/EME-free/

...as generated by this patch.

Comment 19

[Chris Cooper [:coop] (he/him)]

(In reply to Chris Cooper [:coop] from comment #17)
> (In reply to Chris Cooper [:coop] from comment #15)
> > I can whip up the partner repack patch pretty easily. Given that this bug
> > isn't private, I'm going to assume it's OK for me to publish that config to
> > the repo.
> 
> First stab at repacks are here:
> 
> http://people.mozilla.org/~coop/partner_repacks/EME-free/

Javaun: these builds are based on 37.0b7. Do we want someone to QA these, or should we wait until next week when we'll have 38.0b1 to work with?

Comment 20

[Javaun Moradi [:javaun]]

We can wait to 38.0b1 to QA.

Comment 21

[Chris Cooper [:coop] (he/him)]

(In reply to Javaun Moradi [:javaun] from comment #20)
> We can wait to 38.0b1 to QA.

New repacks based on 38.0b1 are here for QA:

http://people.mozilla.org/~coop/partner_repacks/EME-free/38.0b1/

Comment 22

[Sylvestre Ledru [:Sylvestre]]

Sorry if the question has been answered somewhere else but where this binaries will be available?
Are we going to communicate on this?
Will it be available from the download page?
Thanks

Comment 23

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Sylvestre Ledru [:sylvestre] from comment #22)
> Sorry if the question has been answered somewhere else but where this
> binaries will be available?
> Are we going to communicate on this?
> Will it be available from the download page?
> Thanks

ni? Javaun to answer this...

Comment 24

[Javaun Moradi [:javaun]]

I'm still working on this one, probably won't know until later in the week. I can say that we won't put this on the downloads page, only a small percentage of the savviest of users understand what DRM is. The average user doesn't understand what DRM or EME means. If they downloaded the DRM-disabled repack and tried to watch protected content, they might reasonably believe their browser was broken and leave Firefox.

Comment 25

[Chris Cooper [:coop] (he/him)]

I have new builds up with the latest requested prefs:

http://people.mozilla.org/~coop/partner_repacks/EME-free/38.0b6/

Comment 26

[Javaun Moradi [:javaun]]

Thanks Coop. To formally update the ticket, the one pref to turn back on is:

   browser.eme.ui.enabled 

We are able to turn back on the minimal UI that shows the UI pref because of overall advances on frontend. This means we still have a repack that is DRM free, no CDM downloads nor ever will, but a user who gets that version by accident won't think their browser is broken. Better user experience.

Comment 27

[Chris Cooper [:coop] (he/him)]

Attachment: [partner-repacks] Add EME-free repack, v2

Here's the latest config. We're not sure about the final list of locales, but there's a non-zero chance that it will be en-US only. I'd like to get this basic patch landed so if we do go en-US-only, we don't have any one-off repack work to do (for EME) during release week.

Comment 28

[Chris Cooper [:coop] (he/him)]

Comment on attachment 8600426 [details] [diff] [review]
[partner-repacks] Add EME-free repack, v2

Review of attachment 8600426 [details] [diff] [review]:
-----------------------------------------------------------------

https://hg.mozilla.org/build/partner-repacks/rev/96f174945da8

Comment 29

[Chris Cooper [:coop] (he/him)]

Working with all shipped locales on just the win32 platform, we generated 3.3GB worth of repacks. It took about 45 minutes.

Comment 30

[Chris Cooper [:coop] (he/him)]

New RC repacks are in the canonical place:

http://stage.mozilla.org/pub/mozilla.org/firefox/candidates/38.0-candidates/build2/partner-repacks/EME-free/

Comment 31

[Javaun Moradi [:javaun]]

Catlee, Coop, Cpeterson and I spoke today. We will do win32 repacks for all locales. This gives full coverage across locales. We will not do repacks for Win64, OSX, or Linux at this time, since we are not launching on those platforms. We explicitly hide the EME UI pref in other (non- win32) platforms for Fx38  and the repack reveals it.

Comment 32

[Chris Cooper [:coop] (he/him)]

Attachment: [partner-repacks] All locales on win-32 only

(In reply to Javaun Moradi [:javaun] from comment #31)
> Catlee, Coop, Cpeterson and I spoke today. We will do win32 repacks for all
> locales. This gives full coverage across locales. We will not do repacks for
> Win64, OSX, or Linux at this time, since we are not launching on those
> platforms. We explicitly hide the EME UI pref in other (non- win32)
> platforms for Fx38  and the repack reveals it.

This patch implements these changes agreed upon at the mtg yesterday. ^^

The list of locales was taken from shipped-locales on m-r.

Comment 33

[Chris Cooper [:coop] (he/him)]

Comment on attachment 8601594 [details] [diff] [review]
[partner-repacks] All locales on win-32 only

Review of attachment 8601594 [details] [diff] [review]:
-----------------------------------------------------------------

https://hg.mozilla.org/build/partner-repacks/rev/b7f790d166ba

Comment 34

[Ada [:adalucinet]]

Tested EME - free repack build via http://stage.mozilla.org/pub/mozilla.org/firefox/candidates/38.0-candidates/build2/partner-repacks/EME-free/ under Windows 7 32 bit and Windows Vista 32 bit;

Partial testing results: 
* media.eme.enabled is properly set to false, while 'browser.eme.ui.enabled' is set to true and Play DRM checkbox is available via Options -> Content tab on both platforms;
* also, EME is disabled when launching the build with a remote profile with EME enabled, a profile < 38 and one > 38;
* when I follow the below steps, I hit the edge case Justin mentioned in comment 8:
1. Install latest 40.0a1 & wait for the plugin to download.
2. Disable the plugin.
3. Install EME free build in the same folder (as in step 1)
4. Re-install latest 40.0a1
Actual results: EME is not enabled by default: Play DRM not enabled and the plugin is not downloaded; 'media.eme.enabled' not present in prefs.js; 'media.eme.enabled' is false in about:config
Also, at step 3, 'media.eme.enabled' = false is still displayed in the profile's prefs.js file on Vista for about 30 seconds; it works as expected after the pref vanishes.

Any ideas on the above issues? Thanks in advance!

Comment 35

[Justin Dolske [:Dolske]]

I'm not sure what you're asking. The edge case described in comment 8 wasn't fixed, so if you're encountering that it's expected.

Comment 36

[Ada [:adalucinet]]

(In reply to Justin Dolske [:Dolske] from comment #35)
> I'm not sure what you're asking. The edge case described in comment 8 wasn't
> fixed, so if you're encountering that it's expected.

Logged bug 1164858 just to have it tracked. No other new issues encountered during testing.

Comment 37

[Chris Pearce [:cpearce (Not reading bugmail)]]

Let's declare victory and close this bug then.