Firefox Sync offers best-in-class security and privacy: Mozilla’s servers never see your raw password, and all of your Sync data is encrypted locally, before it leaves your computer. However, some users want to go one step further and host all of their Sync data themselves. The ability to self-host is central to Mozilla’s mission, as it ensures that the convenience of Sync doesn’t come with hidden costs like strict lock-in.
With Sync 1.1, self-hosting was as easy as setting up ownCloud, using one of several Python modules, or for the more intrepid users, running the same code that Mozilla used in production. OpenBSD even includes a Sync 1.1 server in its ports tree!
With Sync 1.5’s recent release, we’re back to square one: all of Mozilla’s code is open source, and people are already running their own Sync 1.5 stacks, but it will take a few months before easier-to-use, self-contained projects emerge.
Of course, if you’re currently using using a self-hosted Sync 1.1 server, Firefox will continue to work with it for several months while we sort out self-hosting of Sync 1.5.
The Relationship Between Sync and Firefox Accounts
One challenge with self-hosting Sync 1.5 is understanding the relationship between Sync 1.5 and Firefox Accounts (FxA). Indeed, this is a frequent topic in the #sync IRC channel.
The Firefox Accounts system serves two purposes:
- It is a single, common authentication system for Mozilla services like Sync, the Firefox Marketplace, and Firefox OS’s find-my-device feature.
- It stores a password-wrapped version of your Sync key, so that you (and only you) can recover your data, even if you lose all of your devices.
By keeping authentication in one well-defined place, and sharing that infrastructure between projects, we’re able to dramatically reduce complexity and maintenance costs associated with running many services. Sync can focus on Sync, while letting Firefox Accounts handle accounts.
Unfortunately, this happens to increase complexity if all you care about is self-hosting a single service, like Sync.
The Moving Parts
Right now, the Firefox Accounts system is mostly comprised of a database and three servers written in Node.JS:
- fxa-auth-server, which handles the Firefox Accounts backend and API, including provisioning identity certificates for users.
- fxa-content-server, which serves up static content, like the UI that you see when you visit about:accounts in Firefox.
- browserid-verifier, which makes it easy for services like Sync to verify identity certificates issued by the auth server.
Sync has a database and two servers written in Python:
- tokenserver, which handles incoming auth requests, issues long-lived bearer tokens, and directs the browser to an appropriate storage server.
- syncstorage, which accepts bearer tokens and allows the browser to store and retrieve encrypted Sync data.
Sync and FxA are decoupled, which leads to two interesting self-hosting options:
Method 1: Just the Data
It’s possible to host just the Sync components, while still relying on Mozilla’s hosted Firefox Accounts infrastructure for authentication.
With this method, you still store all of your encrypted Sync data on your own server, but you use Mozilla’s servers for authentication and for backing up a password-wrapped version of your Sync key.
Because Sync uses client-side (PBKDF2 + HKDF) key stretching, Mozilla never learns your plaintext password, and thus cannot unwrap your Sync key. Additional server-side stretching (scrypt + HKDF) further protects against brute-force attacks if the Firefox Accounts database is ever compromised.
Method 2: Full Stack
Alternatively, you could host both the Sync and Firefox Accounts components, completely removing any dependence on Mozilla for Sync.
Self-hosting is limited to browser-based services like Sync. Web sites, like the Firefox Marketplace, may require an additional account with the centralized Firefox Accounts server before allowing you to log in.
Right now, we’re focusing on getting Method 1 working as well and as quickly as possible. Most of that work is happening in the syncserver repo, which is a Python project that combines both the tokenserver and syncstorage projects into a single package.
We also need to resolve Bug 1003877, which is currently preventing either method from working on Firefox for Android.
Lastly, we need to ensure that the work we do to facilitate self-hosted Sync is the right work. Namely, how do we go from “technically possible” to “reasonably easy” for advanced users? To get this right, we’ll need to draw on the experience of projects like ownCloud, which is at the forefront of making Sync 1.1 easy to self-host, as well as users who have self-hosted in the past or who are interested in self-hosting now.