1651497 - Sync ping devices list contains many devices without `os`/`version` info

Status: NEW

(Firefox :: Sync, defect, P3)

Description

[Thom Chiovoloni [:tcsc] (ex-moco)]

In bug 1639838 we stopped filtering the ping devices list, however the info we include about (most of) the previously filtered devices is just their device ID and device type field.

There are a number of issues with this.

1. Those devices are entirely useless in the context of analyzing event telemetry, which is the problem that bug is attempting to address.

2. The presence of these unfiltered devices would make it almost impossible to do other sorts of analysis we might want to do in the future. My personal device list now contains a huge number of entries, going back multiple years and including multiple device-registration-induced duplicates (in https://bugzilla.mozilla.org/show_bug.cgi?id=1639838#c10 I go into more deftails about this). Specifically, previously the list would have been able to answer questions about:

   • how many other devices the user is actually using, and what they're types are.
   • whether or not these bookmark validation problems are correlated with having mobile devices.
   • ...

These are really two separate issues, but I think they're probably related (that said, you could imagine solutions to number 2 that involve include usage timestamps which would solve that issue but not the first)

---

Essentially my feeling here (which you can disagree with):

• For sync users we should try very hard to avoid sending devices in the device list which have no os/version info

• For all users (but especially non-sync users), we should try very hard to include irrelevant devices in that list, where irrelevant means something like "could not possibly influence any sort of analysis we might want to do".

  • My personal devices list contains: 20 devices 2018, 4 from 2019, and 2 from 2017. These all seem very much irrelevant.

Strawman solution

Note: This is more intended to be a starting point for discussion than what the algorithm should definitely be.

1. Bring back at least age-based filtering, but modify it so that it cannot filter devices whose id appears in the events list.

2. If we are a sync user and are going to include device record with no os/version info, try and resolve that:

   • If they're not a sync user, nothing can be done.

   • Otherwise, try to dedupe it using something like:

     • Clients engine info like staleness and such (I believe it knows this for some cases, but would have to check again to remember the details).

     • If device name is identical to a device whose info we have, we use its info. (This is a little dodgy, so if we expect the clients engine approach to be reliable, we should stick with that)

Thoughts?

Comment 1

[Mark Hammond [:markh] [:mhammond]]

I think the requirements here are fairly simple:

• It should be impossible for telemetry to not have a device that is shown in any UI. It's also OK (if not ideal) for it to have devices which aren't shown in UI - so to be safe, telemetry should record the exact same list the /devices end-point returns. To put it another way, telemetry itself should never filter even if some UI components do.

• all devices which have sync client records should include os and version info, even if the sync code considers that device "stale". These days, the sync code considering devices as stale doesn't make sense - send-tab targets need not be sync devices, so if any filtering is done, it should be at the fxa device level, not the sync client record level.

• any future analysis should not assume attributes which are supplied by sync rather than fxa. If sync supplied attributes are critical, we need an fxa bug so they are provided by FxA.

Comment 2

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:eoger, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:lina, could you have a look please?

For more information, please visit auto_nag documentation.