1803694 - Include unique ID connecting to default profile in `background-update` pings

Status: NEW

(Toolkit :: Application Update, enhancement, P3)

Description

[Nick Alexander :nalexander [he/him]]

Right now, background-update pings include the legacy Telemetry client ID of the default browsing profile, allowing to connect browsing to background updates (in a limited manner). Unfortunately, it's hard to connect subsequent events recorded by Desktop Glean to background updates because the background-update ping does not include the Glean client ID of the default browsing profile.

This ticket tracks including the Glean client ID of the default browsing profile.

The code that extracts the legacy Telemetry ID is BackgroundTasksUtils.readTelemetryClientID, but it's not clear how to extract the Glean client ID from an arbitrary profile. Alternatively, we might add these identifiers to the serialized targeting state written by Bug 1775138, although that's not as robust as I would like.

Comment 1

[Nick Alexander :nalexander [he/him]]

chutten: could you advise on extracting the Glean client ID?

Comment 2

[Chris H-C :chutten]

We've chatted about this and have found a workaround. Historically we've been reticent to permit the client_id to ever leave the SDK except in pings. Not locking that down has led to leaky abstractions and poor practices in legacy telemetry systems (anything from using it as a stable identifier across data opt out, to using it as an input in a sampling calculation) that Glean has so far been able to avoid.

It is true, though, that BUA is a new and special case. Other product with Glean don't have this "same binary: multiple app_ids" relationship that Firefox Desktop does with BUA. New situations may require new solutions, or revisiting old decisions.

But for now the data that's necessary is available to be queried and that appears to have unblocked things here.

For my part, I'll be keeping this case in mind as we plan 2023.

Comment 3

[Nick Alexander :nalexander [he/him]]

I'm changing the title of this ticket. While analyzing the results of a tricky roll-out (https://experimenter.services.mozilla.com/nimbus/backgroundupdate-enable-unelevated-installations-rollout-3-release), I found that connecting browsing profiles to background update profiles via background_update_client_id -- the legacy telemetry ID -- was not working out well. (Many were a placeholder GUID, and many were repeated many times across clients.) So I'd like to capture that we want a unique ID to try to make this easier in the future.

Comment 4

[Nick Alexander :nalexander [he/him]]

This identifier needs to make its way into background update tasks. The easiest way is to dump it into an app.update.background.* preference and then report it in the background update telemetry.