Private by Design: How we built Firefox Sync

What is Firefox Sync and why would you use it

That shopping rabbit hole you started on your laptop this morning? Pick up where you left off on your phone tonight. That dinner recipe you discovered at lunchtime? Open it on your kitchen tablet, instantly. Connect your personal devices, securely. – Firefox Sync

Firefox Sync lets you share your bookmarks, browsing history, passwords and other browser data between different devices, and send tabs from one device to another. It’s a feature that millions of our users take advantage of to streamline their lives and how they interact with the web.

But on an Internet where sharing your data with a provider is the norm, we think it’s important to highlight the privacy aspects of Firefox Sync.

Firefox Sync by default protects all your synced data so Mozilla can’t read it. We built Sync this way because we put user privacy first. In this post, we take a closer look at some of the technical design choices we made and why.

When building a browser and implementing a sync service, we think it’s important to look at what one might call ‘Total Cost of Ownership’.  Not just what users get from a feature, but what they give up in exchange for ease of use.

We believe that by making the right choices to protect your privacy, we’ve also lowered the barrier to trying out Sync. When you sign up and choose a strong passphrase, your data is protected from both attackers and from Mozilla, so you can try out Sync without worry. Give it a shot, it’s right up there in the menu bar!

Sign in to Sync Button in the Firefox Menu

Why Firefox Sync is safe

Encryption allows one to protect data so that it is entirely unreadable without the key used to encrypt it. The math behind encryption is strong, has been tested for decades, and every government in the world uses it to protect its most valuable secrets.

The hard part of encryption is that key. What key do you encrypt with, where does it come from, where is it stored, and how does it move between places? Lots of cloud providers claim they encrypt your data, and they do. But they also have the key! While the encryption is not meaningless, it is a small measure, and does not protect the data against the most concerning threats.

The encryption key is the essential element. The service provider must never receive it – even temporarily – and must never know it. When you sign into your Firefox Account, you enter a username and passphrase, which are sent to the server. How is it that we can claim to never know your encryption key if that’s all you ever provide us?  The difference is in how we handle your passphrase.

A typical login flow for an internet service is to send your username and passphrase up to the server, where they hash it, compare it to a stored hash, and if correct, the server sends you your data. (Hashing refers to the activity of converting passwords into unreadable strings of characters impossible to revert.)

Typical Web Provider Login Flow

The crux of the difference in how we designed Firefox Accounts, and Firefox Sync (our underlying syncing service), is that you never send us your passphrase. We transform your passphrase on your computer into two different, unrelated values. With one value, you cannot derive the other0. We send an authentication token, derived from your passphrase, to the server as the password-equivalent. And the encryption key derived from your passphrase never leaves your computer.

Firefox Sync Login Flow

Interested in the technical details?  We use 1000 rounds of PBKDF2 to derive your passphrase into the authentication token1. On the server, we additionally hash this token with scrypt (parameters N=65536, r=8, p=1)2 to make sure our database of authentication tokens is even more difficult to crack.

We derive your passphrase into an encryption key using the same 1000 rounds of PBKDF2. It is domain-separated from your authentication token by using HKDF with separate info values. We use this key to unwrap an encryption key (which you generated during setup and which we never see unwrapped), and that encryption key is used to protect your data.  We use the key to encrypt your data using AES-256 in CBC mode, protected with an HMAC3.

This cryptographic design is solid – but the constants need to be updated. One thousand rounds of PBKDF can be improved, and we intend to do so in the future (Bug 1320222). This token is only ever sent over a HTTPS connection (with preloaded HPKP pins) and is not stored, so when we initially developed this and needed to support low-power, low-resources devices, a trade-off was made. AES-CBC + HMAC is acceptable – it would be nice to upgrade this to an authenticated mode sometime in the future.

Other approaches

This isn’t the only approach to building a browser sync feature. There are at least three other options:

Option 1: Share your data with the browser maker

In this approach, the browser maker is able to read your data, and use it to provide services to you. For example,  when you sync your browser history in Chrome it will automatically go into your Web & App Activity unless you’ve changed the default settings. As Google Chrome Help explains, “Your activity may be used to personalize your experience on other Google products, like Search or ads. For example, you may see a news story recommended in your feed based on your Chrome history.”4

Option 2: Use a separate password for sign-in and encryption

