User:Jorge.villalobos/WorkWeek2012Q2

From MozillaWiki
Jump to: navigation, search

Improving our Response to Add-on Problems

Problems

Add-on Security

  1. Add-on ids can be easily replicated to bypass blocklisting. Our only way to identify add-ons is using their ids. We use them to get metadata, collect stats and add them to the blocklist. Today, the worst potential problem we face is a viral malicious add-on that uses the same id of a very popular add-on. This hasn't happened yet, as far as we know.
  2. Malicious add-ons are being distributed through Facebook and video sites repeatedly. About 35 malicious add-ons have been blocklisted so far this year. They all follow the same pattern: they are disguised as a Flash or DivX update, or something else people want (free Cheesecake Factory dinner) and when installed they insert malicious code into Facebook or other sites. A couple of keyloggers have been submitted to AMO also. They are all copies of malicious code posted in a blog post some time ago. Creating and distributing these add-ons is cheap and easy, and they don't show any sign of stopping.

Blocklisting

  1. The blocklist system isn't designed as an effective warning system. Blocklisting is now limited to critical cases because its user interface is too severe-looking and doesn't give users enough information or alternatives.
  2. The blocklist system doesn't give users ways to act and resolve the problem. It doesn't look for fixed updates or direct users to the right place to seek help (the block page is sometimes not the right place to send people).
  3. The blocklist can be easily subverted by malicious add-ons.

Add-on Quality

  1. Many add-ons that are not hosted on AMO have very poor quality. Crashes, memory leaks, poor performance are reported frequently for many of them.
  2. We have almost no tools to diagnose add-on impact in Firefox performance. It's difficult for us to diagnose problems, and much more difficult for the affected users.
  3. We don't have an effective way to communicate quality problems in add-ons.
  4. Old versions of the SDK are constantly being deprecated and quality problems are found in them. A quality problem in the SDK affects dozens or hundreds or add-ons, and most developers don't expect a need to update the SDK frequently.

Add-on Installation

  1. The foreign-installed add-on1 confirmation screen might not be sufficient to inform users. We have no data about the effectiveness of the Firefox 8 mass add-on opt-in. Do we have data about the confirmation screen?
  2. At least one installer (Ask.com) is modifying the foreign-installed confirmation screen to encourage users to accept.
  3. Many users install foreign-installed add-ons unknowingly and have problems uninstalling them. Many cases may be users clicking through installation wizards without paying attention, or users who share computers with others.
  4. Users forget which add-ons they have installed and just accumulate them.

1Foreign-installed add-ons: add-ons that are installed by external applications.

Communication

  1. We don't provide enough documentation about doing things The Right Way™.
  2. Public communications about major add-ons can damage our relationship with business partners.

Possible Solutions

Add-on Security

There are two approaches that can be taken here. We can either implement Add-on File Registration and non-compulsory Add-on Signatures, or just compulsory Add-on Signatures. I recommend the first approach because it's more likely to be accepted by the developer community, and it is less technically and logistically challenging.

Blocklisting

  • The blocklist should be hardened by moving it to a separate process. I think this can be done relatively easily on Windows because of the changes done for Silent Update. It should be still be possible to configure it, but not with Firefox preferences that can be easily changed by extensions.
    • How it ultimately interacts with the Add-ons Manager is still a vulnerable area, though.
  • Change the refresh rate to twice a day to improve its effectiveness.
  • When faced with a blocked add-on, the Add-ons Manager should look for suitable upgrades or even downgrades in order to avoid the block.
    • This requires a better plugin update mechanism on our side. The plugin check page isn't good enough.
  • We need a warning system that may or may not be part of the blocklist system.
    • Different warning levels (low, medium, high). The different levels would determine if they should only show up in the Add-ons Manager, show up in a notification bar, or display a more urgent popup.
    • Different reasons. Since we want the messages to be localized, we need some predetermined warning reasons, like Performance, Security, Stability, Privacy.
    • It should be possible to link to a more detailed article about the problem.
    • This will significantly improve our ability to deal with quality problems in add-ons. We want to avoid user fatigue (too many warnings), but it should significantly lower the bar for dealing with bad situations.

Add-on Quality

  • The solutions proposed in the Add-on Security address some of this, by offering (or mandating) code reviews for non-AMO developers.
  • We need to have a performance tracking page in Firefox (about:performance, maybe?), showing graphs of known metrics (startup time, memory consumption) through time, with markers showing when add-ons were installed/uninstalled/enabled/disabled, and other useful info (tab/window count? visited sites?). If and when poor performance is detected, users should be prompted to review this page.
  • We need to come up with a regular, continuous test plan for top add-ons. It should be something like regular testdays, where one or more members of the Review Team help QA and volunteer testers review the most commonly used add-ons (and maybe other randomly chosen ones).
  • Better documentation. Many poor practices out there exist because there are no published alternatives, or they were copied from poor published alternatives. We need to better understand why developers chose to do things a certain way instead of the one that seems logical to us.
  • bug 751466 is tracking updating add-ons that use older versions of the SDK. Many developers have been contacted directly already. However, the long term solution to this problem (integrating the SDK into Firefox) should happen ASAP.

Add-on Installation

  • Add-on installation needs to be simplified and renewed so that users don't get so used to ignoring installation prompts. bug 643020 started this work in the right direction.
  • Revisit the foreign-installed add-on screen. It might not be giving users enough information to act. It should also acknowledge that some installers are overlaying information over it.
  • We need to decide (again) what's the approved way to install add-ons externally. Our current recommendation is to add them using the registry. This only works on Windows, can install add-ons before Firefox is installed, and installs them in a way that can't be removed from the Add-ons Manager. The easier and more widely published this is, the less likely are developers from using different methods.
  • It should always be possible to remove an add-on from a profile. The only possible exception are enterprise-like deployments. In this case, it should be possible for them to set a system-wide preference instead of profile-specific. Any profile-specific solution is vulnerable to other add-ons.
  • Users should be reminded about the add-ons they have installed. Maybe in about:home, or just displaying an Add-on count in the menu could help. Prompting might be too much, but should be considered.
  • In order to give users more data, users should be able to rate any add-on anonymously from the Add-ons Manager, which should be presented on install and in the Add-ons Manager. We might need to have a public page to display some basic data, user reviews, a Report Abuse link like on AMO, but no download links.

Communication

  • See Add-on Quality and Add-on Installation for specific areas where documentation is lacking. We should have an add-ons landing page aimed for non-AMO developers that groups all the information that is specially useful for them.
  • Communicate inside Mozilla what are the appropriate ways to deal with add-on problems (file a bug, ping us, etc.). We might want to open up the marketplace-abuse mailing list for anyone in the staff to report problems.
  • We need closer communication between the Add-ons Team and SUMO. Should we have a regular meeting? A dashboard for the Add-ons team? We need to be aware or top and trending problems related to add-ons.

Sources and Related Discussions and Bugs

Retrieved from "https://wiki.mozilla.org/index.php?title=User:Jorge.villalobos/WorkWeek2012Q2&oldid=441042"