A Better Firefox Sync
blog.mozilla.org
blog.mozilla.org
What I don't understand is why does it first ask you for a pair code from another device? My only other device was a desktop far away. After I logged in and clicked "reset sync key" it apparently lost all of the synced data!
I seriously hope this solves the currently heinous sync process. Just let me log in an authorize myself for goodness sake.
In the old system, the pair code was effectively a password. It's obvious that resetting the sync key wiped out your synced data; the synced data was encrypted with the old key and generating a new one obviously wouldn't let you decrypt it. (It's possible the old key can still be used to recover the data, but I'm not sure).
Complaining that it demanded a pair code is like complaining that gmail asks you for a 2fa code after you've turned on 2fa. Of course it does, that's how the security works.
Of course, the pair code system is kind of a pain, so they introduced passwords. But the pair code system does work if you use it correctly. I don't think it's fair to call it 'completely borked' when your problems are entirely down to user error.
Keep in mind that Firefox Sync always protects all your profile data; Mozilla can't access it because your machines encrypt it. This is unlike Chrome's profile sync where all the data lives on Google's servers and is accessible to them. As a result the authentication can't be as simple as 'sign in with your gmail account' or something like that.
This is not true. When you configure chrome's sync you can set an encryption password separate from your Google password and select items for encrypted sync.
Though in my opinion Firefox Sync had the better method here security wise.
Also, quick addendum: you _can_ specify an addition password in Chrome so your data is encrypted before it gets sent to Google. It's pretty much identical to FF Sync then, and much more user friendly.
Notably Chrome sync does let you encrypt all data locally, but it works the same way: if you lose your passphrase, you can't sync a new machine with it.
The big difference is that it's also tied to an account, which lets you do things like use it as a backup and restore service (the analog would be a pair code that's persistent and well known to the user). The current Sync pair code system makes your synced data just an extension of the data in your browser (or browsers, if you already use more than one). Lose that browser and you lose your data. The new Firefox Sync looks like it provides that now, which should ease a lot of user pain due to lost data (and not just annoyance).
Except that I can change my password on Facebook without losing all my data and change my bank PIN without losing my money.
The truth is that isn't a password at all.
And it was completely borked. The 2nd most common use case for Chrome Sync for me is logging onto a new computer and wanting my bookmarks. If I had my other computer with me I wouldn't be logging onto a new computer!
No where in the user-flow did it say anything about losing data if you reset the recovery key. These confusions are why they're changing the FF sync system!
the new sync actually seems to have plans for a recovery key and be a "backup system", which seems more inline with users expectations
class-A: data assigned to this class can be recovered, even if the user forgets their password, by proving control over an email address and resetting the account. It can also be read by Mozilla (since it runs the keyserver and knows kA), or by the user's IdP (by resetting the account without the user's permission).
class-B: data in this class cannot be recovered if the password is forgotten. It cannot be read by the IdP. Mozilla (via the keyserver) cannot read this data, but can attempt a brute-force dictionary attack against the password.
- https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc...
We do not yet know which data will be assigned to which category by default, but it is likely that saved-passwords will go into class-B, and many other datatypes will default to class-A. There will be an option to put all data into Class-B.
- https://wiki.mozilla.org/Identity/AttachedServices/Architect... (not sure if out of date)
...and for good reason, because since Mozilla presumably wants to avoid being required to hand over account data by governments to the greatest extent possible. Being able to reset your password via email necessarily makes it possible for Mozilla to decrypt that data.
personally, i perfectly understood the old scheme and found it great, but apparently that's not your case neither the general case.
If a user couldn’t figure out how to set up Firefox Sync previously by following the instructions and taking a set of digits from one device and entering them into another, what hope have they of picking a strong and unique password?