Mozilla Add-ons Community Blog
Categories: developers policy

No Surprises

30 responses

Surprises can be appropriate in many situations, but they are not welcome when user security, privacy, and control are at stake. Mozilla is committed to guarding these principles, and we feel that a policy should be adopted that explicitly details our stance on these issues in regard to add-on modifications. The text of our proposal is below.

Changes to default home page and search preferences, as well as settings of other installed add-ons, must be related to the core functionality of the add-on. If this relation can be established, you must adhere to the following requirements when making changes to these settings:

  • The add-on description must clearly state what changes the add-on makes.
  • All changes must be ‘opt-in’, meaning the user must take non-default action to enact the change.
  • Uninstalling the add-on restores the user’s original settings if they were changed.

These are minimum requirements and not a guarantee that your add-on will be approved.

We welcome all constructive feedback and comments on this proposal, preferably in the AMO Newsgroup.

Update: The No Surprises policy has now been officially adopted and has changed slightly since this blog post. Read the official policy for details.

30 comments on “No Surprises”

  1. Jesse Ruderman wrote on

    For an extension whose only purpose is to replace the home page or new-tab page, it seems silly to require “opt-in”. I also don’t understand why you’d require both disclosure-in-description and opt-in, since if you have opt-in, the disclosure-in-description will be inaccurate or confusing.

  2. David Naylor wrote on

    Great, swift reaction @ the NoScript debacle.

  3. James Pujals wrote on

    I believe that the proposed policy change is reasonable and consistent with the spirit of the Mozilla community and its commitment to security and privacy.

    I will recommend not only the wholesale approval of this change, but its ongoing enforcement.

    -dZ.

  4. John wrote on

    Does an extension updating itself to a newer version without asking or notifying the user constitute a change?

  5. anon58994 wrote on

    Yes! A thousand times yes! Good work Mozilla.

  6. spkthed wrote on

    I want to thank you guys for this welcome change. I’m assuming the reason for this at least in part is the whole Noscript situation. One of the reasons that I like recommending Mozilla is that it offers layers of protection against people that abuse the default settings in software. Most people won’t care enough to find out what that means.

    This provides a major level of protection against spammers and is a major victory in the fight for all of us.

  7. Pseudonymous Coward wrote on

    I’m sorry but this is only as strong as the weakest social link. What Mozilla needs to do is technologically enforce its AMO policy. Suggestions:

    1. A strong Javascript sandbox.
    2. Why on earth do extensions have such raw power in Firefox? We need a strong add-ons sandbox too.

  8. AKAJohnDoe wrote on

    There also needs to be the ability to ‘opt-out’ without adversely affecting the functionality.

    If one add-on author believes that they need functionality in another add-on that needs to be negotiated with the author of the other add-on in order to become a part of that other add-on. Alternatively, the author wishing the functionality could simply create another add-on that pairs with theirs and document that that fact.

    It is simply wrong on so many levels to allow cross-dependencies.

  9. Ben Bucksch wrote on

    What about other prefs? Is it fine to change weaken cookie policy pref? To just enable autoupdate although I had disabled it? To set a proxy which re-routes all my traffic?

    I think the link to “the core functionality of the add-on” is good, but it should apply to all prefs, not just homepage and search. It is essentially just a concrete version of the “no surprises” rule that already applies. If an extension changes a pref, and that pref change has nothing to do with the core functionality of the addon, it’s always surprising.

  10. Mook wrote on

    Making the addons restore your preferences on uninstall will be very hard to meet, since:
    1) The user might have changed things since, at which point it’s hard to tell what you want to do (e.g. home page prefs, or even the pile of things FasterFox does)
    2) You don’t actually get a reliable uninstall notification. Safe mode + uninstall from there?

    I do agree with the other things though, that’s definitely a positive step towards empowering the user. Or something, I’m not used to words like that.

  11. Michael Kaply wrote on

    I’ll participate in the discussion, but I completely disagree with the search preferences thing.

    If an extension is upfront about the fact that it is going to change the search engine, that should be fine.

    That’s how a number of extensions get revenue is by changing the search engine. It’s not necessarily related to the extension, but it is a fact of life.

  12. W^L+ (Walt Hucks) wrote on

    Being “upfront” about their revenue is part of “tell me what you’re changing”. Still, opt-in is the only reasonable solution to situations like the recent one involving NoScript changing AdBlockPlus filter settings to whitelist ads on its sites. Like most others, I would have voluntarily enabled the ads if NoScript had been upfront about what was going on, because I like and use that extension.

    Part of my job is to fix things when users of another browser get hijacked this way. This policy is entirely reasonable and consistent with why I tell my users to install Firefox on their home computers.

  13. SomeDude wrote on

    Nice to see some decisive action from Mozilla on the NoScript debacle.

  14. Anon wrote on

    ‘If an extension is upfront about the fact that it is going to change the search engine, that should be fine.’

    So it’s fine to tell someone ‘I’m going to change your home page and then you can change it right back when I’m done’ but it isn’t fine to say ‘I want to change your home page – do you want me to?’

    ‘That’s how a number of extensions get revenue is by changing the search engine. It’s not necessarily related to the extension, but it is a fact of life.’

    Some extensions may do. Some extensions, for all I know, get their revenue from their authors mugging people in the streets. Just because things happen doesn’t mean they’re right.

  15. Simon wrote on

    @Anon – being upfront about changing the search engine doesn’t mean it tells you before it does it – it means you know that’s what it does before you install it. It’s not a case of better to ask forgiveness than permission…

  16. Sam Hasler wrote on

    Addon’s shouldn’t open up a web page after install to tell you what has changed. They should be required to submit detailed changelogs to AMO so that they appear in the “Show Information” pane of the Updates dialog so that users can see what has changed BEFORE they decide whether to upgrade or not.

  17. James Elie wrote on

    Bravo! As someone in Systems Support part of the industry, I definitely support both Full Disclosure and Opt-In and the fact that they are paired. However, simply restoring user settings without prompting upon an uninstall is just a user nightmare waiting to happen as changes post-install may have taken place.

    I would only support restoring of user or program settings if it prompted the user and showed them: what the setting was pre-install, what it was changed to (as part of the install), and what it is currently. Which could very well display 3 different settings.

    Overall, thank you for adding this policy of transparency. 🙂

  18. JR wrote on

    I think this policy change is important and necessary to retain the trust users have in Mozilla, and in the extensions provided through the software interface on Mozilla software.

    This is not, by any means, a complete fix to the problem at hand. Mozilla needs to enforce limits on what extensions can and cannot do, whether via changes to Mozilla software or by increased oversight of extensions available via the Mozilla website.

    Extensions like AdBlock Plus and NoScript that make changes affecting security of Mozilla software should always be reviewed by AMO before being made available to users. Obviously, the “trusted” system is not sustainable, as it allowed authors to sneak in changes without oversight.

    That said, the Mozilla community is to be commended for how quickly this issue was brought to light and is being dealt with. Closed-source vendors are notorious for not being responsive to issues like this.

  19. spenser wrote on

    The solution for the use case where a user has changed settings since the install of the addon, at the time of uninstall, is to give the user the choice of which setting to make. Yes, give the user a choice.

  20. penkapp wrote on

    It would seem Mozilla could implement a Public/Private key encryption system for each add-on based upon a given domain name or author ID. A given add-on could not alter another unless it was capable of exchanging keys.

  21. BartZilla wrote on

    @JR: You wrote: “Closed-source vendors are notorious for not being responsive to issues like this.”.
    But you realize that Mozilla distributes (and even recommends on AMO) a closed source and proprietary software too, right?

  22. Nom wrote on

    How about Mozilla stop allowing some extensions to be installed while the browser is CLOSED and without an option to uninstall them? *cough*Java Quick Starter*cough*

  23. mark wrote on

    “Uninstalling the add-on restores the user’s original settings if they were changed.”

    How is this technically done? Will each plugin author need to write his own code for this, or can he use something “central”?

  24. Manne wrote on

    How about programs like skype?
    It installs (without asking and impossible to unselect) an extension in Firefox.

    Not fine.

  25. chofmann wrote on

    mkaply,

    JR, summed up what this policy is about.

    “…policy change is important and necessary to retain the trust users have in Mozilla”

    If an extension isn’t upfront about the fact that it is going to change the search engine, or it takes the introduction of lots of complicated UI with lots of misunderstood or confusing words and dialogs to do so then we simple are in a race to the bottom.

    When addons start to change preferences outside the core functionally of the addon, users will lose trust individual addon, then addons as a whole, then Firefox, then Mozilla. As we have seen the war can also escalate to a race to the bottom between competing addons wanting to control preferences.

    We can’t put users in the middle of this battle and expect any kind of good outcome.

    You are right that addon developers are caught in difficult place with no few monitization options right now and we need to solve that problem, but lets not do it at the expense of degrading user experience and trust.

  26. AKAJohnDoe wrote on

    The answer is the three-pronged approach:

    (1) Enact and enforce a policy regarding scope of authority for add-ons
    (2) Implement an improved process for installing (and uninstalling) add-ons
    (3) Implement the functionality of the best of the best of the add-ons into the core functionality of Firefox

  27. Michael Kaply wrote on

    My problem is with this wording:

    “Changes to default home page and search preferences, as well as settings of other installed add-ons, must be related to the core functionality of the add-on.”

    This says to me that if an add-on is not explicitly related to search (like Yahoo or Google toolbar), it can’t change search preferences, even if it is upfront with the user about the fact that it is going to change these things.

    So an addon that says “we change the search engine to Foo. Please use Foo and support us” won’t be allowed to do that anymore unless the addon is explicitly related to search.

    Is that correct?

  28. Bilbo wrote on

    About “Uninstalling the add-on restores the user’s original settings if they were changed”

    What if user have some pref set to A, plugin changes it to B and some time later, user changes it to C. Should the plugin revert it back to A? If “that pref” is homepage for example, I think user will be quite unhappy with it.

    I think the plugin should restore the settings to its previous values ONLY if they are not changed between installation and uninstallation of the plugin.

    Perhaps add some helper functions which extension authors would call and they will do this “properly”.

  29. ranides wrote on

    Policy policy…
    great great, but it’s impossible.

    Separate JavaScript sandbox for every addon… ROTFL. I don’t want think about performance of that solution. Maybe… 10x slower?

    And… Has anyone know that extensions could use XPCOM Compontents? That components can be written in C++ and compiled to native code. It’s impossible to trace and block native code in Firefox, in user-mode. Every XPCOM component can do everything, and this can’t be changed.

    If you want control native code, you must create thousands hooks into operating system, and work in kernel mode. Obviously, internet browser shouldn’t do that…

  30. Daifne wrote on

    And yet it happens again. The Aero Fox and Aero Fox Silver themes now include Ask.com Chrome Search extension with the updates to them. There was no opt out nor was their any notification that this would be installed. This should never have been put in the public section. Besides hijacking the default search, this also affected the Awesome Bar not allowing access to about:config.

    Per the author’s website, he will be doing this with all his themes: http://www.virtusdesigns.net/

    This should never happen with themes hosted at AMO.

    See Bug 502479