AMO requires opt-in for DNSLink lookups

[lidel]

We've received ask from Mozilla's Add-Ons website to add explicit opt-in for using local IPFS node for DNSLink lookups:

All data sent to any services outside the add-on itself is considered as remote, localhost or not.

We will ask you to consider the opt-in function.

Solutions

So far I see two ways of addressing this.

Option A

We could add opt-in for DNSLink lookup feature, and display balloon the first time DNSLink resolution is requested:

Option B

Right now, when a local IPFS node is detected we show "success" and start using it without any consent:

We could tweak onboarding process a little. Change text on Welcome screen, or even start entire extension in "disabled mode" by default and add a global opt-in to Welcome Screen:

• It would inform user that they need to agree for sending some information to local/remote IPFS node in exchange for specific functionality (node being able to resolve DNSLink, redirect to local gateway etc)
• This may be better in the long run, solving consent globally, not just for DNSLink, and in a way that does not degrade overall UX.
• If user closes Welcome page, extension remains in "disabled" state, and if user enables it via browser menu action without prior consent, Welcome/consent page is displayed again.
  • key here is that the consent needs to happen on a page that explains what data is sent where and why

Option C

Please write down in comments below, if you see other way of solving this, ideally without compromising UX too much :)

Copy of AMO Review

Below is full exchange published for transparency, and also to show how detailed Mozilla's review and feedback is, especially when compared to other browser vendors.

This is a chore for me as a developer, 😬
but I really appreciate this level of care as a Firefox user! ❤️

AMO:

We found out that you were sending current tab URL to remote servers.
Is there any consent from the user about this personal data sent?

Click to expand

@lidel:

Are you able to clarify, point specific code lines that raised your concern?
current Tab should not be sent to remote servers:
our browser extension redirects IPFS resources to IPFS node of user's choice, by default it is localhost
(URL endpoints can be changed in Preferences)

AMO:

This is only one of examples we found:

From add-on\src\lib\dnslink.js - L.126 - readDnslinkFromTxtRecord function: You are inserting fqdn attribute into the URL attributes.

Previous function is used in add-on\src\lib\dnslink.js - L.70 - readAndCacheDnslink function: fqdn in attribute of the function

Previous function is used in add-on\src\lib\dnslink.js - L.206 - findDNSLinkHostname function: hostname is coming from "url" attribute of the function

Previous function used in add-on\src\lib\ipfs-companion.js - L.230 - sendStatusUpdateToBrowserAction function: url variable is initialized with info.currentTab.url which is initialized with browser.tabs.query({ active: true, currentWindow: true }).then(tabs => tabs[0])

So in conclusion current tab URL is sent to a remote service of the add-on. Tab URL is considered as personal data. Please be aware of other cases.

This requires affirmative consent from the user (i.e., explicit opt-in from the user). It must be clear to the user that they give consent to the collection of personal and ancillary data.

The consent page should be shown at install time and contain choices accompanied by the data collection summary, choices, which should be disabled by default.

Here is an example of how to create a page within the add-on https://blog.mozilla.org/addons/2016/07/15/writing-an-opt-in-ui-for-an-extension/.

Also, the summary of the data collection should be mentioned in the add-on description and privacy policy.

For more information, refer to https://extensionworkshop.com/documentation/publish/add-on-policies/#Data_Disclosure_Collection_and_Management

@lidel

Thank you for the details, very helpful!
I see how code related to resolving DNSLink raised your concerns.
Let me clarify what happens and when.

By default, our browser extension requires user to run local IPFS node:

GUI: https://github.com/ipfs-shipyard/ipfs-desktop
or CLI: https://github.com/ipfs/go-ipfs

DNSLink (https://dnslink.io) is a convention for storing content-addressed pointers in DNS TXT records.

Unfortunately WebExtension APIs do not support lookups of TXT record types (https://bugzilla.mozilla.org/show_bug.cgi?id=1449171) so we delegate DNS TXT resolution to user's IPFS node running on localhost (example: http://127.0.0.1:5001/api/v0/dns/en.wikipedia-on-ipfs.org).

This means by default the current tab URL never leaves user's machine, all we do is checking if DNS TXT record exists for entire domain using regular DNS lookup

and as we noted in our Privacy Policy (https://github.com/ipfs-shipyard/ipfs-companion/blob/master/docs/privacy-policy.md) we don’t collect any Personal Data.

We are very careful about keeping the default settings limited to localhost.

The only time hostnames could be sent to a remote server is when user made an EXPLICIT OPT-IN via Preferences: changing HTTP Gateway/API URLs or enabling one of experiments.

For example, one can opt-in to try experimental embedded js-ipfs node type via Preferences, which uses ipfs.io gateway, as noted under "Read more" at https://github.com/ipfs-shipyard/ipfs-companion/blob/master/docs/node-types.md

Let us know if this answers your concerns about the default state, or if we should improve docs / labels related to opt-in functions.

AMO

All data sent to any services outside the add-on itself is considered as remote, localhost or not.

We will ask you to consider the opt-in function.

[autonome]

+1 to Option B to do a global opt-in on install.

I don't think it should disable extension UI everywhere though.

Instead, accessing any companion extension UI should bring up the opt-in prompt.

Should not be tied to local daemon presence/absence.

[lidel]

Update: AMO revisited our case, and seems that our welcome screen and the need for explicit install of ipfs-desktop or go-ipfs is enough barrier for now 👍

Reviewer Reply by Hubert about 3 hours ago

After some talk we decided that for this specific case opt-in was not a necessity.

However, for the future, be aware that any personal data collection is requesting an opt-in as explained here: https://extensionworkshop.com/documentation/publish/add-on-policies/#data-disclosure-collection-and-management

We may still need to do explicit opt-in at some point, as Chrome Web store gets more and more strict (#808), but closing this as resolved for now.