Hacker News new | ask | show | jobs
by beatle_sauce 2775 days ago
The new Firefox sync (v1.5) is surely great and has good usability, I preferred the old Firefox sync (v1.1), because it didn't require a Mozilla account (for password retrieval). The new service requires two servers for one's fully own setup (for managing accounts and a sync server), although it is possible to use Mozillas account server.

Also, from the description of the protocol ( https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc... ) it was not clear to me, what exactly is encrypted? Only the passwords? I had the impression that the bookmarks were stored in a way readable by Mozilla.

Update. It is not clear what kind of data is in "Class-A" as described here: https://wiki.mozilla.org/Identity/AttachedServices/Architect... ... It also says:

> we can share e.g. bookmarks with a third party (by telling them the decryption key)

1 comments

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-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.

> 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.