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