Add-ons Policy Changes 2021

Add-ons Announcements
#21

Could you please clarify how the HTTPS requirement works for user-supplied values and/or the website currently being browsed? A few examples:

  • Can 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?

In general, should this rule be interpreted as “an extension shall always prefer an encrypted connection to an unencrypted one if possible”, as “an extension shall not introduce new unencrypted connections except at explicit user request” or as “an extension must not touch anything that’s unencrypted even if that’s what the user explicitly tells it to do”?

2 Likes
#22

I’d like to understand how to adapt my Add-ons for the new policies given that they are installed into schools via Enterprise policies as part of educational software. I think many students, given the choice to opt-out of having their Teachers know where they are browsing, probably would choose that. However that doesn’t make sense in a school setting, the parents have already signed a Data Privacy agreement with my company and their school. And most of the time the computer belongs to the school and is completely managed by the school.

I would appreciate any information that would help me adapt my Add-ons for Enterprise education users.

1 Like
#23

I have a question about HTTPS requirements for remote services. I would like to be able to provide updates for the self-hosted version of my extension I2P in Private Browsing from within the I2P network itself. In order to do this I would have to reach out to a remote service at a .b32.i2p hostname. Most of the time we haven’t used HTTPS for these domains because b32.i2p hostnames are self-authenticating and self-encrypting just like .onion hostnames.

I can configure the update server to use HTTPS on the .b32.i2p hostname, but the remaining problem is basically, I’m not Facebook. I can’t get a real, signed, CA-issued certificate for my I2P hostname. There’s no guarantee that there would even be a non-I2P site where the extension would be updated which could apply for a certificate that could eventually be used to sign the .b32.i2p hostname. The bottom line is that I can only use a self-signed certificate.

So, my questions: Does a self-signed certificate for a hidden service hostname satisfy the requirement of “Real, in-browser HTTPS?”

If not, could it be made possible for self-hosted extensions to deliver a self-signed certificate which they can indicate within in their manifest.json, which indicates that the self-signed certificate is valid only for the domain used in the update_url field? That would enable people who use browser extensions like ours to integrate with hidden service networks, the distributed web, etc. to distribute in-network updates in a way which is straightforward to them and to the users, and would not involve making a self-signed certificate valid for things that it should not be valid for(By encouraging users to install certificates or make unwise exceptions). Changes to the certificate could be detected by the automated addon scans and you could contact the extension maintainer to confirm it was deliberate?

1 Like
#24

For clarity, is this saying “there will be a new field in the submissions details, for you to post a privacy policy”? If so, this doesn’t appear to be live at the moment - do we know when we’ll need to fill this out?

Also, if our addon doesn’t collect any user data at all (for example, if our tool is a downloader that never sends anything back, or something that modifies how a site looks), is it sufficient to simply say we don’t collect any user data? Or do we need something more formal?

3 Likes
#25

I am the only user of my vertical tab extension. It’s not listed on AMO, but it does have a public Github repository. Does Mozilla consider that distribution?

My extension shows me tab icons. It uses whatever Firefox gives it as the image. What does this mean in regards to the privacy policy, and the HTTPS only requirement?

#26

Thanks. I loathed add-ons that were nothing better than a bookmark. Good riddance!

1 Like
#27

So, I guess Mozilla doesn’t want people to develop add-ons for Intranets or localhosts where https isn’t available.

I guess they’re trying to get rid of the few faithful developers left.

Or maybe they didn’t think this one through…like many of their decisions for the past few years.

2 Likes
#28

I’d wait for the official answers. My best guess is that this change was intended as “you really need to use HTTPS over the wide Internet even if information does not seem sensitive”, but not enough attention was given to corner cases.

1 Like
#29

Yea I’d be annoyed if my add-on that communicate with localhosts or intranet fail to work because if https requirement. and look, they haven’t even bothered to answer anyone’s question so far.

1 Like
#30

The summary above states “Most add-ons require a privacy policy”. The current policy preview from December goes a bit further:

You must maintain a privacy policy in the privacy policy field on addons.mozilla.org.

It would be helpful if Mozilla could provide a minimal template for the no-data-collection-being-done-at-all case.

4 Likes
#31

Google’s Chrome Web Store has an option for ‘this add-on doesn’t not collect data, beyond what is required for its operation’. Something like that could work here - a simple checkbox or button indicating ‘there is no data collection’.

1 Like
#32

