6 ms·
Just today I reinstalled Ubuntu on a laptop and the sync completely borked. What I don't understand is why does it first ask you for a pair code from another d
by mikegioia 13y ago
Just today I reinstalled Ubuntu on a laptop and the sync completely borked.
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.
- kevingadd 13y agoAside from the fact that yes, pair codes are annoying - it sounds like you didn't understand Sync at all and were upset that it wouldn't compromise basic security guarantees for ease of use? 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.
- ultramancool 13y ago> This is unlike Chrome's profile sync where all the data lives on Google's servers and is accessible to them. 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.
- zobzu 13y agohad, yes. i liked it better. but it seems very few understood it.
- magic_haze 13y agoI don't think it's still as simple as entering your username/password if you don't have your paired device nearby: you also need a recovery key. I got bitten by this once: I didn't remember entering, or even being asked about a recovery key when I set up my account, so I was forced to reset my data. Luckily, I still had my bookmarks in Chrome, so I didn't lose any data, but the entire experience was frustrating. 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.
- mikegioia 13y agoThis was exactly what happened. I didn't know what the recovery key was and reset that thinking it was okay to.
- magicalist 13y agoThis is a bit unfair, since, as you admit, these changes are being made precisely because users don't understand the sync model, and the mismatch causes things like lost data. 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).
- wtallis 13y agoI'm pretty sure the pairing code system came along quite a while after password-based encryption and authentication. I've been using Firefox Sync since it was branded Mozilla Weave, and the first time I came across the pairing code thing it was an unpleasant surprise that was totally at odds with my prior experiences with associating a new computer. I had previously had no trouble adding a new machine without direct access to a previous machine.
- nl 13y agoIn the old system, the pair code was effectively a password. It's obvious that resetting the sync key wiped out your synced data 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!
- mikegioia 13y agoThis is a ridiculous and rather arrogant response. First off, if the user doesn't understand something, you can't just always blame the user. It in fact did completely bork my synced data. I don't care what you want to call it, if user's lose data there's a problem somewhere in the design of the sync system. 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!
- zobzu 13y agothere is no recovery key in old sync AFAIK. you delete the single, only mail key. (also, that's why old sync is "not a backup 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
- comex 13y agoTrue, if you accidentally lost data, this suggests the documentation should be better. But this is not entirely changing: 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-protocol 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/Architecture#Data_Security 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.
- zobzu 13y agothat's the old sync.the new sync TFA is talking about doesn't have this functionality at all. personally, i perfectly understood the old scheme and found it great, but apparently that's not your case neither the general case.
- pekk 13y agoIsn't this the old sync you are talking about?