The purpose of this document is to give an overview of the behaviour of the new Telemetry Reporting Policy.

This behavior replicates what FHR does now from Telemetry.

What happens on the first run with a new profile?

1. When Firefox starts and windows/tabs are restored, user is notified after a delay.

1. A notification bar is shown at the bottom of every opened Firefox window, even private ones.
2. As soon as the bar is shown, the user is assumed to have “acknowledged” of the policy.

1. The user is assumed to have acknowledged it even if he doesn’t close the notification or clicks on “Choose what I share” button.

2. Telemetry won’t start sending pings until the infobar was shown.
3. Once the notification is displayed, Telemetry is notified and can start sending pings.

What happens if the policy version is changed?

The same as above.

We use a “policy version” to reflect changes to our privacy policies etc.. If we have changes that require user consent, we can bump the “required policy version”, which triggers the infobar to be shown again.

When does data sending start?

• Only after the infobar was shown (which implies user consent here).
• This behaviour is common among all the channels.

When do we use this new behaviour/how does it interact with the telemetry.enabled pref?

Only when DRS is disabled and unified telemetry is preffed on.

How will this interact with the telemetry.enabled pref?

How should we structure the implementation?

We will add two new modules, one of them interacting with TelemetrySend, with the following responsibilities:

• TelemetryInfobar.jsm (new)

• builds and shows the infobar UI.
•  fires events on

• notification bar closed, use to notify other windows when closing the data choices infobar (so that they close their infobar as well)
• user click on the “Choose what I share” button - Not used
• notification displayed

• TelemetryReportingPolicy.jsm (new)

• decides if the user was notified or if he needs to be notified.
• Handles preferences migration (if needed) from FHR.
• Exposes a |canUpload| method which can be used by TelemetrySend to decide if data can finally be submitted to Mozilla servers.

• TelemetrySend.jsm

• checks with TelemetryReportingPolicy.jsm whether it can upload
• gets notified by TelemetryReportingPolicy when upload can start

Which preferences keep this stuff working?

• datareporting.policy.dataSubmissionEnabled [true]: is the data submission master kill switch. If disabled, no policy is shown or upload takes place, ever.
• datareporting.healthreport.service.firstRun [false]: if true, this is not the first run; if false, that’s the first run.

• datareporting.policy.firstRunTime [0]: records the date of the first time a data reporting policy was run.

• This is not really used anywhere, just in [7] even though a comment suggests it's used for scheduling [8]

• datareporting.policy.dataSubmissionPolicyNotifiedTime [0]: records the date user was shown the policy. {Also used on Android}

• datareporting.policy.dataSubmissionPolicyAcceptedVersion [0]: records the version of the policy notified to the user.

• datareporting.policy.dataSubmissionPolicyBypassNotification [false]: used in tests, it allows to skip the notification check.

• datareporting.policy.currentPolicyVersion [2]: stores the current policy version, this is only overridden in tests.

• datareporting.policy.minimumPolicyVersion [1]: the minimum policy version which for dataSubmissionPolicyAccepted to to be valid. This can be set per channel.

• datareporting.policy.minimumPolicyVersion.channel-beta [2]: this is the only channel-specific version that we currently use