Hi, everyone - here are answers to most of the questions we got about the new policies. There are a few questions that have come after we collected these, and we’ll bet getting to them shortly.
Q: The “sole purpose” rule, as it’s currently worded (“Add-ons that serve the sole purpose of launching another website…”) is confusing. 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. Does that mean that these addons would no longer be permitted?
- An addon that opens the current page, dead links or defunct sites in the internet archives, or some other cache?
- Addons that redirect to an external service related to the current page, such as search?
A: First of all I am happy to say that most of the use cases mentioned here continue to be supported. As mentioned earlier, this rule is mainly to avoid add-ons are, for lack of a better term, spam: that is, add-ons of no meaningful utility or functionality that appear to be using addons.mozilla.org purely as a marketing channel for their target site.
To provide a few concrete examples:
- Add-ons that save the current page to a bookmarking site are permitted. Add-ons that simply open a bookmarking site when clicking the browser action button would not be.
- Utility redirects, such as switching between two versions of a site, switching to archive.org, etc also do not fall into this category. The purpose here is not to advertise the website, but to provide the user with a way to obtain additional information or enhance the user experience.
- Search add-ons continue to be welcome on addons.mozilla.org. There are a few additional requirements for search add-ons to protect user privacy.
As well as a few counter-examples:
- An add-on that promotes a service by opening the page and encouraging the user to sign up, but does not actually provide functionality to enhance the browser in combination with this service, is not permitted.
- An add-on that solely encourages the download of a desktop application, where the main functionality described is implemented within the desktop application, is not permitted.
Q: Does " Add-ons must not relax web page security headers, such as the Content Security Policy" include addons that:
- Are designed to do specifically that - for example, CORS Everywhere,
- Add-ons that require relaxing security headers to be functional, such as an extension adding/modifying security headers (e.g. Referer) when accessing an API from background page which is normally inaccessible due to server-side CSRF protection or,
- a userscript loading extension using script tag/eval that replaces CSP?
A: Add-ons related to web development that are explicitly built and described to interact with those headers (e.g. CORS Everywhere) continue to be permitted. This is considered an edge case of the rule. Developers of such extensions should make an effort to clearly describe the security impact and ensure that users don’t accidentally have these security headers disabled while not actively using the add-on.
We’ve seen a number of add-ons that relax the CSP or remove certain headers out of convenience to enable certain functionality. This isn’t great because the protections website authors have put into place are being relaxed, which may have unintended consequences.
One example mentioned above I’d like to provide a bit more detail on, if you are setting a Referer header to achieve a specific result when making a singular request, this is not something disallowed by the policy. With this approach you are not relaxing security headers.
Q: With respect to data collection, one question was, what is the definition of “Collecting”, and does it apply to listed addons only, or unlisted addons as well? Do unlisted Add-ons require a privacy policy? And does Mozilla consider add-on source hosted on GitHub to be a “distribution”?
A: As noted in the introduction, our policies apply to all add-ons. The method of distribution—listed or self-hosted—does not make a difference.
There are some provisions that don’t apply to self-hosted due to their nature, notably parts of the Content section. You do not need to set the privacy policy on addons.mozilla.org for a purely self-hosted add-on, because this won’t be visible to the user. The add-on should however still have a privacy policy available.
In addition, the content policies are relaxed for self-hosted add-ons. If we do not permit add-ons with a closed user group to be hosted on AMO, these add-ons will still provide value when self-hosted.
Note however that, with the exception of parts of the Content section, all provisions apply to all distribution channels and regardless of how many users are using your add-on. This especially includes the section about data collection and user consent.
Q: Is it correct to state that an add-on “does not collect and share user data” if it uses the Firefox bookmark API or storage API in any way (e.g. to save a URL when the user presses a button)?
A: If you are asking about what text to put in the privacy policy, we unfortunately cannot provide legal advice. Add-ons that are self-contained, i.e. they do not expose user information to a website or other external target, do not need an elaborate privacy policy. That said, many jurisdictions are specific about what constitutes permissible data use and retention, and we encourage you to understand your obligations in this regard.
Q: Are the best practices for informed data consent documented at https://extensionworkshop.com/documentation/develop/best-practices-for-collecting-user-data-consents/ still applicable to determine “Prompt after install or First use”?
A: We will be updating this page shortly to accommodate the policy changes. The only major change on that page is the removal of an explicit prompt to consent to storage or access to cookies. The consent prompt still needs to show at the first run of the add-on.
Q: Greasemonkey checks for updates to installed scripts. If it was installed over HTTP, we check for updates over HTTP (not HTTPS) and there is not a lot we can do about that. Is there an exception for runtime/user-supplied values?
A: With this policy change our goal is to broaden the use of HTTPS and ensure that communications are not intercepted or modified in transit. We acknowledge that not all scripts may be hosted on HTTPS servers. However, given that these scripts are code that runs in a user’s browser, often in a privacy-sensitive context, we ask developers of user-script extensions to make every effort to upgrade user-script update paths to HTTPS-secured channels wherever possible. If the connection cannot be upgraded automatically, there should be a clear and user-visible indication that the script upgrade is insecure, and the user may need to review the upgrade.
Q: *Does this https requirement apply to localhost urls, including .localhost subdomains? Does it apply to other protocols, like “ws://”, and does a self-signed certificate for a hidden service hostname satisfy the requirement of “Real, in-browser HTTPS?” This is an issue for many IPFS implementations.
Could you please clarify how the HTTPS requirement works for user-supplied values and/or the website currently being browsed? A few examples:
- an an RSS/Atom feed reader allow the user to subscribe to HTTP-only feeds? Does it need to disable existing user feeds if they’re HTTP-only?
- Is a tab autorefresh extension permitted to reload a user-chosen tab with an HTTP URL?*
- Is a form autosubmit extension allowed to interact with HTTP websites?*
Is a proxy extension allowed to choose a proxy for HTTP requests? Is it allowed to support SOCKS proxies or are they forbidden because the SOCKS protocol is unencrypted? And finally, is this requirement enforced by policy or is there a technical mechanism?
A: A number of questions were raised about the use of encryption. These requirements are mainly intended to increase security and involve mandating the use of encryption whereever possible. This principle applies to http: vs https: the same as it applies to ws: vs wss:.
However, we acknowledge that there will be edge cases where encryption cannot be used. If for example you are interacting with a media server on a local network and the server does not support encryption, requiring encryption would not be constructive. If you are providing access to IPFS services that are by definition a mix of both encrypted and unencrypted transports, you may continue supporting both.
Please ensure that you are setting clear expectations for users in these cases. If a user is transmitting data over an unsecured connection by means of your add-on, they should be aware of this, and be able to make an informed choice. Note also, if you are in control of the service that is only providing unsecured communications, it is up to you to make changes on the server side to provide support. We will not be accepting add-ons that use unsecured communications in this case.