Additional checkbox for preferences to give users finer control of sharing study data

RESOLVED FIXED

Status

Shield
Add-on
RESOLVED FIXED
4 months ago
3 months ago

People

(Reporter: mheubusch, Assigned: mkelly)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 months ago
While opt out shield studies at present conform to the telemetry data setting (Allow Mozilla to collect technical and interaction data) we decided that in the interest of user choice and transparency we should offer an additional setting that would allow users to continue to send telemetry data but opt out of studies, rather than limiting them to a share all/share nothing binary.

We are proposing that indented below the telemetry option we offer a checkbox that says: 
[ ] Allow Firefox to install and run studies View Firefox Studies 

Note: View Firefox Studies links to the about:studies page in development

This option will be checked by default. If the user unchecks telemetry this will also be unchecked and greyed out. If the user rechecks telemetry the study option become available for selection and will be rechecked by default. 

In addition, this control should also govern:
1. If a user unchecks the opt-out studies box that they not be prompted to participate in opt-in studies
2. That this box govern both shield studies and telemetry studies
Flags: qe-verify+
QA Contact: hani.yacoub
Whiteboard: [photon-preference][triage]
Target Milestone: --- → Firefox 56
(Assignee)

Comment 1

4 months ago
The pref name we'd like to use is app.shield.optoutstudies.enabled, as a boolean pref defaulting to true.

Comment 2

4 months ago
hi Tina, Cindy,

i would like to have your comment for this one.

thank you very much
Flags: needinfo?(thsieh)
Flags: needinfo?(chsiang)

Comment 3

4 months ago
yes Michelle mentioned this during the work week.
Flags: needinfo?(chsiang)

Comment 4

4 months ago
wait for Tina to confirm if spec will be updated.
Hi Francis,
Michelle and I had a discussion for this option last week. I've added the option to the updated reorg spec: https://mozilla.invisionapp.com/d/main#/console/10198964/237159280/preview

