1740744 - Set HTTPS-Only (currently read-only API)

Status: NEW

(WebExtensions :: General, enhancement, P5)

Description

[Andrea Marchesini [:baku]]

In general it would be better if we could also ensure to have UI in about:preferences that shows when the new browserSettings is controlled by an extension, but this can be done in a follow-up.

Comment 1

[Shane Caraveo (:mixedpuppy)]

UI in about:preferences

For a on/off setting, I don't think it is necessary. The extension preferences system catches those changes now, and the addon can listen for those changes.

Comment 2

[Rob Wu [:robwu]]

For reference, read-only was introduced in bug 1678306.

This bug is about supporting a writable version of the setting.

Comment 3

[Sebastian Streich [:sstreich]]

Attachment: Bug 1740744 - Make httpsOnlyMode writeable for web-ext r=robwu

Comment 4

[Shane Caraveo (:mixedpuppy)]

Noting past conversations that it is OK for an addon to "upgrade" this value, however we will not allow this value to "downgrade". IOW, an addon is allowed to turn on httpsOnlyMode, but it is not allowed to turn it off..

Comment 5

[Rob Wu [:robwu]]

The above is not easily enforceable and also too restrictive. I chatted with the team, and we ended up with the following design.

First, the intention here is to respect the user or application-set security setting, and to reject downgrades to avoid inadvertent security downgrades. Rejecting downgrades altogether as suggested in comment 4 is too restrictive, because it can result in functional regressions (i.e. http-only sites not working when https-only is enabled), that are not obvious to a user. Usually, disabling the responsible add-on recovers the setting, but if we were to reject downgrades altogether, then that would imply that uninstallation of an add-on wouldn't have any effect on the pref either.

So, to the design:

1. The BrowserSetting type supports the levelOfControl concept: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/types/BrowserSetting/get#return_value
   • currently supported values: not_controllable, controlled_by_other_extensions, controllable_by_this_extension, controlled_by_this_extension
   • getLevelOfControl is currently implemented internally at https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/toolkit/components/extensions/ExtensionSettingsStore.jsm#620-654 and https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/toolkit/components/extensions/ExtensionPreferencesManager.jsm#475-491
   • "control" is also described at https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webextensions/other.html#extensionpreferencesmanager
2. Extensions should only be able to seize control of the preference if it cannot undo an explicit upgrade request, i.e. if both are true:
   • Preference not controlled by another extension.
   • httpsOnlyMode is false
3. If an extension sets httpsOnlyMode from false to true, it seizes control. Other extensions cannot set it to false again.
   • The user may set it to false, which takes precedence over the extension's setting.
   • However, when an extension attempts to set it to true again, that should probably succeed (so that a user cannot accidentally lock themselves on a lesser-secure setting forever).
4. If an extension sets httpsOnlyMode from true to false (if permitted, see point 2), then the extension may relinquish control (in order to allow another extension to seize control again).
5. If an extension is uninstalled, httpsOnlyMode will only become false if the extension is in control, and it had set httpsOnlyMode to true.