Can you please clarify following sections? :

  • 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 .
    Question: Does this only apply to listed addons or unlisted addons as well?

  • 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.
    Question: Is best practice mentioned at https://extensionworkshop.com/documentation/develop/best-practices-for-collecting-user-data-consents/ for data consent still applicable to determine “Prompt after install or First use”

#33

Do unlisted Add-ons require a privacy policy? I don’t see a field in the Add-on Developer Hub page to add a specific privacy policy to my unlisted extensions.

1 Like
#34

I have 3 addons listed on AMO that currently have no privacy policy because they do not collect any data. When I look to add a privacy policy under Manage Authors and License page I see

If your add-on transmits any data from the user’s computer, a privacy policy is required that explains what data is sent and how it is used. It is only relevant for listed add-ons.

This is very confusing since the Dec policy states I must maintain a privacy policy but the webpage to add one tells me the privacy policy is for explaining the data collection my addons don’t do.

1 Like
#35

Also, 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)?

#37

@mozkewisch
My addon runs on a single (1990s vintage) forum, adding features to it such as identifying new posts. It uses local storage to store ‘context’ from one invocation to the next, e,g. the last displayed post number, and for user preferences. It won’t work at all without this local storage. There are currently 6 users.

Is that use regarded as ‘cookies’ which requires consent?

If so can I simply add a statement to the addon description - something like ‘this addon uses local browser storage for xxxxx, do not install this addon unless you are happy with that’? Or must I add a first-install consent dialogue and disable it if the user does not consent?

TIA
Dave

#38

Everyone should calm down :slight_smile:.
These policy updates are primarily targeting malicious addons that tracks users or spam addons that are basically an ad for a service with no features.
You don’t see this but Firefox addons page is constantly under attack with a huge number of fake/malicious addon submissions and these new policy will help fight it.

Nobody wants to take down your addon made with love for users like you!

And even if there is a problem with your addon, the reviewer will contact you and you will have time to resolve issues.
But in general, if your addon is not used by a huge number of users, it will never be reviewed.

So don’t stress yourself just yet :slight_smile:. Focus on what’s important and have a nice week!

1 Like
#39

You don’t see this but Firefox addons page is constantly under attack with a huge number of fake/malicious addon submissions and these new policy will help fight it.

Actually, a lot of people totally do, which is part of why this is so weird looking. It is very, very obvious that this is happening. Until this new policy came out, there wasn’t a peep out of Mozilla about the proliferation of malicious extensions being the root of extension review times.

And even if there is a problem with your addon, the reviewer will contact you and you will have time to resolve issues.

Having gone through this process once already I can hardly recommend it, in fact it is extremely poorly conducted throughout and part of the reason for why it’s so bad is because these rules were poorly or insufficiently conceived. I’m still willing to give this one to Hanlon and not Mulder, but non-malicious intent doesn’t actually make it better for any of us. The outcome is the same, our extension updates are blocked for months at a time.

But in general, if your addon is not used by a huge number of users, it will never be reviewed.

What’s huge? 10000 users? 1000? 100? Mine’s between the last two. Anyway this is false. There are tons of unlisted extensions with a single user or used within a single organization that are affected by this already. These are self-hosted extensions.

If they want self-hosted WebExtensions to remain viable we’re going to need some way of side-loading valid extension signing keys into Firefox to do our own signing without AMO. Extensions should have to opt-into this method at the same time they choose between AMO or self-distribution. Sideloading a key should not be something a user can do by accident and it should not be required to manipulate about:config. A real UI for extension key sideloading so unlisted extensions that opt-in can’t even be installed without performing the sideloading procedure. That would actually impact the problem by removing the burden of signing many unlisted extensions from Mozilla and removing the ability to install those extensions from Firefox without explicitly enabling them by sideloading a key.

#40

I don’t think the number of users is taken into account. And nor should it be - if an add-on is malicious you don’t want to wait till it’s popular.

I had to rewrite a section of this same add-on after several years because it contained ‘obfuscated code’ - a table of unicode characters which were in a unicode to html-code conversion module published on github. Even though its content and purpose were obvious, I couldn’t demonstrate how the table was built. The reviewer was helpful - but inflexible.

But in this case I just want to know the minimum I have to do to keep my addon listed. I need it listed on AMO so I can use it in FX Android Nightly.

1 Like
#41

One question:

Add-ons must not relax web page security headers, such as the Content Security Policy.

Does this include a) addons that are designed to relax security headers, such as CORS Everywhere, and b) addons 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?