Does file data sync at the discrete login level happen on the client or the server?
I read your white paper and other help and couldn't find the answer to my question. If I updated a specific login on one device, regardless of which sync method is used, the local data file on all other devices should be updated to match. My question is, where and how does that happen. I'm assuming that a discrete login entry can't be updated (or does the latest dated one just replace all the others?) while the local data is encrypted.
If so, then where is the data file located when it is decrypted for modification. Is it on the client, as your security assurances would suggest, or on a server (Agile, iCloud, Dropbox, WLAN) somewhere? As I understand the way general syncing systems work, a star configuration is preferred where some central server entity is the "master" and each surrounding client entity is synced with the master in a round-robin fashion. At the completion of two rounds, all should have the same data. There are two ways this could be done, the first is preferred. The master file could be sent to the client which decrypts the master's data and its local copy, does the sync modifications, and sends the encrypted update back to the server to become the new master. The round robin then proceeds to the next client. The second less preferred method is the opposite, the client data is sent to the server and the server decrypts and synchronizes. This seems to be in violation of your security principles if unencrypted data ever exists on the server.
Does !PW operate as I described in a star type configuration and if so, does unencrypted data only ever exist on the client? Is the same mechanism used for iCloud and Dropbox as for Agile's server and WLAN server? Some of the forum answers given would suggest that what iCloud and Dropbox do is not well understood or controlled by 1PW.
It would be nice also to understand better at the individual login entry level how 1PW merges two different data sets.
1Password Version: 6.8.3
Extension Version: 4.6.11
OS Version: 10.12.6
Sync Type: iCloud currently
Comments
-
I'll let @rickfillion chime in with more detail, but i will say that data is never decrypted anywhere other than the local device. When you unlock 1Password it pulls down the latest data from the server or dropbox or iCloud and looks to see if there are any merge conflicts. When it's done it pushes the encrypted result up to the server where the other clients are able to retrieve it.
Rudy
0 -
Hi @Dave Toth,
Neither systems you describe match what we do. In the case of Dropbox, iCloud and 1Password.com, the server is responsible for detecting the presence of conflicts, and each achieves this through different means that are ultimately similar : upon client1 trying to upload a change to the server when client2 has uploaded another change that client1 hasn't dealt with yet, the upload fails (or in the case of Dropbox gets saved beside the expected file). It's then up to client1 to pull client2's changes, merge them with their own, and re-upload the item.
In 1Password, the server is responsible for coordination of data, and clients are responsible for merging conflicts.
I hope this helps.
Rick
0 -
Again, let me add that all decryption, whatever the synch mechanism, can only happen on your system. We never have the keys to decrypt your data.
You have asked a good and tricky question. But the answer does depend on the synch mechanism. I will elaborate on what @rickfillion said, but he probably understands the code and protocols for synching and avoiding conflicts more deeply than anyone else here. As he said, it is always the clients to perform the conflict resolution (as they are the only ones with the keys to decrypt items), but our service can play a greater role in trying to avoid conflicts in the first place.
It the old days (Agile Keychain via Dropbox) we used a combination of file modification date (this is what Dropbox used) and our own conflict resolution mechanism. It worked right for almost everyone almost all the time. But some of our long time users might recall having files in the Agile Keychain with names like
XXXXX.1password-conflicted-copy-hostname(or something like that, I can't remember now what we called those.)In the more recent past (using OPVault) we used file modification time as a first pass and an internal item modification date. We also had a checksum of the item to allow us to quickly identify that items didn't match. Again, there was a behind the scenes locally running conflict resolver that worked remarkably well given the difficult problems it is presented with. You might find items in your 1Password data with a section called "conflicts". This is when the conflict resolver doesn't want to throw out anything, but still makes a guess at what should take precedence.
With our service, we don't have to depend on someone else's file sync mechanisms. We can dramatically reduce the cases in which the conflict resolver is called into play. The server can read and modify item version information to items even though it can't decrypt those items. Also because with our own protocol we can get away with transmitting less data per synching operation than we would with the file-based systems, we can reduce the opportunity for conflicts to arise.
So the details really do depend on the synching system, but the constant is that conflict resolution is performed locally, although our server can help co-ordinate synching in ways that reduce conflicts.
0