We developed Firefox Sync to be as easy to use as possible, so we designed it from the ground up to derive an authentication token and an encryption key – and we never see the passphrase or the encryption key. One cannot safely derive an encryption key from a passphrase if the passphrase is sent to the server.

One could, however, add a second passphrase that is never sent to the server, and encrypt the data using that. Chrome provides this as a non-default option5. You can sign in to sync with your Google Account credentials; but you choose a separate passphrase to encrypt your data. It’s imperative you choose a separate passphrase though.

All-in-all, we don’t care for the design that requires a second passphrase. This approach is confusing to users. It’s very easy to choose the same (or similar) passphrase and negate the security of the design. It’s hard to determine which is more confusing: to require a second passphrase or to make it optional! Making it optional means it will be used very rarely.  We don’t believe users should have to opt-in to privacy.

Option 3: Manual key synchronization

The key (pun intended) to auditing a cryptographic design is to ask about the key: “Where does it come from? Where does it go?” With the Firefox Sync design, you enter a passphrase of your choosing and it is used to derive an encryption key that never leaves your computer.

Another option for Sync is to remove user choice, and provide a passphrase for you (that never leaves your computer). This passphrase would be secure and unguessable – which is an advantage, but it would be near-impossible to remember – which is a disadvantage.

When you want to add a new device to sync to, you’d need your existing device nearby in order to manually read and type the passphrase into the new device. (You could also scan a QR code if your new device has a camera).

Other Browsers

Overall, Sync works the way it does because we feel it’s the best design choice. Options 1 and 2 don’t provide thorough user privacy protections by default. Option 3 results in lower user adoption and thus reduces the number of people we can help (more on this below).

As noted above, Chrome implements Option 1 by default, which means unless you change the settings before you enable sync, Google will see all of your browsing history and other data, and use it to market services to you. Chrome also implements Option 2 as an opt-in feature.

Opera and Vivaldi follow Chrome’s lead, implementing Option 1 by default and Option 2 as an opt-in feature. Update: Vivaldi actually prompts you for a separate password by default (Option 2), and allows you to opt-out and use your login password (Option 1).

Brave, also a privacy-focused browser, has implemented Option 3. And, in fact, Firefox also implemented a form of Option 3 in its original Sync Protocol, but we changed our design in April 2014 (Firefox 29) in response to user feedback6. For example, our original design (and Brave’s current design) makes it much harder to regain access to your data if you lose your device or it gets stolen. Passwords or passphrases make that experience substantially easier for the average user, and significantly increased Sync adoption by users.

Brave’s sync protocol has some interesting wrinkles7. One distinct minus is that you can’t change your passphrase, if it were to be stolen by malware. Another interesting wrinkle is that Brave does not keep track of how many or what types of devices you have. This is a nuanced security trade-off: having less information about the user is always desirable… The downside is that Brave can’t allow you to detect when a new device begins receiving your sync data or allow you to deauthorize it. We respect Brave’s decision. In Firefox, however, we have chosen to provide this additional security feature for users (at the cost of knowing more about their devices).


We designed Firefox Sync to protect your data – by default – so Mozilla can’t read it. We built it this way – despite trade-offs that make development and offering features more difficult – because we put user privacy first. At Mozilla, this priority is a core part of our mission to “ensure the Internet is a global public resource… where individuals can shape their own experience and are empowered, safe and independent.”

0 It is possible to use one to guess the other, but only if you choose a weak password.

1 You can find more details in the full protocol specification or by following the code starting at this point. There are a few details we have omitted to simplify this blog post, including the difference between kA and kB keys, and application-specific subkeys.

2 Server hashing code is located here.

3 The encryption code can be seen here.

4 Section “Use your Chrome history to personalize Google”

5 Chrome 71 says “For added security, Google Chrome will encrypt your data” and describes these two options as “Encrypt synced passwords with your Google username and password” and “Encrypt synced data with your own sync passphrase”.  Despite this wording, only the sync passphrase option protects your data from Google.

6 One of the original engineers of Sync has written two blog posts about the transition to the new sync protocol, and why we did it. If you’re interested in the usability aspects of cryptography, we highly recommend you read them to see what we learned.

7 You can read more about Brave sync on Brave’s Design page.

About Tom Ritter

