When device clocks disagree
Dropbox Passwords relies on zero-knowledge encryption, meaning the private keys for a user's stored credentials exist only on their local devices. The server cannot decrypt payloads, so it also cannot act as a source of truth for which version of an item is most recent. That responsibility falls entirely to the client software.
When syncing encrypted login items between devices, Dropbox engineers initially implemented a straightforward two-way merge. If a user edited an item on one device, the client would update its local payload, download the server's version of the same payload, compare timestamps, and keep whichever item was newer.
A successful merge and sync.
The logic seemed sound, but testing revealed a troubling pattern: sometimes an older edit would overwrite a newer one. The root cause turned out to be clock skew—the difference between a device's internal clock and actual time. A computer with a clock set even a few minutes behind could mark a legitimate recent change as older than a stale edit made on another device with a more accurate clock.
An example of a failed merge. Note that the timestamp on the newer change is older than the stable version.
Introducing a base payload
The fix borrowed from a concept already familiar to anyone who uses Git: the three-way merge. When merging two branches without a linear history, Git relies on the common ancestor of both branches to determine what actually changed. The Dropbox desktop client already uses this pattern for file syncing, so extending it to password payloads was a natural fit.
The two-way merge failed because there was no revision history locally, forcing every decision to rest on fallible timestamps. Adding a third copy of the payload solved that problem. Each client now tracks three states:
- local — the payload the user sees on their device
- remote — the payload stored on the Dropbox server
- base — the payload from the most recent successful sync on that client
Instead of comparing local and remote timestamps directly, the client now generates a diff between local and base, and another diff between remote and base. Any difference found in one diff but not the other indicates a non-conflicting change that can be applied safely. Only when an item appears in both diffs—meaning both devices edited the same item since the last sync—does the client need to fall back on timestamps to pick a winner.
A successful merge and sync with skewed clocks.
Conflict resolution under normal conditions
This approach does not eliminate clock skew entirely. A true conflict still requires two devices with mismatched clocks editing the same item between syncs. That is a much narrower window than the original problem, where a single edit on a skewing device could clobber an unrelated newer change. In typical usage, the three-way merge resolves most versions without ever consulting timestamps.
Since rolling out the three-way merge to general availability, Dropbox reports that the sync logic has been markedly more robust. That stability mattered as the team added password sharing and payment card items throughout 2021—features that would have made the old two-way merge failure mode especially painful.
