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
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
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!
1 Like
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.
1 Like
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.
1 Like
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.
It’s OK I’m not actually mad at you. That said, it’s already been an issue for me(I am the reason that the cookie consent requirement is now conditional). My ire is completely focused on the AMO team right now. There are like 40 questions on this almost 3 week old thread and only one answer. AMO has appeared broken for about a year and they’re not listening at all or telling us anything about what’s going on. We’re forced to look at the evidence surrounding the situation AMO and conclude that spammers(spamming malicious addons) are successfully DOSing legitimate addon developers by exhausting Mozilla’s time. Policy changes aren’t going to make AMO/extension developers harder to attack in this way. Maybe not all extensions are that important but some are extremely important. Snowflake and uBlock Origin are extremely important, for instance.
Hi, everyone - Mike Hoye here, on behalf of the Add-ons team. I wanted to thank you for your questions; I’m collecting them for the team, and we’re going to go over them together shortly.
One of our main goals for this update is that the policy document itself to be able to answer your questions as much as possible. No policy can cover all cases, but in those places (several of them you’ve already mentioned here) where there are difficult edge cases in play or other things that need more clarity and specificity, we’ll try to provide that.
As an aside, when Juraj says, “Nobody wants to take down your addon made with love for users like you!” - that’s true, nobody wants that, but we have a set of standards and policies here that are important for the safety of the whole Firefox community, and they define how the Add-ons team enforces policy, so: the words matter, and we’d like to get them right. Especially for developers making stuff out of love for their users. So, thanks for all of your help here, we’ll have good answers for you soon.
-mhoye
4 Likes
Is there a timeframe when we should expect some clarifications to the questions? Given that there are a couple of them and as I understand you’ll start enforcing the policy in 7 days.
1 Like
Does private add-ons also need to show the consent dialog when collecting technical or user data?
If so how much time we have to implement them?
Will our future submissions be rejected if we don’t implement them?
Given that there hasn’t been any clarifications yet, are you still going to start removing our extensions from tomorrow?
1 Like
Thank you @mhoye for the updated information.
Regarding changes to listings, such as the new mandatory privacy policy, how long do we have to update our entries? Is there any sort of grace period to update existing addons?
This link is 404 now https://extensionworkshop.com/documentation/publish/add-on-policies-dec-2021
So does this HTTPS policy mean we cannot perform GET/POST requests to HTTP? My extensions communicate with my employer’s local web servers which I’ll never be able to get IT to change.
1 Like