Internally hosted web data consent

Add-ons addons.mozilla.org
#1

Hey there,

I have been really struggling with reviews on addon.mozilla.org. We submit our source code for review, and that has been the process for a long time. We have not had many issues with the Firefox review process, but recently we have got stuck on quite a few issues. Some of the stuff is minor, like us updating the instructions to make sure the reviewer does not go through internal developer steps for building the addon. But there is some stuff that we have been recently getting that has been causing lots of additional work, and TBH most of the stuff mentioned is nowhere in the guidelines and policies around building and addon.

Internally hosted data consent pages.

This was something that essentially we have been doing for years now, and this allowed us to create a great onboarding experience for our users on our website. We communicate back and forth with our website via a content script to allow different controls to be initially set on these pages. I feel like it’s nothing super uncommon. Even large companies like Honey do this same thing.

We have recently got feedback we can’t do that, and we need to host this page inside of the extension. We went back and forth on the review, and we ended up having to implement some additional data consent settings. Felt like things were moving forward, but now we are stuck back at square one again. It seems like we are being rejected for this again, even though I have not been given any documentation around this requirement. Has anyone experienced this before, and if so, is there any resources or documentation around these requirements? I hate going back to the product manager with these types of changes without having a good reason for them.

A little bit more about the implementation:

  • Website communicates with addon via content script and postMessage.
  • The value that sets the users data consent is stored in the extension local storage.
#2

There are some security concerns about postMessage, make sure to read the docs:


(basically you need to verify “origin” and send messages also only to this origin)

Also, reviewers are lazy programmers just like you and me. You need to make the build process as simple as possible, like npm run build, no manual installing or setting up a build environment :smiley: , lol! Nobody has time for that.

And yeah, the addons needs to be self-contained, even Chrome has that rule now. But this is kind of a gray zone, I’m not sure what’s allowed and what’s not. But the moment your addon makes a single remote request, it can be considered a tracking because your server will know when user installed it, from what IP, what browser and other info. So maybe first popup should be asking user consent about remote communication with your server to provide basic functionality. But I’m not really sure about this :frowning:.

#3

Thanks for the feedback, yeah thanks for the feedback. We have been using postMessage for a while now, it’s just supported more universally, and we have been validating origin, even though TBH the validation could be better.

Chrome has the rule now? Do you have any links to documentation? Yeah feel like that is what bothers me, is that it is a grey area. It makes it harder to know if we have done enough to be able to be approved. I have talked about this with other add-on developers about this, and TBH these are some of the reasons why they just avoid publishing to Firefox. In general, they would rather not incur additional work that takes away from feature work.

#4

Here the Chrome policy:

Specifically, the full functionality of an extension must be easily discernible from its submitted code. This means that the logic of how each extension operates should be self contained. The extension may reference and load data and other information sources that are external to the extension, but these external resources must not contain any logic.