Identity/AttachedServices/Architecture

Overview

Profile In The Cloud (PICL) is a mechanism for synchronizing browser state between a user's various devices. The user attaches a given local profile to a remote account by "logging into their browser", which then uploads and downloads data as necessary to bring the local profile into harmony with the server-held data. Possible PICL services include: bookmarks/history/tabs/passwords backup/syncing, social API preferences, sharing providers, WebRTC bridge provider, file-storage service, etc.

Architectural Overview

There are roughly five areas of concern in the PICL system:

• 1: Signup/Signin: How does the user attach a new device to their account? This area involves passwords, usernames, email addresses, recovery options, revocation, and device management.
• 2: Conversion: How do we extract (and inject) data from the various native data sources (PlacesDB for bookmarks and history, the Password Manager, etc)? This data should be converted into a neutral format so the synchronization code doesn't need to know the details. This code must also merge conflicting data when necessary.
• 3: Synchronization: the neutral data must be encrypted, signed, batched, and delivered to/from a storage server. This process must tolerate dropped messages, interrupted connections, overload conditions, and arbitrarily-long periods of server unreachability.
• 4: Storage Server Authorization: The browser code must prove to the Storage Server that it has a right to read/write the encrypted records.
• 5: Storage Server Format: The storage server must store large quantities of data reliably, and provide fast access.

Authentication

Authentication to PICL Services is done via Persona. This means that a browser needs to be natively logged into Persona, so that it can generate the Persona assertions it needs to connect to individual services without user intervention every time the browser reconnects to an existing service. Specifically, if a PICL service runs at https://bookmarks.example.com, the browser gets an assertion for that audience, without prompting the user every time it needs one.

The flow for logging into the browser is more user-agent centric than the typica Persona signin-to-web flow. Redirecting to an IdP is too jarring. Thus, even if we allow different IdPs, the login UI must be consistent and feel like it's part of the browser.

These requirements (and the next Data Security section) call for a design where the browser locally captures the user's email and password, then engages in a protocol with the IdP – persona.org or otherwise – to obtain a certificate. One way to implement this immediately is to embed the invisible persona.org communication IFRAME and call into its internal API, which we recently augmented to include login() and accountExists() calls to support this implementation path.

Data Security

We are exploring various models for data security: https://wiki.mozilla.org/Identity/CryptoIdeas/03-ID-Attached-Data

The user will have a single "PICL Password", which they must type into the browser during the sign-in process. The user's browser proves (to the Key Server) that it knows this password. From this, it obtains data-encryption keys and a signed certificate that authorizes Storage Server reads and writes. No server learns this password directly: the closest they come is the Key Server, who receives a stretched "verifier" (which only enables a brute-force dictionary attack).

User data is stored in one of two categories. Anything put in the "Class-A" category can be recovered as long as the user can still access their email (i.e. get a Persona assertion for it from their IdP), and consequently is also technically retrievable by the operators of that IdP and the Key Server (or someone who compromises either). Data put in the "Class-B" category requires the PICL password to retrieve: it cannot be recovered when the password is forgotten, but (if the password is well-chosen) cannot be retrieved by the IdP or any other server-side attackers.

We do not yet know which data will be assigned to which category by default, but it is likely that saved-passwords will go into class-B, and many other datatypes will default to class-A. There will be an option to put all data into Class-B.