1635507 - Consider expiration for default browser agent scheduled task

Status: RESOLVED FIXED

(Firefox :: Installer, enhancement, P3)

Description

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Currently the default browser agent will run approximately every 24 hours, exiting without doing anything if prefs or policies forbid it. We could turn the pref off with Normandy or other mechanisms if we decide to disable the agent. However, if Firefox doesn't run, then those prefs won't be changed.

I'm proposing that we could set a range of time in which the scheduled task will be active, so that if the task isn't refreshed by an update (which should happen if Firefox is running regularly), the task will eventually expire. This should be as simple as setting the EndBoundary field on the task, since we recreate the task on every update.

This also prevents the task from continuing to run forever if the user has an install of Firefox that never runs, in which case we probably shouldn't keep running this task. The expiration date should probably be at least the current date + twice the release cadence to allow for delay in acquiring updates.

Arguments against:

• This will have to be taken into account when analyzing telemetry.
• This simple method won't work once the update agent is deployed, as updates will always be installed whether Firefox has run or not. But we could completely remove the agent in an update if we decide to disable it.

Comment 1

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

:rharter, this would mean that pings would drop out after a while instead of continuing for as long as the browser is installed, if it is never run or updated. Would this unnecessarily complicate the data analysis?

Edit: To be clear, I just mean the default browser agent pings, this won't affect any other telemetry.

Comment 2

[Ryan Harter [:harter]]

This isn't ringing any alarm bells for me.

IIRC, the primary reason for this telemetry is to identify churned users. Stopping the ping after a couple of months of inactivity seems totally reasonable.

In fact, since the ping does not include a client identifier, it's probably better that the ping stops eventually. Otherwise, we'll accumulate a large number of inactive users over time.

It would probably be useful to include a client identifier and some time since last run measurement as well.

Comment 3

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Great, thanks!

(In reply to Ryan Harter [:harter] from comment #2)

It would probably be useful to include a client identifier and some time since last run measurement as well.

It's not going to be simple to get either of those from the agent, and the client ID may not be appropriate for this opt-out background ping.

Comment 4

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

ESR may complicate this as it has a release cadence officially at 42 weeks, vs 4-6 week for normal release. I had thought it might be simple to give ESR a much longer expiration (~1 year), but given that the agent is built outside of the normal build process we really don't have direct access to the update channel. It might be possible to get this out of the version in the registry with some effort, but then things start to get more complicated.

There may be other mechanisms, like looking for "time since last run" somehow (as suggested in comment 2, perhaps looking at the timestamp on the reflected pref in the registry), but that again starts to add complexity.

Comment 5

[Ryan Harter [:harter]]

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #3)

client ID may not be appropriate for this opt-out background ping.

Getting a client_id for the background ping is likely critical to making decisions with these data. I've discussed this with :rtestard separately, but it feels worth mentioning here as well. The client_id does not necessarily need to be the same id reported by telemetry.

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #4)

ESR may complicate this as it has a release cadence officially at 42 weeks, vs 4-6 week for normal release. I had thought it might be simple to give ESR a much longer expiration (~1 year)

This would probably complicate the metric interpretation. Extending the expiration for ESR users will cause ESR to be overstated in our metrics. We'd need to either keep expiry the same for all users or include a reliable time since last run.

Comment 6

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #4)

given that the agent is built outside of the normal build process we really don't have direct access to the update channel

I misremembered, the agent is built using the normal build process. (Probably irrelevant as it sounds like we don't want to have different expiration lengths anyway.)

(In reply to Ryan Harter [:harter] from comment #5)

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #3)

client ID may not be appropriate for this opt-out background ping.

Getting a client_id for the background ping is likely critical to making decisions with these data. I've discussed this with :rtestard separately, but it feels worth mentioning here as well. The client_id does not necessarily need to be the same id reported by telemetry.

Ok, I wasn't aware of these discussions.

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #4)

ESR may complicate this as it has a release cadence officially at 42 weeks, vs 4-6 week for normal release. I had thought it might be simple to give ESR a much longer expiration (~1 year)

This would probably complicate the metric interpretation. Extending the expiration for ESR users will cause ESR to be overstated in our metrics. We'd need to either keep expiry the same for all users or include a reliable time since last run.

I'll see if I can get a good proxy for time since last run. If it doesn't rely on the expiration being reset with updates, then it would be reasonable to have the same expiration length for all channels.

Comment 7

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Timestamp on the reflected pref won't work, directly. Even though this is written on every startup, the timestamp on the key only updates if the key or its values have actually changed.

Comment 8

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: Bug 1635507 - Don't do task after 90 days since last app run. r?mhowell!,bytesized!

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:agashlin, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 10

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

I marked the patch "Changes Planned" as I'll need to rebase it on top of other pending WDBA work.

Comment 11

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

I'm revisiting this, I think it would be good to have the agent also unregister its scheduled task if it detects expiration, rather than continuing to run just to exit after checking the timestamp. If Firefox hadn't run for the 90 day expiration period, then when/if it runs again it will likely need an update, and the post-update will re-register the task (since the "Installed" registry value will still be present).

Comment 12

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Unregistering the task isn't going to be as straightforward as I'd hoped, the running task doesn't have the needed permissions to remove itself (I didn't notice this in early testing on Windows Sandbox, I think because UAC is turned all the way down). I'll leave the task exiting immediately for now.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ee24e6245189
Don't do task after 90 days since last app run. r=mhowell,bytesized

Comment 14

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/ee24e6245189