[Blog post] Add-on Policy and Process Updates

#1

(Cross-posted from the Add-ons Blog)

As part of our ongoing work to make add-ons safer for Firefox users, we are updating our Add-on Policy to help us respond faster to reports of malicious extensions. The following is a summary of the changes, which will go into effect on June 10, 2019.

  • We will no longer accept extensions that contain obfuscated code. We will continue to allow minified, concatenated, or otherwise machine-generated code as long as the source code is included. If your extension is using obfuscated code, it is essential to submit a new version by June 10th that removes it to avoid having it rejected or blocked.

We will also be clarifying our blocking process. Add-on or extension blocking (sometimes referred to as “blocklisting”), is a method for disabling extensions or other third-party software that has already been installed by Firefox users.

  • We will be blocking extensions more proactively if they are found to be in violation of our policies. We will be casting a wider net, and will err on the side of user security when determining whether or not to block.

  • We will continue to block extensions for intentionally violating our policies, critical security vulnerabilities, and will also act on extensions compromising user privacy or circumventing user consent or control.

You can preview the policy and blocking process documents 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 post them here.

3 Likes
#2

4 posts were merged into an existing topic: Certificate issue causing add-ons to be disabled or fail to install

#6

The certificate issue causing add-ons to be disabled being experienced by many users is unrelated to this policy change. Discussion about that issue should be discussed in the relevant topics.

#7

This topic was automatically opened after 2 days.

#11

3 posts were split to a new topic: Thoughts on recent policy changes

#12

Hey Caitlin,

just wondering… what actually counts as minified and what counts as obfuscated?
Using the normal webpack process, which minifies the code, looks pretty obfuscated to me, since all variable names are gone and have been replaced by shorter ones.

#13

Hi Lusito,

we have a guide on this on the Source Code Submission page. Does this answer your questions? If there is anything we can expand in that section I’d be happy to hear your feedback.

Philipp

2 Likes
#14

Thanks Philip, that does clear it up. So webpack production mode should be fine.

#15

From https://github.com/jeremiahlee/page-translator/issues/26#issuecomment-568393559:

… I guess that the significance of Mozilla’s posts (and related publicity) was simply lost in the coincidental frenzy around armagadd-on 2.0.

I reckon that it was:

  • less a communication failure
  • more a failure to pay attention

– no disrespect intended. Given the unfortunate coincidence, it’s almost entirely understandable that everyone concerned lost sight of Mozilla’s forewarning.

HTH

tl;dr extremely unfortunate. The perceived suddenness of the (October 2019) block, and so on.

@caitmuenster please: all things considered, might the block on Page Translator be eased – from hard, to soft? Mid-January, maybe? (Until the benefits of Bergamot https://redd.it/dtppt3 can be made available to end users.)

Re: https://bugzilla.mozilla.org/show_bug.cgi?id=1589974#c8 whilst I’m aware of the appropriateness of the e-mail address (I don’t expect a reply here) I do want to publicly show support for ease in this exceptional case. IMHO there’s sufficient technical context for ease here to not set a precedent elsewhere.

TIA