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.

I seem to have double-submitted this bug. Bugzilla tried to warn me, but I wasn't quite sure what it was saying.