Identity/PiCL

What Is PiCL?

PiCL is a project whose short term goal is to fix firefox sync. The long term goal to give users easy access from any device to their Firefox data. This document describes the present state of the project and the near term plan.

PiCL the name is about the long term goal of PiCL - it stands for Profile in the CLoud. Which is to say we're going to take the interesting data in your Firefox Profile and move it to the cloud - make it possible to access and manage this data from web apps, mobile apps, and all of our products - Mobile, Dekstop, and OS.

(This document is up to date as of July 2013)

What Problems Are we Solving?

Right now we have three problems with our existing sync service. In priority order they are:

1. Scalability: Our sync servers are failing far too frequently resulting in user facing outages.

2. Usability: First, it's too hard to set up - only 1% of our users have actually done so. Second, it's too hard to add a second device - only 10% of sync users have more than one device (and hence are actually getting any value at all from sync).

3. Features: Features we want to build require that we can access data via web apps, which the current sync product cannot support. Competing browsers are building interesting features that can do this. We are at a disadvantage, and it's not for want of ideas.

How Will It Look?

User Experience

What the user will notice when PiCL lands in production is a request to pick a username and password in order to back up their browser. Users will be able to set up Firefox Mobile (android or OS) simply by typing the same username and password. They will be prompted early and prominently to set "log in" or "create an account" to get their firefox everywhere.

For a recent view of UX explorations, go here: http://people.mozilla.com/~zfang/FirefoxAccount/PiCL.pdf

Data Representation

Not all data in your profile is the same. Some of it you would really hate for other people to know (your passwords), some of it would have less impact on you (your currently open tabs). To reflect that the data we will handle has different value to users, and different privacy expectations, there are two classes of data in the system:

1. Recoverable data: Data which is less sensitive and can be recovered if you forget your password (hence, mozilla can read easily). This data is encrypted by a persistent key known to our servers.

2. Non-recoverable data: Data which is more sensitive and cannot be recovered if you forget your password. This data is encrypted by a key derived from your password.

Server Infrastructure

There will be two main network based services that clients will talk to: an authentication service and a storage service.

Authentication Service

The auth service major responsibility is supplying a user with key material if she can prove she knows an email / password combination.

Most of the complexity in the auth service is around robust crypto algorithms to limit user risk given the sensitivity of the data we're dealing in. This includes features like client-side key stretching which prevents our servers from ever knowing the user's raw password and robust password proof protocols which protect users against man in the middle attacks.

The code repository is at: https://github.com/mozilla/picl-idp

A sketch of current work: https://id.etherpad.mozilla.org/picl-idp-protocol

Danny Coates and Zach Carter are leading implementation, and we are targeting a first iteration API that can be developed against in the coming weeks (mid-july).

Storage Service

There are two storage approaches. There is the existing sync system running in production right now, which poses considerable scaling challenges, and a new system proposed based on CouchDB. This section will shortly be updated with information about the new proposed system.

BUT FEEL FREE TO IGNORE STORAGE FOR NOW! Let's focus on nailing authentication - first thing is first.

Chris Karlof, Ryan Kelly, and Brian Warner are leading the storage design, with help and review from folks who know.

How Will We Build It?

Milestone 1: Stop The Bleeding

This is the phase where we keep our current sync from breaking. Mark Mayo has already put considerable work into this, and we may do no work for this phase if we can accelerate subseqeunt phases. This milestone addresses the short term Scalability problem that is affecting our users.

Milestone 2: See It and Feel It

This milestone is complete when we have UI implemented in Firefox Desktop and Client that UX approves of, at this point the Authentication Service is live and this new UI actually can create interact with the account service.

(optional) Milestone 3: Make it So People can Use It

By the time we complete 2, we'll be able to sit down and consider two different options to get to production shippable.

1. Old Sync Storage - Use the existing production Sync system for an initial product to market - re-using swaths of existing client code.

2. New PiCL Storage - Implement new client code that speaks a new protocol talking to a new server.

The decision will depend on cost and time to market.

Milestone 4: Sync Is Fixed

This milestone is achieved when we have a storage backend that we can maintain for the long term and puts us in a place where we can implement new features that require access to firefox data from web applications.

Out of scope

There are an incredible number of things we want to do, but in order to actually complete an iteration of sync that solves Scalability and Usability we are defining a brutally minimalistic MVP. Features we want but will build later include:

1. Remote wipe.

2. Alternate storage services (remote file system, commercial services such as dropbox, etc).

3. Unverified Email support