Sync turned on all options this morning and synced EVERYTHING (including history and Extensions) from my work laptop to my private PC. I always had only tabs and passwords enabled. Yesterday I reset my sync password, which must have caused this.

Are there any error logs in about:sync-log on the machine on which you first entered your new password?

> Yesterday I reset my sync password, which must have caused this. I believe it did. Since we remap the sync node on password reset, it makes sense that we would lose this information after password reset.

(In reply to Chris Karlof [:ckarlof] from comment #2) > Since we remap the sync node on password reset, it makes > sense that we would lose this information after password reset. The same datatype elections should be reuploaded as part of meta/global by one of the configured clients as soon as they get the new node assignment. Node reassignments happen(ed) all the time, and are expected not to affect your choices. That makes me think of Bug 692620, coupled with Bug 615926, unless the new FxA password change process is clearing some prefs or state it shouldn't.

These are todays logs - the earliest one has a timestamp of 1:52 PM but the error happened in the morning. Hope it is helpful. there are no error logs on the other machine.

(In reply to Chris Karlof [:ckarlof] from comment #2) > > Yesterday I reset my sync password, which must have caused this. > > I believe it did. Since we remap the sync node on password reset, it makes > sense that we would lose this information after password reset. Shouldn't the "what is synced" be stored in the profile locally? I had a nasty surprise as all my addons and history migrated over to my work laptop. Also, quite a few of my (newer & more recently modified) SSO passwords were reverted to their old versions. Is there no safeguard against updating older login info? I was able to revert the passwords using my Addon QuickPasswords, but still. (I don't really want to use LastPass just needed to see what the competition does - too complicate for my taste)

(In reply to Axel Grude [:realRaven] from comment #5) > Shouldn't the "what is synced" be stored in the profile locally? It is: see the services.sync.engine.* prefs. The trick is that those prefs are authoritative in some circumstances and not in others -- for example, if you open prefs and check "Bookmarks" on one device, it'll write a new meta/global to the server, and your other devices will download it and apply the changes to enable bookmark sync. The opportunity for bugs comes when errors occur during the critical first sync to a new node; see my Comment 3. I might speculate that something like this happened: * You reset your Sync credentials on Client A. * Client A gets a new node assignment and tries to sync. * It uploads a blank meta/global, then fails before it uploads a client record. * Client B syncs. It sees the blank meta/global, applies the heuristic from Bug 615926 or friends (the remote empty m/g is newer, and the local m/g is unmodified), and decides that all engines should be enabled. It successfully uploads meta/global. * Client A sees the new meta/global and treats it as authoritative. or: * You set up a new client, resetting your FxA password to do so. * It syncs successfully, with no data, and all engines enabled by default. * You enter your new password on one of your old devices, and it joins the new constellation, applying the server meta/global. Any choices you made on an earlier client will be overwritten by the new choices that the new client made. > laptop. Also, quite a few of my (newer & more recently modified) SSO > passwords were reverted to their old versions. Is there no safeguard against > updating older login info? Here's a hypothetical scenario. Computer A has a password P1(a), your old site password, modified at time CAT1. Computer B has a password P1(b). You just changed it at time CBT2. Now you reset your Sync password on Computer A. It gets a new node assignment and uploads P1(a), which gets a server modified time ST3. Call this P1(s) You log in with your new Sync credentials on Computer B. It gets the new node assignment, and downloads every record that Computer A uploaded, in order to reconcile and achieve a unified state. It sees that P1(s) differs from its local P1(b). Furthermore, P1(b) was modified at CBT2, which is earlier than ST3. (This is the only time that Sync compares a server timestamp to a client timestamp.) It resolves the conflict by overwriting the local password with the 'newer' server password. From Sync's perspective, the server password is newer. This issue arises because client clocks aren't compared directly; the server is the arbiter of changes. Sync, unfortunately, uses server timestamps as its core coordination point. This scenario can only occur in long-term disconnected operation or during node reassignment. It's almost an inevitable consequence of a syncing solution that allows for offline changes but doesn't record full change histories. This is very similar to Bug 720592, which I'm mulling over as part of some extensions to the password record format.