FEATURE: session status 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 minimal version of a "control dashboard" where you can at least see what's connected to your account, and if we get real adventurous maybe let you disconnect things. @edmoz if we decide to push ahead with this for Fx42, we can use this bug to capture the user-story and all the dependencies.

Main user story

I want to see when and where I've logged in to Sync, so that I understand what devices are connected via my Firefox Account and their status.

• Provide an API on the auth server for listing active login sessions and their metadata
• Add a view on the content server that surfaces this data when the user is logged into her account

Supporting user stories

I want to see when I logged into a device, so that I know how old it is.

• This might already be possible via sessionToken creation time.

I want to see when each of my devices last connected, so that I can be informed about recent activity.

• Add last access time to login sessions (Record user-agent and last-access-time on session tokens fxa-auth-server#983)

I want to be able to easily identify devices, so that I can distinguish between them.

• Add user agent information to login sessions (Record user-agent and last-access-time on session tokens fxa-auth-server#983)
• Have Firefox pass the sync client GUID as its device ID after a user has logged into Sync (Record device id on sessionTokens fxa-auth-server#988)
• Have Firefox update the description field when its sync device name changes (Record device id on sessionTokens fxa-auth-server#988)

[edwindotcom]

rfk - maybe we/you could break the check boxes above into components and we do a best guess at how much time this is going to take. s/m/l being 1/3/5 day increments? We can take that and consider the resource plan.

[rfk]

In the interests of getting our process right: when you say "break into components", what concrete artifacts would you expect that process to produce? A bug tree of issues across all the revelant repos?

My rough estimates:

• track useful metadata about all active login sessions [M]
  • needs checking with legal, since it's kinda personal tracking data
• add device and description fields for sessions that belong to a device:
  • allow submitting device/description data when establishing a session [S]
  • allow updating the description data on an existing session [S]
• have Firefox pass the sync client GUID as its device ID when logging in to sync [M]
  • I haven't dug into all the details of this, but it likely breaks down into:
    • get Firefox to tell content-server its device details when setting up sync [S]
    • have content-server pass on those details when setting up the session [S]
• have Firefox update the description field when its sync device name changes [S]

Those are the critical bits that depend on or enable code that needs to land inside Firefox in the 42 cycle. Then there comes the exposing-it-to-users part:

• provide an API for listing active login sessions and their metadata [M]
  • although IIRC Kit has already made a solid start on this
• add a view on the content-server that surfaces this data [XL]
  • large and under-defined:
    • needs UX treatment
    • needs a "session data" API client added to content-server
    • and a bunch of work to actually get it cast into code

[billmaggs]

This bug supports user stories for two different users: FF users and Mozilla staff.

V1. The Basics (FF 42)
As a FF user when using Firefox,

1. I want to know the devices and services I am connected to via my Firefox Account, and important information about my the status of my services.
   1a. For devices, this includes last time synced, record counts of different data types, and optionally data storage size (perhaps an option for self-hosters or others?)
   1b. For services, this includes when I am connected to those services via FF (a FF device) as well as through other other browsers (a non-FF device)
   1c. I want my FF devices to be logically named so I recognize them and also have the ability to rename them.
   1d. I want views that make use of device names such as Tabs from My Other Devices to carry the same device naming and last synced information as the device/service dashboard
   1e. I want a place to go when I think that something might be wrong with Sync to be able to see when a sync last occurred.

V2. Push (FF~43)
As a FF user when using Firefox,

1. I want FF and my core browsing data to feel speedy and to the point both in general usage and when I am specifically interacting with synced data.
   1a. When I am looking at another device's history, tabs, passwords, or other data types synced across my devices, I want FF to feel like it is propagating that information across my devices in a timely fashion.
   1b. When I log into a service with my FxA, I want to be able to see it in my FxA dashboard, complete with last time logged in.
2. when I add a new FF device or log into a FxA-relying service for the first time, I want to be notified while using the product as well as by out of band communication channels (email, SMS) without feeling like I am being watched or spammed.

V3. Device Management (FF 44?)
As a FF user when using Firefox,

1. I want to manage the devices and services attached to my FxA from one place.
   1a. For Mozilla-branded services like Sync and Hello, I want to be able to revoke the service and turn off data types synced between devices. This can include Sync data types as well as other Mozilla information services like Hello.
   My expectations about how those data types coexist on my FF devices should be consistent.
   1b. For third party FxA-relaying services, I want to be able to disconnect them from FxA.

[shane-tomlinson]

This bug supports user stories for two different users: FF users and Mozilla staff.

Can these be teased apart, these seem like two very different set of users with two very different needs. Trying to combine these into one bug/dashboard feels ripe for a UX disaster.

I see a lot in V1, most of this seems bang on, though I think several of the concepts can be re-organized/clarified. The distinction between services/devices can be made more explicit and grouping related concepts helpful.

1a, 1c, 1d, and 1e belong in one group, 1b in another.

I want to know the devices and services I am connected to via my Firefox Account, and important information about my the status of my services. 1a. For devices, this includes last time synced, record counts of different data types, and optionally data storage size (perhaps an option for self-hosters or others?) 1b. For services, this includes when I am connected to those services via FF (a FF device) as well as through other other browsers (a non-FF device) 1c. I want my FF devices to be logically named so I recognize them and also have the ability to rename them. 1d. I want views that make use of device names such as Tabs from My Other Devices to carry the same device naming and last synced information as the device/service dashboard 1e. I want a place to go when I think that something might be wrong with Sync to be able to see when a sync last occurred.

Device & Sync are conflated/intimately tied together, this seems natural from a user perspective, though from a technical perspective Sync is "just another service". How do you envision displaying Sync information, as part of the device information, or as a service? I think either could work, though like I said earlier, tying Sync information to the device seems natural. Something for user testing?

I think the general concept is that Sync data are core data about the Firefox device, central to your browser, and the other services are attached to your FF account.

record counts of different data types, and optionally data storage size (perhaps an option for self-hosters or others?)

Does record count provide real value? It's "neat" in Chrome, but does knowing "hey, I have 147 bookmarks" provide me with any actionable information? I can imagine it's useful to see "hey, I had 239 passwords saved in device A, and 238 in device B, it looks like my data is out of sync" but this scenario requires having both devices in front of me at the same time.

It's just data for the user, gives them a sense of what they're doing with their core browsing experience, but perhaps only really useful to sync self-hosters. I don't think it is essential in any case.

1b. For services, this includes when I am connected to those services via FF (a FF device) as well as through other other browsers (a non-FF device)

"when I am connected" as in the last time the user authenticated for that service, or whether the user has an active session with that service? The first should be pretty easy, the 2nd relies on information from the service.

I think that all we as keepers of FxA can do is tell you about the last authentication. It would be great to know about all the relying services, but I don;t see how we could do that easily.

For Mozilla-branded services like Sync and Hello, I want to be able to revoke the service and turn off data types synced between devices. This can include Sync data types as well as other Mozilla information services like Hello.

We are going to have to decide what data we care about seeing/revoking, and possibly implement a cross-organization strategy to provide the technical infrastructure to enable this. For example, Hello plans to store/sync contacts using the mozContacts API and Firefox OS plans their own backup service to backup/sync phone data that is not already handled by Sync. Will we care about seeing data stored by these alternative data sinks, or only Sync specific data?

You make a good point about Hello contact data, I think that we need to find a way to include data about that. Firefix OS is another matter, it depends how they play that strategy.

[edwindotcom]

@billmaggs can you break apart the final set of user stories into individual github issues. Then we can start scheduling work.

[rfk]

break apart the final set of user stories into individual github issues. Then we can start scheduling work.

Process-wise, is the plan to have these as "user-story" bugs on this top-level repo, and then we can spin off specific implementation details into bugs on the appropriate product repos?

[ckarlof]

rfk - maybe we/you could break the check boxes above into components and we do a best guess at how much time this is going to take. s/m/l being 1/3/5 day increments?

It's more important the tasks are comparable to each other in terms of work required, and less important we understand the time estimate in terms of days at this point in time.

[ckarlof]

I took Bill's user stories and Ryan's list and merged them above in the description for a scoped V1, primarily focusing on Sync connected devices. For archiving purposes, I've included Ryan's old list here:

• track useful metadata about all active login sessions (Record user-agent and last-access-time on session tokens fxa-auth-server#983)
• add device and description fields for sessions that belong to a device (Record device id on sessionTokens fxa-auth-server#988)
• have Firefox pass the sync client GUID as its device ID when logging in to sync
• have Firefox update the description field when its sync device name changes
• provide an API for listing active login sessions and their metadata
• add a view on the content-server that surfaces this data

[rfk]

@billmaggs we need to figure out what to do with this bug, the user-stories that it supports, and the aha integration you've got set up. Right now there's a lot of overlap between this one and other FEATURE bugs.

I suspect the right way forward is to migrate the useful parts of this comment thread into a user-story bug exported from aha, and close this one in favour of it. But none of the existing user-story bugs seem to map well to it. Can you please identity which user-story issues map to the things @ckarlof identified under "Main user story" and "Supporting user stories" in the bug description, and I'll triage things into those bugs.

[billmaggs]

Turned into user stories here:
https://mozilla.aha.io/features/FXA-14
https://mozilla.aha.io/features/FXA-15
https://mozilla.aha.io/features/FXA-16
https://mozilla.aha.io/features/FXA-18

[rfk]

This is now appropriately captured in aha, closing out the bug