On 24/1/17 17:01, Mark Hammond wrote: > On 24/01/2017 4:55 PM, Ryan Kelly wrote: >>> The first steps to that were to put the FxA client ID into client >>> records (e.g., Bug 1254640, Bug 1250782), but there's a lot of work >>> still to do, and I'm not aware of any bugs on file that track it. >> >> TBH I'm not sure what the next steps are to move this forward. Could we >> e.g. gather some telemetry from clients on how frequently there are >> discrepancies between the two lists? > > IIUC, a practical problem is that the FxA device ID doesn't survive > across reauthentication - ie, the device ID changes whenever the session > ID does.
Aha, well this sounds like a good place to start :-) >> Let's drill down into this a little. Are you seeing a discrepency >> between the FxA device list and the send-tab device list on your current >> setup? If so then that's a great place to start, let's file it as a bug >> in bugzilla for further discussion. > > The discrepancies I see tend to be duplicate devices caused by reauth, > and no clear path in that context for "revoking" the earlier device ID. > This is obviously less of a problem if we can make the deviceID persist > across re-auth (and maybe a way to handle that would be to allow the > client to specify the device ID?) Or maybe a way so the device > registration process to take the local sync device ID as part of the > registration body and allow the FxA server to use that as a lookup to > reuse the original deviceID? I'm on board with having the client submit a "fingerprint" that the server can use for deduplication, along the lines of: https://github.com/mozilla/fxa-auth-server/issues/1077 This could be the sync client-id, or a hardware info hash, or whatever makes sense from the client's perspective. Ryan _______________________________________________ Dev-fxacct mailing list Dev-fxacct@mozilla.org https://mail.mozilla.org/listinfo/dev-fxacct
