1819997 - Include new `dlsource` attribution field in Firefox telemetry environment, sibling to `dltoken`

Status: RESOLVED FIXED

(Firefox :: Installer, enhancement, P1)

Description

[Nick Alexander :nalexander [he/him]]

To determine where installations of Firefox originate, we intend to add a new attribution parameter, something like dlsource. This will capture special sentinel values like mozillaci for builds downloaded from archive.mozilla.org (and equivalents, such as ftp.mozilla.org) and bedrock for builds downloaded (via the stub installation service) via mozilla.org. See https://bugzilla.mozilla.org/show_bug.cgi?id=1814727#c11 for more details.

Firefox needs to report the new dlsource field. Technically, the client-side changes look just like those done for Bug 1756209. There's another piece here, however, which is that we also want to expose the dlsource field in various ETL pipelines. This looks like https://bugzilla.mozilla.org/show_bug.cgi?id=1694254 and https://bugzilla.mozilla.org/show_bug.cgi?id=1809197, I think.

This is the client-side part of Bug 1814727.

Comment 1

[William Durand [:willdurand]]

Attachment: Bug 1819997 - Allow `dlsource` in attribution data. r?nalexander!

Comment 3

[[e-mail] (:bhearsum)]

Attachment: data review request

Comment 4

[Chris H-C :chutten]

Comment on attachment 9324857 [details]
data review request

PRELIMINARY NOTE:

ni? :wildurand to confirm by "identifier" in "an identifier that indicate where installations of Firefox originate" you mean one of a fixed number of possible sources (as described in the bug description), not a UUID or other means to identify specific installers?

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 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, :bhearsum 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 2, Interaction.

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?

No.

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

Yes.

Does the data collection use a third-party collection tool?

No.

---

Result: datareview+

Comment 5

[William Durand [:willdurand]]

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

Comment on attachment 9324857 [details]
data review request

PRELIMINARY NOTE:

ni? :wildurand to confirm by "identifier" in "an identifier that indicate where installations of Firefox originate" you mean one of a fixed number of possible sources (as described in the bug description), not a UUID or other means to identify specific installers?

Sorry, yes. Identifier as in a unique string that indicates a possible source from a fixed and small list of possible values. Currently we have two possible values: mozorg and mozillaci. I added a gdoc with some more information to this bug.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/749c926deb21
Allow `dlsource` in attribution data. r=mixedpuppy

Comment 7

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/749c926deb21

Comment 8

[William Durand [:willdurand]]

Comment on attachment 9324833 [details]
Bug 1819997 - Allow dlsource in attribution data. r?nalexander!

Beta/Release Uplift Approval Request

• User impact if declined: To be clear, users won't be impacted if this request is declined.

The problem is that changes in other services (bedrock and stubattribution) are currently blocked until all builds support this new dlsource key. If we were to land/deploy those changes in the two services, the result would be that no attribution data would be collected in Telemetry. This is because Firefox drops all attribution data when an unsupported key is found, see Bug 1824130.

• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It is allowing a new attribution key.
• String changes made/needed:
• Is Android affected?: No

Edit: QE no longer required

Comment 9

[William Durand [:willdurand]]

Comment on attachment 9324833 [details]
Bug 1819997 - Allow dlsource in attribution data. r?nalexander!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is clearly not a critical bug for end users but...

The problem is that changes in other services (bedrock and stubattribution) are currently blocked until all builds support this new dlsource key. If we were to land/deploy those changes in the two services, the result would be that no attribution data would be collected in Telemetry. This is because Firefox drops all attribution data when an unsupported key is found, see Bug 1824130.

That's why I am requesting an ESR uplift, this patch is rather small and it would allow us to unblock work in progress in other services.

• User impact if declined: None
• Fix Landed on Version: 113
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch is covered by automated tests, it only allows a new attribution key.

Comment 10

[Dianna Smith [:diannaS]]

Comment on attachment 9324833 [details]
Bug 1819997 - Allow dlsource in attribution data. r?nalexander!

Approved for 112.0b9

Comment 11

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/8b961b648cf5

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9324833 [details]
Bug 1819997 - Allow dlsource in attribution data. r?nalexander!

Approved for 102.10esr.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/0e7d6d432e6c