3 ms·

Everything is Class-B. Class-A and Class-C are relics of ideas we had back in 2013 that we did not pursue. Specifically, once of the consequences of Class-B is

Everything is Class-B. Class-A and Class-C are relics of ideas we had back in 2013 that we did not pursue. Specifically, once of the consequences of Class-B is that your encryption key is derived from your password. If you forget and reset your password, you necessarily lose access to all of your synced data. (Though we did recently add support for recovery keys: https://support.mozilla.org/en-US/kb/reset-your-firefox-account-password-recovery-keys https://support.mozilla.org/en-US/kb/reset-your-firefox-acco...) The idea behind Class-A was to let users choose to place some less sensitive data--like bookmarks--into a bucket which survived password resets at the cost of Mozilla holding a copy of the encryption key. The idea for Class-C was to allow users to generate and an entirely separate encryption key entirely separate from their password, as with Sync 1.1, but at the cost of more complex setup when adding a new device: you have to either maintain a backup copy of the key, or always have a previously configured device on hand for PAKE. Our experience with Sync 1.1 taught us that this does not work with real people at scale; people often lost data as a consequence of this design.

zeveb 8y ago
> Our experience with Sync 1.1 taught us that this does not work with real people at scale; people often lost data as a consequence of this design. Far better to lose passwords, bookmarks & history than to have them exposed — which is what the current design does (because the user's password can be stolen if the users logs in to his Firefox Account via the HTML page). There are reasonable countermeasures I can take against losing my passwords: I can record them elsewhere; I can reset them if I lose them. But the only reasonable countermeasure I can take against Mozilla stealing my password is to never login to a Firefox Account (the alternative, hand-verifying HTML and a JavaScript bundle myself on every login attempt, is patently unreasonable). So that's what I do: I don't use the Firefox Sync functionality, because the security of the system is broken.

zeveb 8y ago

> Our experience with Sync 1.1 taught us that this does not work with real people at scale; people often lost data as a consequence of this design. Far better to lose passwords, bookmarks & history than to have them exposed — which is what the current design does (because the user's password can be stolen if the users logs in to his Firefox Account via the HTML page). There are reasonable countermeasures I can take against losing my passwords: I can record them elsewhere; I can reset them if I lose them. But the only reasonable countermeasure I can take against Mozilla stealing my password is to never login to a Firefox Account (the alternative, hand-verifying HTML and a JavaScript bundle myself on every login attempt, is patently unreasonable). So that's what I do: I don't use the Firefox Sync functionality, because the security of the system is broken.