I think the goal of this feature should be to make it possible to automatically download "hotfix" extensions to Firefox to correct problems that would otherwise necessitate chemspills. I don't think we should constrain ourselves to the current simplest solution of shipping a dummy add-on with the release. I think this is a bad solution for the following reasons:
- We'd have to implement a mechanism for hiding this extension from users. Whatever mechanism we use would likely be exploitable by other add-ons unless we put a bunch of checks in place that would likely be complicated and expensive.
- Users would still be able to uninstall the extension by removing it from the filesystem
- Updates to the extension aren't controlled by the app update controls, it seems like we should only be downloading a hotfix if the user has agreed to automatic app updates
Instead I think we should implement a small new piece of code into Firefox:
Periodically the add-ons manager will ping an update URL to check for new versions of add-ons to install. If one is indicated to be available then it downloads and installs it.
This has the following benefits:
- The amount of code to implement this is trivial, it still reuses the add-ons manager code for update checks, downloads and installs. There is likely less new code here than there would be for hiding/checking the dummy add-on
- We could ship multiple hotfixes. While the update check would have to check for a specific ID, the downloaded add-on could have any unique ID allowing us to potentially install many hotfixes at the same time before the next update
- We could actively expose the hotfixes to the user as a new category in the add-ons manager if we wanted allowing users to remove hotfixes they didn't want
- We could do prompting after a hotfix is downloaded asking a user to restart unlike for other add-ons
- The code doing the automated ping could observe the app update prefs correctly, it could even be in the update service code if that made sense.
Mossop 14:53, 3 October 2011 (PDT)
One additional benefit is that with the dummy add-on if we just wanted to install a one-time fix like a pref change then we'd have to make the downloaded add-on more clever than it needs, prefs to make sure it only ran once etc. With the multi-hotfix case the add-on can just uninstall itself afterwards.
A disadvantage I've just realised is that we'd have to do something a little more to make sure Firefox didn't try to download the same hotfix over and over again.
Mossop 12:36, 4 October 2011 (PDT)
We should also consider not doing this with add-ons at all. Twice now we have found add-ons that have broken the add-ons manager in such a way that add-on updates fail. Because the app update service uses the add-ons manager both those add-ons also broke app update in some fashion. One of them even took out the blocklist service. Thankfully we found a way to resolve that but one suggestion is that in the event of a catastrophic failure of add-ons and app update systems maybe we should have an alternate so that we can attempt to deploy a hot fix that would get app update working again.
It carries more risk in that the code would be less well tested but it can also be quite simple to do what we want, perhaps just downloading a JS script and run it. Scary but no more scary than downloading an extension and running it.
Mossop 11:18, 7 October 2011 (PDT)