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?
Thanks. I loathed add-ons that were nothing better than a bookmark. Good riddance!
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.
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.
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.
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.
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’.
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”
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.
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.
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)?
@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
Everyone should calm down 
.
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 . Focus on what’s important and have a nice week!
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.
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.
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?
So all search add-ons are forbidden? What does “installing” a website even mean? And what’s the difference between loading and launching a website?
I get that this rule is meant to combat spam, but you really should use clear language here.
So don’t stress yourself just yet
Also your insinuation here is that our extensions are unimportant. Your post was just condescending and discounting our intelligence until then. Adding this sentence rises to the level of being downright disrespectful.
None of us who are talking about http/https and whether self-signed counts as real are talking about the “wide internet.” We’re all talking about talking to a proxy on the localhost which in turn handles requests to a service which is already encrypting the traffic. I’m even offering to unnecessarily switch to HTTPS over I2P/Onion, even though it is redundant, just to make a Mozillan’s job easier. It would be nice if we could get an actual answer instead of being ignored or handwaved off.
Oh man, I’m really sorry, that is not what I meant at all!
I’m just an addon developer like everybody else in this thread and I just wanted to help calm down the situation because I honestly don’t believe this is goona be an issue for any of them (even though I don’t really know).
And when I say focus on what’s important, that means (for me) developing new features instead of trying to fix a problem that doesn’t exist yet.
Again, I’m sorry, if my words sounded disrespectful, that’s really not who I am.