Password Database Saving and Collisions - How does it operate in 1Password?

xantarixantari
edited December 2020 in Memberships

Say I have 1Password open on 5 different browsers on 5 different PC's.

Each one adds a new password.

Do all 5 succeed and get merged into the single cloud database or will there be conflicts?

What about updates?

If 5 computers did 5 simulatenous updates at one time, do all 5 succeed, but last one wins and all 5 changes will show up as history items on the item? Or will there be race collisions?

Comments

  • Good question. Less likely to occur in single user or even family environments, but I could definitely see the potential for conflicting demands in a multi-user business environment.

  • ag_anaag_ana

    Team Member

    Hi @xantari!

    I have forwarded your question to our developers, there is no better team to answer it :) We will post back here as soon as we have an update :+1:

  • rickfillionrickfillion Junior Member

    Team Member

    This is such a great question @xantari, and this is one of my favorite topics.

    The short answer to your questions...

    Do all 5 succeed and get merged into the single cloud database

    Yes.

    What about updates?

    It depends on which apps you're using and the kinds of changes you're making. I'm assuming that all 5 devices are editing the same item which is the hard scenario. If all devices are editing different items then the answer is a simple "it works just as you'd expect."

    Now that the short version is done with, let's jump into the long version!

    @williakz is right that with more people there's a higher probability of this kind of event happening. And these corner cases of sync were a primary motivator for us to build 1Password.com in the first place. By controlling every aspect of sync ourselves we can build something far far more resilient than otherwise. It was a requirement for us to design a system that would work with an arbitrary number of users and devices syncing the same vault. Our design has worked out super well in that respect.

    Each 1Password device has a local copy of the data in the vault and it's designed to work offline. When you create an item in any of our apps except 1Password X or the 1Password Command-line Tool it simply saves the item to the local database and triggers sync with the server to push it up to the server if you're online. The server has the job of coordinating the exchange of items. Because 1Password is end to end encrypted, there's only so much that the server can do to help, but it can play the role of coordinator. It has some pretty simple rules, and the most important in this case is that a device can only update data on the server if it has first downloaded all updated data from the server first.

    So the first device that comes online in your scenario has all of the updates from the server already so it's allowed to push up either the new item or the updated item. That one is easy. Where it becomes just a bit more complicated is the next devices. The next device comes online and the server will say that there's updates it needs to download before it can upload any changes. In the case of a new item it just needs to download that new item and then it can proceed. In the case of an edit of an existing item the app downloads the edit and needs to decide what to do with it. If this device has not edited this same item then it's easy: just replace the item with the version from the server. If this device also has an edit to this item then it has to deal with it as a merge conflict. This is where the "it depends" comes in. There are two ways that an app can deal with the merge conflict: the easy way and the hard way.

    The easy way is to do as you said: throw away the server edits and keep your local edits. This way when you push the local edits to the server this device can know that its changes made it up to the server and should the user need to find other edits they can find them in the item history.

    The hard way is to try to keep both. This requires deep analysis of the edits. If one device edited only the title of the item and another device edited the notes on the item then these changes can be merged together into a unified version. It gets tricky when you've got cases like both sides editing the same piece of data. What do you do if both sides changed the notes? Well you could try to correctly merge them understanding that there's no solutions that are 100% there. What do you do if both sides changed the password? You can't merge those together, but you also don't know which is the actual correct one. At best you can make an educated guess at which we should keep, but then what do you do with the other version? In our case we add it as a field under a section called Conflicts in case the app chose wrong.

    1Password for Mac, iOS, Windows do the hard way. 1Password for Linux, Android, Web do the easy way. I suspect that in the future we'll be migrating them all to the easy way (I could be wrong there).

    All this to say that when you have 100% control of the sync experience as we do you can paint the ugly corner cases of sync into quite small places and come up with reasonable mitigation strategies. We now have vaults shared with tens of thousands of devices, possibly even hundreds of thousands of devices and it all "just works."

    I hope this helps! If you have any more questions about sync don't hesitate to ask. As I said this is one of my favorite topics.

    Rick

  • Wow! Thanks for the look "under the hood," @rickfillion. Definitely a big advantage having direct access to the "engine." I was guessing some sort of spinlock mechanism. Cool that your architecture allows a more sophisticated approach.

  • rickfillionrickfillion Junior Member

    Team Member

    You can think of the server coordination as a very big spinlock. It will only allow one device to enter the critical section of updating the vault contents for that vault at any given time. One big shared lock like that isn't a great design for a lot of things, but for this case it works very well.

    We're always happy (if not eager) to share how things work under the hood.

    Cheers.

    Rick

  • Thanks for the indepth reply!! Appreciate it.

  • ag_anaag_ana

    Team Member

    On behalf of rickfillion, you are very welcome @xantari! If you have any other questions, please feel free to reach out anytime.

    Have a wonderful day :)

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file