Collect additional user consent in privacy-sensitive contexts

[chuckharmston]

In cases where users have privacy.trackingprotection.enabled or privacy.donottrackheader.enabled set to true, or have network.cookie.cookieBehavior set to 4, the "no products" screen should have some additional messaging clarifying that tracking a product will result in the extension making regular requests to the product page on the user's behalf.

@bryanbell would you mind helping us out with that UI here?

This will block launch per @groovecoder.

[biancadanforth]

@chuckharmston The current behavior of the extension (#72 (comment)) is not to perform background extraction in these contexts, so I don't think this is blocking if #186 is not blocking?

[chuckharmston]

Even if it doesn't functionally block launch, ensuring that users consent to this from the beginning will ensure that we don't need to collect any retroactive consent in the future.

[Osmose]

Re-read this and did some thinking:

• The summary describes adding additional context to the "no products" screen, but the issue title describes collecting consent. Are we prompting the user for a yes/no consent, and blocking their ability to save products until that happens?
• What if the user does not consent? Can they still add products to their list, and we just don't update them in the background?
• What happens if a user enables these preferences after using the add-on for a bit? Do we block their access to the rest of the UI until they consent? We can't use the empty listing UI in this case as they will have already saved some products.

At a glance I'm pretty worried about time to implement this; there's too many questions and too many branches of behavior for me to be confident that we can land this by next week.

---

Backing up a bit, I'm iffy on focusing on gathering a specific consent from users with privacy settings set a certain way. It makes more sense to me to simply gather this consent and/or make it clear in our onboarding that use of the add-on itself incurs background page loads regardless of privacy settings. The lowest-effort version of this is an extra paragraph in the onboarding:

We could pair this with a clarification on the Test Pilot page where users install the add-on as well.

Increasing in complexity, we could add a yes/no consent form that uninstalls the add-on if the user doesn't consent to background updates. More complex than that would be to have "No" set an add-on setting that disables background price updates, with a message afterwards pointing them to the add-on's settings page if they want to enable them later on.

@chuckharmston @groovecoder Thoughts?

[chuckharmston]

This was effectively exactly what I was imagining. With approval from @groovecoder and short any better guidance from @bryanbell, I'm comfortable shipping this.

We could pair this with a clarification on the Test Pilot page where users install the add-on as well.

This already exists here: mozilla/testpilot#3913

[Osmose]

I'm gonna give this until Wednesday before we implement the backup plan from my comment above.