FEATURE: a "sync status" control dashboard

[rfk]

(Opening for discussion w.r.t Fx42 goal planning; let's not rush off to start building just yet).

Let's build a way for users to get a simple status overview of what's going on in their sync cluster. A nice minimal set of data would be: a list of devices and the time they last synced, a count of the number of items stored of each type, and the total size of your stored data.

Problem: it's not possible to access any of this information without knowing the user's encryption key kB (or at least some derivatives of it).

To make this work well in web content, I think we'd need the following components:

• A way for content-server to ask for sessionToken and kB from sync state in the browser (More reliable passwordless login when you're connected to sync fxa-content-server#2662)
• Corresponding support in Firefox for passing back sessionToken and kB when asked
• UI in content-server for interacting with sync and displaying the status data

It could also be that fxa-content-server is not the right place to build this sort of sync-specific dashboard, but we do have a lot of sync-specific logic in there already.

[rfk]

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.

[edwindotcom]

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.

[rfk]

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 ;-)

[rfk]

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.

[edwindotcom]

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.

[rfk]

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.

[rfk]

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.