1964544 - [meta] Rename ToU datareporting.policy.dataSubmissionPolicy* prefs

Status: VERIFIED FIXED

(Firefox :: Messaging System, task, P1)

Description

[Chris Peterson [:cpeterson]]

We current record that the user has accepted the ToU using the datareporting.policy.dataSubmissionPolicyNotifiedTime and datareporting.policy.dataSubmissionPolicyAcceptedVersion prefs. Bobby recommends some changes to these prefs

1. Prefs tracking ToU acceptance and prompt bypass are appropriately-named (i.e. they say termsofuse and don’t have any mention of “data reporting”)
2. Not having the legacy telemetry control be renamed to have “ToU” in it
3. Not having any of this stuff gated by MOZ_DATA_REPORTING as it currently is.
4. Nice-to-have: straightforward name and function, dropping “policy version”

The new prefs should carry forward the old pref values for users that have accepted the ToU.

Comment 1

[Meg Viar [:mviar]]

Attachment: Bug 1964544 - Update ToU flow to use its own set of prefs and remove gating related to data reporting

Comment 2

[Chris Peterson [:cpeterson]]

We don't need to uplift this pref change to 139.

How will these pref changes affect the enterprise policy flag to pre-accept ToS (bug 1954128) or sync the ToS acceptance state across multiple and new user profiles (bug 1933264)?

Or the Nimbus advanced targeting for users who haven't accepted the ToU yet? https://github.com/mozilla/experimenter/pull/12596#issuecomment-2859412454

Comment 3

[Meg Viar [:mviar]]

This should also update the ToS enterprise policy and prefs shared across profiles.

We'll need some clarification on whether or not accepting ToS should still update the legacy datareporting.policy.* prefs in addition to setting the new ToS specific prefs.

Comment 4

[Chris Peterson [:cpeterson]]

QA request to test the pref migration: https://mozilla-hub.atlassian.net/browse/QA-3988

Comment 5

[Chris Peterson [:cpeterson]]

Meg recommends that we land and test these new prefs in Nightly 141 instead of 140.

Comment 6

[Rares Doghi, Desktop QA]

Updating the flag for Nightly 141.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

One concern that came up in the #tos-new-users Slack and one of meetings: could the fact that it's possible for new version numbers to be the same as (or less than) old version numbers make it harder to detect if there are weird bugs & edge cases that we haven't thought of? If, instead, we started the new version number at (say) 4, there's no overlap - anything that shows up in the telemetry as less than four is an anomaly/bug, and the numbers in a given profile should never go backwards. Meg, what are your thoughts here?

Comment 8

[Meg Viar [:mviar]]

(In reply to Dan Mosedale (:dmosedale, :dmose) from comment #7)

One concern that came up in the #tos-new-users Slack and one of meetings: could the fact that it's possible for new version numbers to be the same as (or less than) old version numbers make it harder to detect if there are weird bugs & edge cases that we haven't thought of? If, instead, we started the new version number at (say) 4, there's no overlap - anything that shows up in the telemetry as less than four is an anomaly/bug, and the numbers in a given profile should never go backwards. Meg, what are your thoughts here?

I think that's a good idea Dan, and I don't see any risk associated with doing so. I can update the patch accordingly.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

@mviar It occurs to me just now that we will also need to update the advanced targeting as well, but it should a very trivial update.

Comment 10

[Meg Viar [:mviar]]

@dmosedale yes, good call out there. I filed an issue to update here.

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

@mviar Did we ever get any feedback on comment 3?

Comment 12

[Meg Viar [:mviar]]

No official decision here, though I've moved forward with the assumption we do not want to keep the legacy prefs set to the old values so that we can differentiate users who have accepted TOU, the legacy data reporting policy, or both.

NIing Chris and Venetia to see if they have thoughts and otherwise will raise in this week's sync.

Comment 13

[Chris Peterson [:cpeterson]]

(In reply to Meg Viar [:mviar] from comment #3)

We'll need some clarification on whether or not accepting ToS should still update the legacy datareporting.policy.* prefs in addition to setting the new ToS specific prefs.

(In reply to Meg Viar [:mviar] from comment #12)

No official decision here, though I've moved forward with the assumption we do not want to keep the legacy prefs set to the old values so that we can differentiate users who have accepted TOU, the legacy data reporting policy, or both.

We do not want to set or leave the legacy prefs in the user's profile. We want users to only see the new pref names in about:config. Of course, the code will still need to know about the legacy pref names to implement the pref migration.

Comment 14

[Vtay]

Agreed.

Comment 15

[Rares Doghi, Desktop QA]

Updating the flag for 142

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/c851356e72c0
https://hg.mozilla.org/integration/autoland/rev/0c5a18d39544
Update ToU flow to use its own set of prefs and remove gating related to data reporting r=profiles-reviewers,omc-reviewers,dmose,webdriver-reviewers,jhirsch

Comment 17

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/0c5a18d39544

Comment 18

[Rares Doghi, Desktop QA]

Verified as fixed in our latest Nightly build 142.0a1 (2025-07-14)

Comment 19

[Rares Doghi, Desktop QA]

Updating the main status flag.