Add-on File Registration System

Summary

Provide an add-on file registration system on AMO, where all known non-malicious add-on ids and file hashes are stored. Firefox will show a strong warning to users when unregistered files are being installed.

Details

Submission

• AMO will have a page where non-AMO add-on developers upload their add-on files in order to register them.
• The add-on ID will be linked to the account that uploaded the file, and no other accounts will be able to upload a file with the same ID (although we might want to allow multiple account ownership like with AMO add-ons).
• The service does a virus scan and malware analysis (check for known malware patterns like the Facebook add-ons). If successful, it registers the following data:
  • Add-on ID.
  • Add-on name.
  • Add-on version.
  • File hashes (there might be multiple hashes for a version because of platforms, distros, applications, etc.).
• When uploading, offer a code review by the Add-ons Review Team. On by default. -removed in add-ons work week

• Also offer the option to delete the file (but keep the hashes) as soon as possible (keep it for a minimum of, say, one week for security reasons). Off by default. -removed in add-ons work week

• All AMO add-on files are registered during submission (they should go through the same checks).
• An upload API should be provided to facilitate the work of very active developers. Upload limits should be established for this.
• Trusted developers would be allowed the option to submit file hashes without going through the upload process. -removed in add-ons work week

Installation

• When an add-on is being installed in Firefox, its ID, version number and hash will be sent to AMO.
• If they all match, the normal installation process continues.
• If there's no match, a strong warning is shown to the user. Something like This add-on hasn't been registered. Unregistered add-on can potentially be malicious and cause harm to your system, [* Don't Install] [I understand the Risk, Install Anyway].

Administration

• It's likely there are a number of malware flags that won't be sufficient to reject an add-on registration. For that, we need a dashboard where AMO admins monitor submissions and review their files if necessary.
• If a registered add-on is found to be malicious, all files will be immediately unregistered and the add-on blocklisted. The malware checks will be updated accordingly.
• AMO admins and developers should have the option to unregister any registered files. A reason for unregistering must be provided, so that the Add-ons Manager can communicate it to current users.

Overrides

• Firefox should include a preference that allows users to install unregistered files, using an add-on ID whitelist. When the preference is enabled, the warning page displays a checkbox allowing you to remove that warning for all future installed files for that add-on. This is necessary for developers, testers, etc.
• Alternatively, it might be more effective to have a command line switch developers can use to disable these checks. We could make Firefox prompt the user before loading, saying something like "Firefox is starting in Developer Mode, which can lead to malicious add-ons being run." and have a Start in Normal Mode button set as default as an additional protection.

Pros

• Malicious add-ons won't be able to use known ids without getting these warnings.
• Malicious add-on developers will have additional hurdles to pass before getting installed into user's profiles.
• Malicious add-on developers won't be able to use the most obvious ways to get users' attention, like calling their add-ons Flash Update.
• While still centralizing control on AMO, this is the path of least friction with developers. We won't require code reviews, source submissions, or waiting times.
• The registration process is easy and very quick.
• We will have much better information about existing add-ons, specially contact information to their maintainers.
• To sweeten the deal, we can offer add-on developers a statistics dashboard for their add-on, since we're already gathering that info.

Cons

• The automatic code inspection will be very shallow. This should be very effective for the majority of malware creators, but the most clever ones will be able to bypass it (specially if they're willing to go as far as using binary components or NPAPI plugins to hide their code).
• The system is proactive for known malware patterns, but reactive to new ones.
• Some developers will complain about having to register add-ons with us in order to continue developing. It's better for them than other alternatives, though. We need to make sure the service is well localized, scalable and available.
• This doesn't solve any problems related to add-on quality, though it helps us in terms of knowledge about existing add-ons and their developers.
• Registering the backlog of add-on files can be complicated. It shouldn't be too hard to do for AMO add-ons, but for non-AMO add-ons it can be trickier, since developers might not have access to old versions anymore. Old versions are less likely to be compatible with whatever version of Firefox will check for registered files, so this might not be a big deal.