---
created_at: '2015-07-31T11:14:47.000Z'
title: No Surprises (2009)
url: https://blog.mozilla.org/addons/2009/05/01/no-surprises/
author: marcolinux
points: 67
story_text: 
comment_text: 
num_comments: 62
story_id: 
story_title: 
story_url: 
parent_id: 
created_at_i: 1438341287
_tags:
- story
- author_marcolinux
- story_9981100
objectID: '9981100'

---
[Source](https://blog.mozilla.org/addons/2009/05/01/no-surprises/ "Permalink to No Surprises | Mozilla Add-ons Blog")

# No Surprises | Mozilla Add-ons Blog

* [Skip to main content][1]
* [Skip to sidebar][2]

# [Mozilla Add-ons Blog][3]

[Mozilla][4]

# No Surprises

[ ![][5] ][6]

[30 responses][7]

[ May ][8] 1  [ 2009 ][9]

Surprises can be appropriate in many situations, but they are **not** welcome when user security, privacy, and control are at stake. Mozilla is [committed][10] 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][11].

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

**Tags:** [policy][13], [security][14]

**Categories:** [developers][15], [policy][16]

## 30 responses

1. ###  Jesse Ruderman ![][17] wrote on [ May 2, 2009 at 12:25 am ][18]: 

> 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 ![][19] wrote on [ May 2, 2009 at 12:41 am ][20]: 

> Great, swift reaction @ the NoScript debacle.

3. ###  James Pujals ![][21] wrote on [ May 2, 2009 at 5:16 am ][22]: 

> 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 ![][23] wrote on [ May 2, 2009 at 5:41 am][24]:

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

5. ###  anon58994 ![][25] wrote on [ May 2, 2009 at 5:54 am][26]:

> Yes! A thousand times yes! Good work Mozilla.

6. ###  spkthed ![][27] wrote on [ May 2, 2009 at 6:46 am ][28]: 

> 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 ![][29] wrote on [ May 2, 2009 at 8:26 am][30]:

> 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 ![][31] wrote on [ May 2, 2009 at 8:37 am][32]:

> 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 ![][33] wrote on [ May 2, 2009 at 10:06 am][34]:

> 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 ![][35] wrote on [ May 2, 2009 at 1:29 pm][36]:

> 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 ![][37] wrote on [ May 2, 2009 at 2:05 pm ][38]: 

> 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) ![][39] wrote on [ May 3, 2009 at 5:03 am ][40]: 

> 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 ![][41] wrote on [ May 3, 2009 at 6:10 am][42]:

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

14. ###  Anon ![][43] wrote on [ May 3, 2009 at 6:19 am][44]:

> ‘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 ![][45] wrote on [ May 3, 2009 at 2:20 pm][46]:

> @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 ![][47] wrote on [ May 4, 2009 at 7:06 am][48]:

> 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 ![][49] wrote on [ May 4, 2009 at 8:07 am][50]:

> 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 ![][51] wrote on [ May 4, 2009 at 11:13 am][52]:

> 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 ![][53] wrote on [ May 4, 2009 at 1:52 pm ][54]: 

> 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 ![][55] wrote on [ May 4, 2009 at 3:34 pm ][56]: 

> 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 ![][57] wrote on [ May 4, 2009 at 4:54 pm ][58]: 

> @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)][59] a [closed source and proprietary][60] software too, right?

22. ###  Nom ![][61] wrote on [ May 4, 2009 at 5:46 pm][62]:

> 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 ![][63] wrote on [ May 5, 2009 at 6:14 am][64]:

> “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 ![][65] wrote on [ May 5, 2009 at 11:15 am][66]:

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

25. ###  chofmann ![][67] wrote on [ May 5, 2009 at 1:22 pm ][68]: 

> 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 ![][31] wrote on [ May 5, 2009 at 9:54 pm][69]:

> 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 ![][37] wrote on [ May 6, 2009 at 5:42 pm ][70]: 

> 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 ![][71] wrote on [ May 12, 2009 at 7:21 am][72]:

> 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 ![][73] wrote on [ May 20, 2009 at 2:06 pm][74]:

> 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 ![][75] wrote on [ July 26, 2009 at 4:04 pm][76]:

> 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][77]

###  [ ![][78] ][79]

[More from ][79]

### Looking for Add-ons?

[**Visit the gallery][80]**

### Categories

* [builder][81]
* [compatibility][82]
* [contests][83]
* [contribute][84]
* [developers][85]
* [documentation][86]
* [end users][87]
* [events][88]
* [featured addons][89]
* [featured contributors][90]
* [general][91]
* [jetpack][92]
* [mobile][93]
* [policy][94]
* [releases][95]
* [restartless][96]
* [sdk][97]
* [themes][98]
* [webextensions][99]

