We are looking into removing the `app.update.enabled` pref, and replacing that functionality with the DisableAppUpdate and DisableSystemAddonUpdate policies. This would make it necessary to enable these policies outside of ESR builds.

How we will prevent malware/adware from turning off the update preferences?

Currently this is controlled by prefs, meaning that they can be changed by editing a file stored by default in the user's home directory, or the default preferences file in the Firefox installation directory. Policies are controlled by a file in the installation directory or by registry entries in HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER. The permissions to edit the user's home directory are the same as those to edit HKEY_CURRENT_USER. The permissions to edit the installation directory are the same as those to edit HKEY_LOCAL_MACHINE. Please correct me if I am wrong, but there does not seem to be any degradation of security here.

Well now you bring up the question of why we made any pref based policies ESR only in the first place :). I think the core difference here is that if malware modifies the user's preferences, the user can undo it. We don't want to end up in a situation where malware modifies things and there's nothing the user can do to fix it. As far as the policies in registry go, we don't allow these policies in the registry on rapid release so it's not an issue. I honestly don't know the right answer here. Are we going to allow users to turn off updates at all? And if so, how would they do it?

(In reply to Mike Kaply [:mkaply] from comment #3) > Well now you bring up the question of why we made any pref based policies > ESR only in the first place :). > > I think the core difference here is that if malware modifies the user's > preferences, the user can undo it. Hey Mike, we need to move the update switches somewhere global no matter what. For Windows this info can go in the registry or in the install directory as a file. Something in the install directory is preferred because it will usually require elevation to access. We kicked around the idea of using the now deprecated application.ini as a fall back for power users, but determined there's no major difference between this approach and the enterprise config json file. Open question is do we plan to keep that json file.. because power users might start relying on it for this. Lets plan to discuss at tomorrow's enterprise meeting.

> Hey Mike, we need to move the update switches somewhere global no matter what. For Windows this info can go in the registry or in the install directory as a file. Something in the install directory is preferred because it will usually require elevation to access. How are we going to allow disabling updates for specific versions of Firefox? OR will it be a global switch? FYI - I found this document on how Chrome does it. https://support.google.com/chrome/a/answer/7550274?hl=en > Lets plan to discuss at tomorrow's enterprise meeting. sounds like a plan.

(In reply to Mike Kaply [:mkaply] from comment #5) > > Hey Mike, we need to move the update switches somewhere global no matter what. For Windows this info can go in the registry or in the install directory as a file. Something in the install directory is preferred because it will usually require elevation to access. > > How are we going to allow disabling updates for specific versions of > Firefox? OR will it be a global switch? The new controls are per install, with eacnh install having it's own setting and update mechanism. > FYI - I found this document on how Chrome does it. > > https://support.google.com/chrome/a/answer/7550274?hl=en Sounds like they recommend using enterprise settings? We're taking the same approach or close AFAICT - config enterprise json to disable updates and drop it into the install folder.

From an IRC conversation, I'll hold off on this review for a couple of days, to see if we can get bug 1463895 first, and directly change enterprise_only -> machine_only, instead of having a middle step where there are no restrictions on these policies.

Comment on attachment 8979720 [details] Bug 1460082 - Allow DisableAppUpdate and DisableSystemAddonUpdate policies outside of the ESR https://reviewboard.mozilla.org/r/245876/#review257776 Hey Kirk, bug 1463895 has landed. Whenever you need this, just update the patch to use machine_only and I'll r+ it

Comment on attachment 8979720 [details] Bug 1460082 - Allow DisableAppUpdate and DisableSystemAddonUpdate policies outside of the ESR https://reviewboard.mozilla.org/r/245876/#review258542

Comment on attachment 8979720 [details] Bug 1460082 - Allow DisableAppUpdate and DisableSystemAddonUpdate policies outside of the ESR LGTM. Please open an issue in github to update the templates.

Issue filed: https://github.com/mozilla/policy-templates/issues/178

Pushed by ksteuber@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3938774c664b Allow DisableAppUpdate and DisableSystemAddonUpdate policies outside of the ESR r=Felipe

Is this ok to ride the train with 63? Or is it something you're aiming to get into the 62 release?

> Is this ok to ride the train with 63? Or is it something you're aiming to get into the 62 release? 62 release. Targeting a lot of policy stuff for that release.

Comment on attachment 8979720 [details] Bug 1460082 - Allow DisableAppUpdate and DisableSystemAddonUpdate policies outside of the ESR Approval Request Comment [Feature/Bug causing the regression]: Move update policies to machine [User impact if declined]: Unable to turn off update at all on rapid release [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: Yes [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: Non [Is the change risky?]: Very low [Why is the change risky/not risky?]: Only affects policies. [String changes made/needed]:

Comment on attachment 8979720 [details] Bug 1460082 - Allow DisableAppUpdate and DisableSystemAddonUpdate policies outside of the ESR I believe you, but where did the verification in Nightly happen? Let's uplift for beta 5.

This bug was covered by the overall testing efforts invested in the New Enterprise Policies feature. Marking this as verified fixed using Firefox 62.0b16 (BuildId:20180809104529) and Firefox 63.0a1(BuildId:20180813220525) on Windows 10 64bit and macOS 10.13.4