Identity/PiCL
Contents
NOTE: This page is defunct and archived for historical purposes. Please visit the following pages:
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 to their Firefox data from any device. 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, Desktop, and OS.
(This document is up to date as of July 2013)
What Problems Are we Solving?
Right now we have four problems with our existing Sync service. In priority order they are:
1. 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).
2. Quality: The existing Sync codebase and protocol are unable to adequately address the reliability, performance, fault recovery, and efficiency requirements of a high-usage sync system.
3. Scalability: Our sync servers are failing far too frequently resulting in user facing outages.
4. 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
Making an account to backup your data will be as easy as entering your email and password. Users will be able to set up Firefox Mobile (android or OS) simply by typing the same stuff.
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 at least two possible storage approaches. There is the existing Sync system running in production right now, which poses considerable scaling challenges and doesn't address future-facing requirements, a new system proposed based on CouchDB, and several alternative proposed systems.
This section will shortly be updated with information about the new proposed system. The Identity and User Services team will deploy and maintain server components, and respective firefox client teams will build and maintain client side code and user interface.
How Will We Build It?
Milestone 1: Stop The Bleeding
This is the phase where we keep our current sync from breaking. Mark Mayo's team has already put considerable work into this, and we may do no work for this phase if we can accelerate subsequent phases. This milestone addresses the short term Scalability problem that is affecting our users.
Milestone 2: UI Landed
This milestone is complete when we have UI implemented (but turned off by default) in Firefox Desktop and Client with UX and Product approval, at this point the Authentication Service is running and this new UI is sufficiently functional to sign in, out, reset passwords, etc.
In this milestone no changes are visible to Firefox end users - this is solely an integration milestone.
(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
