To support the upcoming download token efforts, we'll need to:

1. Include the download token in the install ping
2. Include token in at least one post-install ping

We'll probably want to ensure we're clear on how we get this download token to start with - assuming via attribution params, but worthwhile to confirm that as well before we start with the bedrock team.

Generated with npm run-script bundle:webpack

Depends on D100969

Comment on attachment 9195911 [details]
dltoken_data_review.md

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, Rob Miller is responsible.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 4, Clearly Identifiable

Is the data collection request for default-on or default-off?

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

Yes.

Is the data collection covered by the existing Firefox privacy notice?

I don't know.

Does there need to be a check-in in the future to determine whether to renew the data?

No. This collection is permanent.

Result: datareview-

ni?elitka for Privacy -- Is adding a new ID linked to all of Telemetry ok?

(Kirk, is this id gonna be saved and provided in the Environment forever, or just for pings submitted in the first session?)

(In reply to Chris H-C :chutten from comment #4)

(Kirk, is this id gonna be saved and provided in the Environment forever, or just for pings submitted in the first session?)

All the other attribution data goes in the Telemetry Environment, so I was going to put this there too. So not just for pings submitted in the first session. But if makes a difference, I can reconsider how the telemetry is sent.

To be clear the data-review- is only pending a review from Privacy. It's possible that the data will be deemed acceptable, but no Steward can rule on that.

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #5)

(In reply to Chris H-C :chutten from comment #4)

(Kirk, is this id gonna be saved and provided in the Environment forever, or just for pings submitted in the first session?)

All the other attribution data goes in the Telemetry Environment, so I was going to put this there too. So not just for pings submitted in the first session. But if makes a difference, I can reconsider how the telemetry is sent.

It might make a difference (or it might not because it will be associated with the client_id so can be extended through time on the analysis side if we wanted to). I was getting this information in place in case it'd help Emily make her determination.

Come to think of it, will this token be erased when the user opts out of data reporting? Otherwise it could be used to link client_ids across a reset.

One note, in case it's not already clear: The download token will be available in the telemetry environment, but all web session data that it is linked to will NOT ever be included in telemetry, it is being deliberately kept in a separate data set, and we will be limiting access to the ability to join these data sets to a small set of people.

Come to, think of it, will this token be erased when the user opts out of data reporting? Otherwise it could be used to link client_ids across a reset.

This is a good question. We don't yet have plans to delete the token, but we can look into having this happen in certain cases. There's a wrinkle, however... there will not be a 1:1 correspondence btn download tokens and client ids, and in fact we suspect that there will be cases where a single download token will correspond to hundreds or possibly thousands of separate clients (because we suspect that a large portion of our 'unattributed funnel' is the result of other actors downloading a single Firefox installer and re-hosting that for download by other users). It would not be desirable nor privacy enhancing to delete the download token in cases where a large (for some definition of 'large') number of clients are associated w the same token.

Approving this for nightly. Will circle back on release / it also sounds like, based on the previous comments, there's some details to iron out.

Approving for beta. Not yet approving for release - I will followup shortly on this. Thanks

The download token team had a meeting today in which it was decided that we ought to land this patch with the telemetry enabled for all channels and uplift a removal of the patch if we don't get privacy approval in time for Release.

I notice that we still have a data-review- on this patch.
@chutten Do we have the permission of the data stewards to go through with this plan?

Oh. Apparently we have already changed our plans to wait for full approval. Never mind.

Yes, if we get Privacy approval by Soft Freeze on Thursday, Jan 21, we will move forward with landing it in Fx86 Nightly. A decision is pending.

Approving this for release channels. Please check in with legal/privacy in 6 months time to validate (a) that the data is useful, and (b) whether our GA service is collecting materially new data. Thanks!

the data-review- is only pending a review from Privacy.

Now that Privacy has reviewed this (comment 13), could you take another look at the data-review status here? Thanks!

Comment on attachment 9195911 [details]
dltoken_data_review.md

Approval granted by Privacy. Good to go.

https://hg.mozilla.org/mozilla-central/rev/e84aa5bced3c
https://hg.mozilla.org/mozilla-central/rev/10183e73c231