From MozillaWiki
< Services‎ | Sync
Jump to: navigation, search


Sync is a very useful feature, but has so far failed to achieve widespread adoption. We believe Sync to be an important piece of the Firefox experience, and our goal is to deliver a much more attractive product to support continued Firefox growth. We are tentatively targeting Firefox 20 as the GA for this new version of the service.

Use Cases


  • A Firefox user with multiple devices (desktop or mobile) who wants to have their awesomebar and passwords available on all of their devices.
    • Suleta uses Firefox on her Windows XP laptop and just installed Firefox on her brand new Galaxy S III smartphone. She really appreciates the Firefox awesomebar experience and Firefox's saved logins. Both of those features would be even more valuable on her smartphone where typing URLs and passwords is a real PITA. With Firefox's NextGen Sync, all she has to do is log in to her Firefox on XP (creating a Firefox account in the process) and then log in to her Firefox on Android and all of her valuable Firefox settings and data are immediately pushed to her phone.
  • A Firefox user setting up a new device wants to get up and running with their full Firefox experience as fast as possible.
    • Yaholo bought a shiny new retina Macbook Pro to replace his old and busted 2011 Macbook Pro. With Firefox's NextGen Sync, picking up where he left off with his old machine is a breeze. Yaholo knows that as soon as he downloads the latest version of Firefox and logs in to it, all his settings and data are magically added to his new machine.
  • A Firefox user who wants to back up their data easily and safely, and only has a single device.
    • Nadie lives in her Android Firefox browser. It's her connection to the outside world. She values the information that Firefox has helped her gather over the last 7 years and fears that if it were ever lost, her life would be over. Having logged in to Firefox's NextGen Sync and back up service, she surfs the web with confidence and piece of mind knowing that all of her Firefox data and settings live in a reliable Mozilla cloud instead of her local machine.
      • This doesn't include snapshot backups like Windows System Restore, Time Machine. That's a post v.1 feature.
  • A Firefox user who wants to have the option of secure syncing between devices, using a strong key they manage themselves. (Parity with/comparisons to Chrome Sync, OS X Lion DiskVault).
    • Cochise, a Debian Linux Firefox user, puts security above almost all else. He would like to be able to sync his Firefox profile between his two desktop machines but he's afraid that someone somewhere will snoop on his surfing. Fortunately for Cochise, Firefox's trustworthy NextGen Sync system has an advanced option that allows him to encrypt his data so it's safe from prying eyes.


  • A Firefox user who has lost their device, and their Persona password, and wants to recover their data should be able to recover everything except for passwords (and any future auth data we start syncing, such as client certificates) is a post v.1 feature.
  • A Firefox user who wants a back-up system that has restore-able snapshots, like Windows System Restore or Mac Time Machine is a post v.1 feature.
  • Firefox can link external services to user data on the server side.
    • Hypothetical example would be to connect to a user's bookmarks, and the service would connect to the server store directly, instead of requiring a client plug-in.
    • This would involve storing data in plaintext, and would almost certainly be opt-in for those users who want to use the service, possibly in the same service, or in a special-built service like AITC.

User Data covered by the feature

  • Feature and defaults parity with the current Firefox Sync offering, unless there is data to support different choices.
    • Bookmarks, History and Passwords is the minimum viable set

High level technical description


The implementation of the next generation Sync feature will be centered around Persona. The Identity team will work to define and deploy a special type of IdP, to which we'll refer as a "Preferred IdP" or PIdP for short. This IdP will support an auth protocol designed to prevent disclosure of the user's Persona passphrase to the server, as well as enabling non-browser clients to directly authenticate without a browser context. In addition to a secure authentication protocol, a PIdP will also expose an API to obtain a wrapped encryption key (known as the User Key, or UK). This key will be encrypted and decrypted on the client, using a key derived from the Persona passphrase. The User Key will not be exposed to consumers, but will be used by the Persona client to encrypt and decrypt a per-service encryption key (known as a Service Key or SK) on request.

The current plan for this is to surface as a Firefox Account

Service Authentication

Similar to Apps in the Cloud, the service client will obtain an assertion from the Firefox Account client, and use that to authenticate to the Token Server. A successful request to the Token Server will return an object containing all necessary data to make requests against the Identity-attached service, as described in the Token Server API docs.

Using the Service

The new version of the Sync Storage API uses the same request authentication model as Apps in the Cloud. Beyond that, it is a significantly refined version of the 1.1 API with a set of improvements outlined in the API docs. Sync clients will use a Service Key stored on the service itself, encrypted by the Persona client using the UK. The SK (or keys chained to it) will be used to encrypt outgoing records and decrypt incoming records, like the existing model.

A very simplified view of the changes between Sync 1.1 and Sync 2.0 is provided by these diagrams:

Sync 1.1.png
Sync 2.0.png

High-level roadmap

We can split this effort into four main areas:

  1. Design, build, and deploy the PIdP service (identity)
  2. Design, build, and integrate the Firefox front-end to this service, on both desktop and mobile (services integration and/or Firefox frontend engineering)
    • Depends on PIdP service
  3. Finish the implementation and deployment of the Sync 2.0 production service (services engineering, services operations)
  4. Implement and integrate the Sync 2.0 client on desktop and mobile, including UX design and UI implementation, bearing in mind concurrent version requirements (services integration).
    • Depends on PIdP service, Firefox account support, crypto work.

Note that (2) is blocked on (1), and (4) depends on everything else to some extent. Development work can begin but not complete until those dependencies are met.

Sync dependencies.png

It might be helpful to think of achieving a Firefox account — that is, providing a PIdP and browser integration — as one project, and browser data synchronization as a separate project on top.

More details are in the technical plan.

Open Questions

Previous questions have been answered and archived archived