mozilla-services
Sync hashed_device_id is incorrect
https://sql.telemetry.mozilla.org/dashboard/sync-backend-dau?p_end date=2024-12-30&p_start date=2024-12-27 shows we’re not receiving individual hashed_device_ids in our glean metrics: a COUNT(DISTINCT metrics.string.<field>) shows the exact same count for both syncstorage_hashed_fxa_uid and syncstorage_hashed_device_id whereas there should be an obvious difference with fxa_uids having 1 or more device_ids.
┆Issue is synchronized with this Jira Bug
➤ Philip Jenvey commented:
The culprit here is we’re hardcoding a device_id of basically “none” here ( https://github.com/mozilla-services/syncstorage-rs/blob/7c9bc0089dd73a9ecaba8b33e26634b2a69b5ff0/syncserver/src/tokenserver/extractors.rs#L647 ).
The comments around this code are correct: the BrowserID verifier ( https://github.com/mozilla/fxa/blob/ce114f7/packages/browserid-verifier/README.md ) result gave us back a fxa-deviceid in its idpClaims.
Whereas the oauth verifier does not return a device_id ( https://mozilla.github.io/ecosystem-platform/api#tag/OAuth-Server-API-Overview/operation/postVerify ). So we did have access to device_id for solely BrowserID clients in the past, with support for BrowserID removed the hardcoding of “none” occurs for all clients.
➤ Philip Jenvey commented:
This is on hold, blocked on FxA adding a new feature to provide a device_id in the response from the oauth verifier. Per a slack conversation:
{quote}ddurst: in SYNC-4591 ( https://mozilla-hub.atlassian.net/browse/SYNC-4591 ), we see that we used to get a device_id (hashed) from the browserID verifier. Now that there's no verifier, can we get the device ID via the oauth verify? How hard would that be?
bchen: maybe for certain oauth clients when they fetch an oauth access token with a fxa session token (firefox/sync does this the last time I looked), we'll include the session's associated device id in the claims. not that hard. but it's got a few moving parts and it involves the busiest endpoints on fxa (/token and /verify) so I think we'll probably wanna move carefully.{quote}