To support use cases such as bug 1523978, bug 1472308, and bug 1548973, Normandy should be able to make changes to Firefox that are not studies for the express purpose of fixing problems quickly. Previously we have misused the Study system of Normandy to achieve this, but this has never been a good tool for many reasons.

Hotfixes can be either changing a preference, or installing an extension. These hotfixes should have several high level properties. Hotfixes should be:

• Temporary - Like studies, hotfixes should only apply in the world as long as the recipe is active. Once we shut off the recipe, the hotfix should revert to its previous state.
• Resilient - Unlike studies, hotfixes may re-enroll a user in some cases. Being unenrolled once shouldn't necessarily prevent re-enrollment later. User opt-out should still be respected.
• Updateable - When the recipe defining the hotfix changes, clients should update their configuration to match the new definition.
• Privacy preserving - Users should not be required to have Telemetry or Studies enabled to receive hotfixes, and when Telemetry is disabled no data should be revealed by the hotfix.
• Monitorable - For users that have Telemetry enabled, we should get metrics about the installation and uninstallation of users into Hotfixes (whether manual or automatic), as well as diagnostics when they go wrong. This is vital to ensure that the hotfixes we send out are working as intended.
• User-accessible - Hotfixes need to be transparent to users. Users should be able to see a list of what hotfixes have applied to them, and optionally remove them. Users might also want to install hotfixes manually or see them even if they don't match the targeting criteria. Ideally we would be able to remotely manipulate hotfixes even if they've been installed manually, such as delivering updates.

(In reply to Michael Cooper [:mythmon] from comment #0)

• User-accessible - Hotfixes need to be transparent to users. Users should be able to see a list of what hotfixes have applied to them, and optionally remove them. Users might also want to install hotfixes manually or see them even if they don't match the targeting criteria. Ideally we would be able to remotely manipulate hotfixes even if they've been installed manually, such as delivering updates.

I'm not sure this is true. In general we don't make system add-ons (including hotfixes) user-configurable on the premise that they're parts of the browser, which just happen to be implemented as add-ons. In the case of hotfixes, they're just browser updates which happen to be shipped as add-ons. And we don't allow users to opt-out of only part of an update, or disable any other random parts of the browser (except occasionally by preferences).

There may be some hotfixes we may occasionally want to allow users to opt out of, but I don't think it should be the general rule.

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Normandy is being sunset so this is very unlikely to be worked on.