Feel free to let me know if you have any questions.
Flags: needinfo?(thsieh)
This option offers users a choice to opt out of studies, so it will be good to expose it in 56. @Francis, could you please let us know if 56 is a possible target? If not, 57 is still an alternative target.
Flags: needinfo?(frlee)
(In reply to Michael Kelly [:mkelly,:Osmose] from comment #1)
> The pref name we'd like to use is app.shield.optoutstudies.enabled, as a
> boolean pref defaulting to true.

Hi Michael,

What's the schedule of the backend that would hook up to this pref? I don't see any bug being referenced here... we shouldn't ship the UI without the actual code reading the pref right :)?

This is quite trivial to add and should be done on top of bug 1365133, which is very close to land. Would you like to have your team to take it on instead? If not we can try to find spare some cycles for this.
Depends on: 1365133
Flags: needinfo?(frlee) → needinfo?(mkelly)
Whiteboard: [photon-preference][triage]
(In reply to Tina Hsieh[:Tina_Hsieh] UX from comment #5)
> Hi Francis,
> Michelle and I had a discussion for this option last week. I've added the
> option to the updated reorg spec:
> https://mozilla.invisionapp.com/d/main#/console/10198964/237159280/preview
> 
> Feel free to let me know if you have any questions.

Sorry for posting a wrong URL! Here is the shared link: https://mozilla.invisionapp.com/share/P4ACQT1E3#/237159280_5-3_Privacy_-_Security
(Assignee)

Comment 9

4 months ago
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #7)
> (In reply to Michael Kelly [:mkelly,:Osmose] from comment #1)
> > The pref name we'd like to use is app.shield.optoutstudies.enabled, as a
> > boolean pref defaulting to true.
> 
> Hi Michael,
> 
> What's the schedule of the backend that would hook up to this pref? I don't
> see any bug being referenced here... we shouldn't ship the UI without the
> actual code reading the pref right :)?

I've added the tracker bug for the feature (although most of the implementation bugs are issues in Github, the tracker explains how to see those) as being blocked by this.

The current schedule is to ship in the Shield system add-on the week of August 14th as a system add-on update in 55, and land built-in in 57. 

The original plan was, in fact, to ship the UI before it was being used, since in normal operation where we run studies on small samples of users most users will not be running any studies anyway. More relevant, though, is that Shield is a system add-on, and could be uninstalled by the update system (if it was breaking Firefox in some critical way, for example) without updating the Firefox version. 

The link in the mockups to the listing itself might break in a case like this, because the about:studies page it would link to might not exist. We should either:

1. Just be aware of this potential (but pretty unlikely) breakage and be okay with it.
2. Remove or replace the link to the study page. 
3. Get super complex about it and have some API for the system add-on to control whether that link/this preference appear. IMO this is the least desirable option.

> This is quite trivial to add and should be done on top of bug 1365133, which
> is very close to land. Would you like to have your team to take it on
> instead? If not we can try to find spare some cycles for this.

Either is fine. Doing it on top of that bug sounds like the easiest way forward, but I'm happy to take it on if you find yourselves crunched for time.
Blocks: 1370799
Flags: needinfo?(mkelly)
(In reply to Michael Kelly [:mkelly,:Osmose] from comment #9)

Thanks for the prompt reply.

Understanding your schedule and the vehicle (system addon) is actually quite important here. So there is already another add-on that inserts it's own pref into the Preferences page. You should be able to do the exactly the same and add the pref into both the old Preferences page and the new one.

http://searchfox.org/mozilla-central/source/browser/extensions/formautofill/FormAutofillPreferences.jsm

For 55 I would image you would need to deploy the system add-on with hard-coded English strings so there is no string change breakage (unless there is already another l10n project setup for Shield?). For 56 once bug 1365133 lands the system add-on can modify the DOM and insert the UI accordingly.

This is unfortunately quite close to (3) as you suggested and it undesirable for you. Yet I think it's important to keep system add-on functionality self-contained so you can enjoy it's flexibility (for solving the link issue you montioned).

Do you think this is something your team can work on your own? That would save us a lot of overhead on coordnating and stuff. Please do reach out to the Form autofill team for technical specifies.
Flags: needinfo?(mkelly)
(Assignee)

Comment 11

4 months ago
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #10)
> (In reply to Michael Kelly [:mkelly,:Osmose] from comment #9)
> 
> Thanks for the prompt reply.
> 
> Understanding your schedule and the vehicle (system addon) is actually quite
> important here. So there is already another add-on that inserts it's own
> pref into the Preferences page. You should be able to do the exactly the
> same and add the pref into both the old Preferences page and the new one.
> 
> http://searchfox.org/mozilla-central/source/browser/extensions/formautofill/
> FormAutofillPreferences.jsm
> 
> For 55 I would image you would need to deploy the system add-on with
> hard-coded English strings so there is no string change breakage (unless
> there is already another l10n project setup for Shield?). For 56 once bug
> 1365133 lands the system add-on can modify the DOM and insert the UI
> accordingly.
> 
> This is unfortunately quite close to (3) as you suggested and it undesirable
> for you. Yet I think it's important to keep system add-on functionality
> self-contained so you can enjoy it's flexibility (for solving the link issue
> you montioned).

The key upside here is that the code lives in our system add-on. (3) is mostly undesireable if the "enable/disable" code lives inside mozilla-central, because keeping it in sync with the add-on is tough.

> Do you think this is something your team can work on your own? That would
> save us a lot of overhead on coordnating and stuff. Please do reach out to
> the Form autofill team for technical specifies.

I think so. Let's move this to the Shield component since it'll land inside our add-on.
Component: Preferences → Add-on
Flags: qe-verify+
Flags: needinfo?(mkelly)
Product: Firefox → Shield
Target Milestone: Firefox 56 → ---
Superb. Thanks for sorting this out.
(Assignee)

Updated

3 months ago
Assignee: nobody → mkelly

Comment 13

3 months ago
Commit pushed to master at https://github.com/mozilla/normandy

https://github.com/mozilla/normandy/commit/f3cc81b3f7d1fb4e39a119e76a968894dbc719e9
Fix bug 1377192, Fix #741: Add global opt-out checkbox to preferences.

Updated

3 months ago
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.