More articles by Tom Ritter…


  1. Ted

    Thanks Tom for this thorough breakdown.
    Is it possible to use Firefox Sync as a central location for syncing bookmarks even from other browsers? I love the idea of Mozilla being the impartial, privacy-fierce guardian of my data, but I have to use different browsers for work due to a long-running Firefox conflict with the main system I work on. Keeping everything in sync, especially privately and for free, is a mess.

    November 13th, 2018 at 11:06

    1. Tom Ritter

      Yes and no. No other major browser natively supports our sync protocol. But our protocol is open, so it’s possible to write extensions for other browsers that connect to our Sync Server (you can even run your own sync server actually). I’m not sure if such extensions already exist (and wouldn’t want to implicitly endorse any), but it would be possible to build!

      November 13th, 2018 at 11:55

  2. Raphael

    I disagree about the choice between option 1 and 3.

    In the old sync protocol, without knowing the implementation details, I could be reasonably certain, as a non-technical user, that the sync server does not have access to my (unencrypted) data because why else would I have two distinct passwords.

    With the new sync protocol I have to be technically skilled to understand why, even though I only have one password for the account, your server still does not have access to my data.

    November 13th, 2018 at 13:17

    1. Tom Ritter

      I think understanding that having two distinct passwords implies that the sync server does not have access to my (unencrypted) data is exactly what makes you a technical user. A non-technical user may never have heard of encryption before, let alone understand that a password somehow controls it.

      November 14th, 2018 at 10:49

      1. johny

        Tom, for “non-technical user” there is chrome,safari and edge.

        And people started to be more educated, millennial folks are coming, so enough with this “let’s make it easy for everyone” and weaken security.

        November 27th, 2018 at 00:57

  3. TG

    I like sync, but mostly its slow to push links.
    I have to go and refresh the history tab on android phone.
    Any news on this ?

    November 13th, 2018 at 20:38

  4. Qio Xuan

    Tom Ritter, we love your work on privacy and cooperation with the Tor Project! Keep it up, proud of ya

    November 13th, 2018 at 20:42

  5. Luis Ashurei

    Nice post! I have used FF from “Option 3” original Sync Protocol up to now.

    How user get encryption key after switch to a new device in the new Sync Protocol? Regenerate from password?

    November 13th, 2018 at 22:29

    1. Tom Ritter

      On each device you log in to sync on you will derive the same authentication token and encryption key from your Firefix Account password.

      November 14th, 2018 at 10:47

  6. Bruno

    Lost all my bookmarks. Stopped using Firefox!!

    November 14th, 2018 at 00:42

  7. Krishna Mohan

    Care to share the rationale behind choosing PBKDF2? I read recently that it is [slow]( by design.

    November 14th, 2018 at 00:53

    1. Tom Ritter

      It’s supposed to be slow. Choosing a slow hash function is intentional; as it makes it more difficult for an attacker to guess your password if they were somehow obtain your authentication token. In the future, we want to make it slower to provide more security!

      November 14th, 2018 at 10:46

  8. Yuri Namekovski

    That’s all nice, but Firefox doesn’t sync

    * search engines
    * cookie settings

    Configuring these on every device is still a major pain in the ass.

    November 14th, 2018 at 01:16

  9. allo

    The sync 1.1 design with separate encryption key was great.
    The weakness of the new scheme can be demonstrated without much technical details:

    – Install Firefox on a new computer
    – Login to sync, only using email address and password
    – You get your data

    The login page is hosted by Mozilla, so they could (e.g. if they were hacked) log your username and password. And that’s all you need for a new login. No local secret anymore (which cannot be recovered with the login data only).

    And self hosting got a lot more complicated :(

    November 14th, 2018 at 04:23

    1. Tom Ritter

      From a sync developer:

      You’re correct in your understanding that that login flow is ultimately driven by a webpage, and this is a deliberate trade-off that we made in the interests of reach and usability of the system.

      It’s certainly a trade-off that not everyone is comfortable with, but we’re confident it’s the right one for the majority of our users. You can read some previous discussions on the topic in these two bugs (and additional suggestions/feedback therein is definitely welcome)

      November 14th, 2018 at 11:04

      1. allo

        I know the trade-off and I understand your decision to some degree, but I dislike what it means for my security.

        I am not sure about a already coupled firefox. Is it more secure, when the login page was secure when I logged in?
        I suppose only a login-token is sent during sync and the password only when logging in?

        In sync 1.1 I liked the easy sync server. I used the django version, which worked without much efford just as the official one.
        I tried to get sync 1.5 to work as some other people, but we had no success in a full-stack sync (the sync-server only seems to be easy, but it then accepts mozilla login-tokens).

        The documentation wasn’t that great at the time and we discussed it in the comments of a blog article about it (I think it was deleted when the author himself gave up as well).
        Possibly the docker images which exist know would make it more simple, but with the full overhead of docker as trade-off.

        I am currently not needed sync that urgently, so I do not sync at all currently.
        I hope you do not see this too much as distrust in Mozilla, but personally I like to avoid trusting thirdparties with such very personal data.

        November 14th, 2018 at 14:24

  10. Daniel

    Firefox Sync is one of the very few “cloud services” I trust my personal data. I’m glad Mozilla exists. You guys make a real difference in the life of so many people. Rock on!

    November 14th, 2018 at 06:17


    unfortunately, in the real world there is a (possible) difference between (intended) design, it’s impementation and it’s (unintended) use.

    November 14th, 2018 at 07:15

  12. Brian Doyle

    Great article. I was wondering how do you handle multiple devices using sync with the same account? Does the encryption key somehow get sent to the other devices or does every device have a unique key and thus multiple authentication tokens on the Mozilla servers? Thanks!

    November 14th, 2018 at 07:32

    1. Tom Ritter

      Because your password is the same; your authentication token and encryption key will be derived to the same value on all devices.

      November 14th, 2018 at 10:45

      1. Brian Doyle

        That makes sense about the token and key being based on your password. So if you change your password then the token and key change? If so, the data would need to be encrypted with the new token? Sorry if these are stupid questions, attempting to learn how this works. Thanks again!

        November 14th, 2018 at 12:29

        1. Tom Ritter

          When you change your password, your authentication token does change, and we replace our (hashed) entry in our database with the new (hashed) value. Your encryption key also changes.

          It’s omitted from the diagram for simplicity, but the encryption key derived from your password doesn’t encrypt your synced data directly. It actually encrypts what is commonly called a ‘data encryption key’ (or DEK). And the DEK is used to encrypt your synced data. The DEK is generated by you during setup, and only sent to the server after being encrypted by your derived encryption key (this process is referred to as ‘wrapping’ the DEK.)

          So when you change your password, you derive a new encryption key, we send you the wrapped DEK, you decrypt the DEK with the old encryption key, re-encrypt it with the new encryption key, and send us back the re-wrapped DEK. This allows you to safely change your encryption key without requiring you to re-encrypt all your data.

          November 14th, 2018 at 12:39

  13. Mark T

    Thanks for the comparisons with other browsers. Do you have the information to be able to compare with Safari? I have always felt that Apple is quite privacy-focused. But I’m also interested to know if they have their own “wrinkles” in their Safari/iCloud sync privacy design and implementation.

    November 14th, 2018 at 09:36

    1. Tom Ritter

      I’m afraid I didn’t look at Safari/iCloud. They state that “No one else, not even Apple, can access end-to-end encrypted information” (here) and that bookmarks are an example of that – but it’s hard to analyze it definitively, because it’s not open source. There have been some Black Hat talks on the subject I think.

      November 14th, 2018 at 10:42

  14. kz

    Thanks for commenting with the link for self-hosting Sync. We’d love blog posts sometime on the state of self-hosting Sync and Accounts.

    When one of our participants creates an online resource like Sync, it amounts to “Shadow I.T.” for us, not because they create it without our benevolent approval, but because they come to us for help when something changes. Staff changes. Policies change. Circumstances change. Expectations change.

    Information that end users bury in a work-related Sync (’cause Firefox puts it front-and-centre) belongs to the business, and I.T. needs to be able to vouch for its availability, its provenance and life cycle. Self-hosting is a start.

    November 14th, 2018 at 13:57

  15. enthusiast

    Thanks, Firefox Sync has improved by experience a lot. A few slightly off-topic thoughts on how to make Firefox Sync even better:

    – Firefox Sync does not (yet) sync search settings / engines:
    – Firefox Sync does not (yet) sync containers:

    And lately I have some bookmarks unusable. This is new behavior in Firefox 63.0.1 on macOS 10.14.1 which I have not yet had time to analyze, but it’s highly frustrating.

    Tom, thanks for this blog post, I enjoyed reading it.

    November 14th, 2018 at 15:06

  16. Amd


    That’s all good but the ISP still has your Loc and Internet address. Why not offer a VPN CAPABILITY like OPERA does? More Intl users may use Firefox if there was a way to totally remain private location wise. Loc privacy can be equally important.

    Also how does Firefox compare privacy wise with Safari?

    November 14th, 2018 at 19:52

  17. Mike

    Nice summary, thanks.

    How is it possible to keep my own sync server on qnap nas which worked fine until upgrade to version 60 of Firefox?
    I cannot set up in current versions. It would be so great to have an extension/addon for that!


    November 15th, 2018 at 12:29

  18. Chris


    Do account data are deleted immediately after pressing the Delete Account button, or there is a trigger to delete this data at once after a while?

    November 15th, 2018 at 12:38

  19. Shuj

    A simple way to improve Firefox Sync is to tell new users that they’ll need a smartphone to complete the sign-up _before_ jumping through all the password and email address hoops. I now have a half-completed sign-up :-(

    November 15th, 2018 at 18:52

  20. Clemens

    This is a very interesting problem and we targeted this exact problem in our research (“AuthStore: Password-based Authentication and Encrypted Data Storage in Untrusted Environments”

    I think the Sync authentication can be improved in two points:

    1) Ultimately, the KDF parameters needs to be adapted over time, e.g. the iteration count needs to be increased to mitigate faster CPUs… Furthermore, the KDF parameters should be configurable by the user.
    2) If the user enters the wrong password, e.g. a password that is used at a different service the server could start a brute force attack on the authentication token. This problem is hopefully less relevant for Mozilla ;)

    In our proposed solution we solved these problems. Users can choose and adapt KDF parameters as they like. To make this work we store the KDF parameters on the server. However, this leads to other problems, i.e. the server could perform a “parameter attack”. Briefly: in a parameter attack the server sends back the weakest possible KDF parameters to the user in order to obtain an easier to brute force authentication token. To prevent this attack we use an adapted version of the provable secure EKE2 protocol. This protocol does not reveal any information about the entered password. For example, if you entered “123” (not your real password) in the password field the server is not able to find out that this is what you did. The server can only tell if the entered password is correct or not. This property prevents parameter attacks since the server does not learn anything about the weakened auth token. Please have a look at our paper for more details.

    I implemented our solution as a browser extension (FejoaAuth: However, having something like FejoaAuth integrated into the browser would be much more convenient. Our approach can be used to securely authenticate at multiple services with the same password and the same password can even be reused for data encryption.

    Please let me know if you have questions!

    November 16th, 2018 at 16:52

  21. wolfiedk

    I have been looking for a replacement for X-Marks, I tried using FFSync, but alas, it demands access to my mobile, which is a definite no from me.

    What to do?

    November 17th, 2018 at 12:33

  22. Igor Bukanov

    Firefox Sync still assumes that the user has to remember two passwords, one for email and one for Sync as on a new Firefox installation access to Sync requires a confirmation by email. So the practical difference from Chrome is that in Firefox the option 2 is the only choice and for the email one can use any email provider, not only Google.

    November 19th, 2018 at 06:56

  23. tc

    Thanks for sharing the design concept, which is rarely accessable to end users. Never leaving passphrase away from user’s hardware is a great.
    I also enjoy your point of ‘Total Cost of Ownership’ for services’ evaluation.

    November 29th, 2018 at 06:38

  24. fred


    I would love to be able to generate the encryption key using my own tooling (ie openssl) instead of the software that is part of this implementation. I understand this increases the barrier to entry so having it as an option for advanced users would then be a good idea. This way 2 separate and totally unrelated toolchains are used to build the system, which in my view is essential. It’s not that I don’t trust Mozilla (I do), but I believe a system like this should not be dependant on trust.

    – Fred

    December 2nd, 2018 at 03:02

  25. Stephan Porz

    Your article convinced me to finally use Firefox Sync! Thank you so much for the article as well as this beautiful design.

    Historically, I have been hosting most syncing on a computer I control, just because third party vendors actually would be able to read my data OR wouldn’t explain in detail how they protect the privacy of my data.

    December 4th, 2018 at 01:43

Comments are closed for this article.