[Return to top][100] [Mozilla][4]

Except where otherwise [noted][101], content on this site is licensed under the [Creative Commons Attribution Share-Alike License v3.0][102] or any later version. 

* [Contact Us][103]
* [Privacy Policy][104]
* [Legal Notices][105]
* [Report Trademark Abuse][106]
* [Theme Code ][107]

[1]: https://blog.mozilla.org#content-main
[2]: https://blog.mozilla.org#content-sub
[3]: https://blog.mozilla.org/addons/ "Go to the front page"
[4]: https://www.mozilla.org/
[5]: https://secure.gravatar.com/avatar/?s=24&r=g
[6]: https://blog.mozilla.org/addons/author/ "See all posts by "
[7]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comments
[8]: https://blog.mozilla.org/addons/2009/05/ "See all posts from May, 2009"
[9]: https://blog.mozilla.org/addons/2009/ "See all posts from 2009"
[10]: http://www.mozilla.org/about/manifesto
[11]: http://groups.google.com/group/mozilla.dev.amo/topics
[12]: https://addons.mozilla.org/en-US/developers/docs/policies/reviews#section-defaults
[13]: https://blog.mozilla.org/addons/tag/policy/
[14]: https://blog.mozilla.org/addons/tag/security-announcements/
[15]: https://blog.mozilla.org/addons/category/developers/
[16]: https://blog.mozilla.org/addons/category/policy/
[17]: https://secure.gravatar.com/avatar/d2dc9227eafcd0ec5ba3712ee4f19b75?s=48&r=g
[18]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3646 "Permanent link to this comment by Jesse Ruderman"
[19]: https://secure.gravatar.com/avatar/b53ac440869db5bf7248ae5c6d26b1c3?s=48&r=g
[20]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3648 "Permanent link to this comment by David Naylor"
[21]: https://secure.gravatar.com/avatar/30b25ea682e6a325fdffdc3364e0c999?s=48&r=g
[22]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3654 "Permanent link to this comment by James Pujals"
[23]: https://secure.gravatar.com/avatar/228245860ccb20531e5b1be726320cae?s=64&r=g
[24]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3655 "Permanent link to this comment by John"
[25]: https://secure.gravatar.com/avatar/c510febb9bed68b5cc4a09f076701e0f?s=64&r=g
[26]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3656 "Permanent link to this comment by anon58994"
[27]: https://secure.gravatar.com/avatar/8112cedbbd7421a41545f4c95ae6ceab?s=48&r=g
[28]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3658 "Permanent link to this comment by spkthed"
[29]: https://secure.gravatar.com/avatar/2265e743ac5bf6f78c6c8fe5d3fa7467?s=64&r=g
[30]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3665 "Permanent link to this comment by Pseudonymous Coward"
[31]: https://secure.gravatar.com/avatar/fe3a611777daf859fa9b3535a5164d61?s=64&r=g
[32]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3666 "Permanent link to this comment by AKAJohnDoe"
[33]: https://secure.gravatar.com/avatar/15f111b4e413a12de6dd05745e674199?s=64&r=g
[34]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3667 "Permanent link to this comment by Ben Bucksch"
[35]: https://secure.gravatar.com/avatar/7d3e8568bd27920063ac605620a7fac1?s=64&r=g
[36]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3676 "Permanent link to this comment by Mook"
[37]: https://secure.gravatar.com/avatar/2246e9f43ad4b30102f289071ae91e2e?s=48&r=g
[38]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3678 "Permanent link to this comment by Michael Kaply"
[39]: https://secure.gravatar.com/avatar/1250b261e7174ddd6693f61d03477eaf?s=48&r=g
[40]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3698 "Permanent link to this comment by W^L+ (Walt Hucks)"
[41]: https://secure.gravatar.com/avatar/14d44015f21ccd5cb7ae448db9ada80c?s=64&r=g
[42]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3700 "Permanent link to this comment by SomeDude"
[43]: https://secure.gravatar.com/avatar/357a20e8c56e69d6f9734d23ef9517e8?s=64&r=g
[44]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3701 "Permanent link to this comment by Anon"
[45]: https://secure.gravatar.com/avatar/26ce53c20c5831d282772b3795c2429c?s=64&r=g
[46]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3706 "Permanent link to this comment by Simon"
[47]: https://secure.gravatar.com/avatar/5377323bbe24824de512a6a077fc77a3?s=64&r=g
[48]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3716 "Permanent link to this comment by Sam Hasler"
[49]: https://secure.gravatar.com/avatar/d7859248f63df404a87b487e379142ca?s=64&r=g
[50]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3719 "Permanent link to this comment by James Elie"
[51]: https://secure.gravatar.com/avatar/43c9ef982d0243ac7c6a6ae84ad86129?s=64&r=g
[52]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3720 "Permanent link to this comment by JR"
[53]: https://secure.gravatar.com/avatar/beb21939f6a5a1e3b48faa2d5eed358a?s=48&r=g
[54]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3721 "Permanent link to this comment by spenser"
[55]: https://secure.gravatar.com/avatar/ea9fb19fef444264d72320fbcb5078c3?s=48&r=g
[56]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3723 "Permanent link to this comment by penkapp"
[57]: https://secure.gravatar.com/avatar/b74f4b88e05b4c81cdfd44b4852cebea?s=48&r=g
[58]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3725 "Permanent link to this comment by BartZilla"
[59]: https://addons.mozilla.org/en-US/firefox/addon/5202
[60]: https://wiki.mozilla.org/Talk:Releases/Fx_3.0.7_Partners
[61]: https://secure.gravatar.com/avatar/729ac24db54c9bffde9f2bd2c1997771?s=64&r=g
[62]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3726 "Permanent link to this comment by Nom"
[63]: https://secure.gravatar.com/avatar/cc24c17b3e28b217c2a16687e25b1019?s=64&r=g
[64]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3744 "Permanent link to this comment by mark"
[65]: https://secure.gravatar.com/avatar/3ed6524c308c84098871593aa561080b?s=64&r=g
[66]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3750 "Permanent link to this comment by Manne"
[67]: https://secure.gravatar.com/avatar/d4b6b76f9bdc1f85df922cb34012dc09?s=48&r=g
[68]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3753 "Permanent link to this comment by chofmann"
[69]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3759 "Permanent link to this comment by AKAJohnDoe"
[70]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3780 "Permanent link to this comment by Michael Kaply"
[71]: https://secure.gravatar.com/avatar/f5d8f5821270e3ba8e13a9c47a03a2e4?s=64&r=g
[72]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-3891 "Permanent link to this comment by Bilbo"
[73]: https://secure.gravatar.com/avatar/89e0d4a0217080c2bdb516778443f945?s=64&r=g
[74]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-4030 "Permanent link to this comment by ranides"
[75]: https://secure.gravatar.com/avatar/3972ebbfdc3479e44dfad086fec27b27?s=64&r=g
[76]: https://blog.mozilla.org/addons/2009/05/01/no-surprises/#comment-6675 "Permanent link to this comment by Daifne"
[77]: https://bugzilla.mozilla.org/show_bug.cgi?id=502479
[78]: https://secure.gravatar.com/avatar/?s=68&r=g
[79]: https://blog.mozilla.org/addons/author/
[80]: https://addons.mozilla.org/
[81]: https://blog.mozilla.org/addons/category/builder/
[82]: https://blog.mozilla.org/addons/category/compatibility/ "Information about add-on compatibility"
[83]: https://blog.mozilla.org/addons/category/competition/
[84]: https://blog.mozilla.org/addons/category/contribute/
[85]: https://blog.mozilla.org/addons/category/developers/ "Topics of interest to add-on developers"
[86]: https://blog.mozilla.org/addons/category/documentation/ "Documentation and tutorials for add-on developers"
[87]: https://blog.mozilla.org/addons/category/end-users/ "Information of important to end users/consumers of add-ons"
[88]: https://blog.mozilla.org/addons/category/events/ "Information about upcoming add-on events"
[89]: https://blog.mozilla.org/addons/category/featured-addons/
[90]: https://blog.mozilla.org/addons/category/featured-contributors/
[91]: https://blog.mozilla.org/addons/category/general/ "General/uncategorized posts"
[92]: https://blog.mozilla.org/addons/category/jetpack/
[93]: https://blog.mozilla.org/addons/category/mobile/
[94]: https://blog.mozilla.org/addons/category/policy/ "New policies and discussion of draft policies for add-ons"
[95]: https://blog.mozilla.org/addons/category/releases/ "Information on releases of addons.mozilla.org"
[96]: https://blog.mozilla.org/addons/category/restartless/
[97]: https://blog.mozilla.org/addons/category/sdk/
[98]: https://blog.mozilla.org/addons/category/personas/
[99]: https://blog.mozilla.org/addons/category/web-extensions/
[100]: https://blog.mozilla.org#page
[101]: https://www.mozilla.org/about/legal.html
[102]: http://creativecommons.org/licenses/by-sa/3.0/
[103]: https://www.mozilla.org/contact/
[104]: https://www.mozilla.org/privacy/
[105]: https://www.mozilla.org/about/
[106]: https://www.mozilla.org/legal/fraud-report/
[107]: https://github.com/mozilla/One-Mozilla-blog/

