1616884 - Instrument time between opt-out and opt-in if they happen in the same session

Status: RESOLVED WONTFIX

(Data Platform and Tools :: Glean: SDK, enhancement, P4)

Description

[Beatriz Rizental [:brizental]]

Whenever a user disables upload, a deletion-request ping is sent and local data is cleared. If the user reenables upload a new client id is created and the metrics recorded are completely unrelated to the previous ones.

I think this makes sense when disabling and enabling are far apart from one another, but if they are too close from each other I propose a different approach.

1. When the user disables telemetry, they get a warning saying that if they don't enable it again in X amount of time the data related to their client_id is going to be deleted from the Mozilla servers*;
2. If they enable it again before that amount of time is over, we just reinstate telemetry without reseting the client id and also cancel the previously sent deletion request;
3. If they enable it after that time, then it works just how it does now.

* Writing this down makes it look weird to me. The data collected by telemetry is not personal data and doesn't really have much use to the user. Depending on how this is worded it could look like that is not case, but it could also be an opportunity to have information right there educating our user as to how Mozilla collects data, why is it not personal, etc.

I am not sure if this is too much of an edge case, but I thought it was worth having a discussion.

Comment 1

[Mark Reid [:mreid]]

We considered this during the first round of Shredder work, and decided not to pursue it (yet) for two main reasons. First, intuitively I expect this to be a relatively uncommon case. Second, it would have added significant complexity in Firefox to stop or delay the rotation of the Client ID in order to be able to cancel a pending request. This would have made it riskier and likely take longer to ship.

I think a good step would be to check that first assumption and measure how often this occurs in the wild. If it's common, we should revisit this possibility.

Do we currently have a way to identify the first ping after opting back in?

Comment 2

[Chris H-C :chutten]

On Firefox Desktop we do: https://probes.telemetry.mozilla.org/?search=optin&view=detail&probeId=scalar%2Ftelemetry.data_upload_optin

Comment 3

[Beatriz Rizental [:brizental]]

Even if we know that the ping is the first ping after opting back in, we can't know who was the client that opted out before that. And because of that can't know if the client did that quickly. Can we?

Comment 4

[Mark Reid [:mreid]]

Looks like my intuition is bad in this case :)

https://sql.telemetry.mozilla.org/queries/68478/source#172957

This doesn't tell us anything about whether the opt-ins and opt-outs are the same clients (or whether they happened close together), but it does suggest that this work may be more impactful than I expected.

Comment 5

[Chris H-C :chutten]

(In reply to Beatriz Rizental from comment #3)

Even if we know that the ping is the first ping after opting back in, we can't know who was the client that opted out before that. And because of that can't know if the client did that quickly. Can we?

Correct. We could fix that by adding a timing scalar. Save the current time somewhere around here and then on optin record the delta between the two timestamps (as, say, seconds?) into a uint Scalar.

That way it's either:

• absent or large, which means the optout/optin pair took a while and we shouldn't debounce it even if we could
• present and small, which means the optout/optin pair happened within the same session and close together in time, so we should look into debouncing it

From there we can then learn whether debouncing is necessary, possible, and feasible.

Comment 6

[Mark Reid [:mreid]]

+1 for investigating along these lines.