FEATURE: a "sync status" control dashboard about fxa HOT 7 CLOSED

a list of devices and the time they last synced

I believe this information is available in the records in the "clients" collection, but it's encrypted.

a count of the number of items stored of each type, and the total size of your stored data.

This information is available unencrypted from the sync storage node. However, to access the sync storage node you need to authenticate to the tokenserver, and that requires you to specify a hash of the user's kB.

from fxa.

I'd like to see a list of all the things we could potentially display:

• last sync time-stamps
• device name
• storage size
• count of items per data type
• histogram of fetches?
• time of oldest data?

Option A: all client side work - clone about:sync-tabs and a work estimate (s/m/l) of each data type above

Option B: do this in a hosted web page https://mydevices.firefox.com and understand work estimate (s/m/l) for a high level feature breakdown.

If we had a roadmap around 'mydevices' adding revoke, delete, download data - that should steer the path we choose.

from fxa.

last sync time-stamps, device name, count of items per data type

IIUC these are pretty straightforward to read out of sync.

storage size

This is available but may be expensive to read since we don't have quotas enabled in production, we'll have to check operational setup.

histogram of fetches, time of oldest data

I don't think these are surfaced in the sync data model in a useful way.

do this in a hosted web page https://mydevices.firefox.com

Let's bikeshed that a little more, I think we should avoid prolifertating top-level firefox.com domains and either do it as a sub-path or a sub-domain on accounts.firefox.com. But we've probably got a lot of ground to cover before making a final decision on that point ;-)

from fxa.

Option A: all client side work - clone about:sync-tabs and a work estimate (s/m/l) of each data type above

I've no sense of how to break this down, how large it would be, or who we've got with enough bandwidth to carry out this work in the timeframe required.

Option B: do this in a hosted web page https://mydevices.firefox.com and understand work estimate
(s/m/l) for a high level feature breakdown.

The more I think about this, the less comfortable I am with trying to give kB to web content so it can display such a dashboard. We probably want to work towards that capability, but rushing it could easily be a disaster.

I think a better approach will be to add some way to opt-out of the tokenserver's X-Client-State handling, so that web content can read the sync metadata without knowing the encryption key. We'd still need to land client code in Firefox for mozilla/fxa-content-server#2662, and probably want all or most of #24 to replace the encrypted data that we can't read from the clients records. But it would be a smaller and safer set of client changes.

Without decrypting data from sync, but assuming some of #24 gets done, I think we could display:

• device names (or a generic description for devices too old to tell FxA their device name)
• The time each device refreshed its certificate (which approximates last sync time, but wouldn't account for e.g. failed syncs)
• approximate item counts for each datatype
• total storage size

That's still a lot of ground to cover, particularly if it's in addition to onboarding improvements earlier in the flow.

from fxa.

does this open up a security hole web content can read the sync metadata without knowing the encryption key ? But it sounds like we're only passing statistics, not the data itself.

The bigger road map looks like:
M1: growth and discovery of multi-device sync
M2: improve performance through push
M3: device management: revoke, delete, disconnect apps.

With this in mind, we should do this via web content, re-skinning about:sync-tabs doesn't get us that far on the road map. I think #24 is the right path forward.

from fxa.

does this open up a security hole web content can read the sync metadata without
knowing the encryption key ?

You would still need to be able to authenticate as the user in order to read their sync data.

from fxa.

I'm going to close this out, I don't think it adds any value on top of the user-stories that have been exported from aha.

from fxa.