Add-ons Policy Changes 2021

(Cross posted from the add-ons blog)

From time to time, the Add-ons Team makes changes to our policies in order to provide more clarity for developers, improve privacy and security for users, and to adapt to the evolving needs of the ecosystem. Today we’d like to announce another such update, to make sure the Add-ons developer community is well-prepared for when we start to enforce them on December 1st.

In this update, we’ve put a major focus on clarity and accessibility, taking a holistic view of our policies and making them as easy to understand and navigate as possible. While this has resulted in a substantially rewritten and reorganized document, the policy changes are modest and unlikely to surprise anyone. The most notable changes that may require action on the part of add-on developers are as follows:

  • Collecting browsing activity data, such as visited URLs, history, associated page data or similar information, is only permitted as part of an add-on’s primary function. Collecting user data or browsing information secretively remains prohibited.
  • Add-ons that serve the sole purpose of promoting, installing, loading or launching another website, application or add-on are no longer permitted to be listed on addons.mozilla.org.
  • Encryption - standard, in-browser HTTPS - is now always required when communicating with remote services. In the past, this was only required when transporting sensitive information.
  • The section on cookie policies has been removed, and providing a consent experience for accessing cookies is no longer required. Note however, that if you use cookies to access or collect technical data, user interaction data or personal data, you will still require a consent experience at first run of the add-on.

The remaining changes in the document focus on improving the clarity, discoverability and examples. While the policies have not substantially changed, it will be worth your time to review them.

  • If your add-on collects technical data, user interaction data, or personal data, you must show a consent experience at the first run of the add-on. This update improves our description of these requirements, and we encourage you to review both the requirements and our recommended best practices for implementing them.
  • There are certain types of prohibited data collection. We do this to ensure user privacy and to avoid add-ons collecting more information than necessary, and in this update we’ve added a section describing the types of data collection that fall under this requirement.
  • Most add-ons require a privacy policy. For add-ons listed on addons.mozilla.org, the policy must be included in the listing in its full text. We’ve created a section specific to the privacy policy that lays out these requirements in more detail.
  • If your add-on makes use of monetization, the monetization practices must adhere to the data collection requirements in the same way the add-on does. While we have removed duplicate wording from the monetization section, the requirements have not changed and we encourage you to review them as well.

You can preview the policy and ensure your extensions abide by them to avoid any disruption. If you have questions about these updated policies or would like to provide feedback, please respond to this thread.

Update: The policies are now live, please see the main policy for details.

3 Likes

Thanks very much for making these policy changes clear to us.

This point is not clear. Which site counts as “another site”?

The main intent for this rule is to avoid add-ons that are using addons.mozilla.org solely as a marketing channel, and are not providing original functionality. In the simplest case, imagine an add-on that coins itself “File Converter”, but does nothing more than open a web page to convert files.

2 Likes

Thank you, understood.

Feedback: this rule, as it’s currently worded (“Add-ons that serve the sole purpose of /—/ launching another website…”) — was also confusing to me.

Many bookmarklet-type extensions (“save current page to [bookmarking site]”) could also fall under this rule, as their sole purpose is to open a “save bookmark” page…

1 Like

Does this also apply to addons that offer users to opt-out from browsing activity collection?

Re: https – Please note, I spent two weeks (and then some) going round and round and round again with the ca and the domain registrar tearing what little is left of my hair out to FINALLY get traffic routed, encrypted, certified, and accepted on my server. So when the extension does call a cgi script back ‘home’ for support ( a .dot graphviz server) it DOES get ROUTED https, it just starts out in the Javascript as plain-old www.abc.org/cgi-bin/dotserver.cgi for the XHTTP request. plugging “https://” in front of the target in the string WILL NOT WORK [and I tried for many many many hours on the horn to get various tech-support at multiple locations to help].

My point is, this is not something that can be verified by running a source code scanner - it actually has to be verified by ex’ing the XHTTP request.

Thanks for bearing with me, just trying to forestall issues that many others may have trying to achieve this.
Chrys

1 Like

I received an email about it and I don’t now or have I ever developed any add-ons for Firefox or any other browser. To be honest, I don’t even know how.

Encryption - standard, in-browser HTTPS - is now always required when communicating with remote services.

Greasemonkey checks for updates to installed scripts. If it was installed over HTTP, we check for updates over HTTP (not HTTPS). Not a lot we can do about that? Is there an exception for runtime/user-supplied values?

2 Likes

Encryption - standard, in-browser HTTPS - is now always required when communicating with remote services. In the past, this was only required when transporting sensitive information.

Does this https requirement apply to localhost urls, including *.localhost subdomains? Is this requirement enforced by policy or is there a technical mechanism?

The ipfs extension forwards ipfs:// and ipfs.io links to a local daemon with URLs that look like: http://bafybeibwvqwjcptcsl5zm4gedug5mlfsltvcirxffm2zgjr5hudxct6jmy.ipfs.localhost:8080

Approving a self-signed cert for https localhost urls would add a lot of friction for these types of extensions that bridge the web for p2p networks so I really hope there is a carve-out for local daemons here.

4 Likes

I am developing an extension where the user provides a URL (which can be HTTP). The extension search a video from the web page (with a fetch and DOMParser) and sends the video URL to the Kodi mediacenter (with WebSocket unsecure: "ws://...). Is this action not allowed anymore?

3 Likes

I got the email also and I have never created an add-on

I have an addon that loads data from ISP (only accessible inside ISP’s network) using http:// and there is no working https:// alternative.

What is the definition of “Collecting” here?

Add-ons with the sole purpose of promoting, installing, loading or launching another website, application or add-on are no longer permitted to be listed on addons.mozilla.org.

Does that means my addon (that opens current/dead webpage in one of internet archives/cache, anyway, it opens another website) will not be permitted anymore?

Will this mean that my extension; which has the purpose of redirecting users from an old unmaintained wiki to the official wiki for a game, need to be removed from the official addons store?

What about addons that redirect to an external service related to the current page? For example, I recently wrote an extension that generates a link to a Matrix room for the currently-visited URL (only for URLs below a hard-coded domain specified by the extension).

Other examples I can think of, from add-ons I have installed, are:

And of course, others in this thread have provided valid examples of addons whose primary purpose is to redirect, as an automation/convenience feature.

2 Likes

@mozkewisch

Hello, I am one of the developers of an add-on which is redirecting browser requests from a old and derelict community-driven wiki to the new incarnation of it. Presumably this falls under #2 of the policy clause? Considering that the primary purpose of the add-on is to make it easier for users to reach the new community wiki and it intercepts requests to a specific domain (not under our control) and directs the same search query to the new domain (within our control), and is marketed as a tool to do exactly this, can I assume that we are still fine to remain on the add-on store? Please let me know.

Add-ons that serve the sole purpose of promoting, installing, loading or launching another website, application or add-on are no longer permitted to be…

This part was also confusing to me.
We have a click2dial add-on that makes all the phone numbers in all web pages clickable. And by clicking the number you start a call in our application (it’s an application like Skype for business).
Does this add-on violates the new rules?