537653 - Merge can silently discard a newer password

Status: RESOLVED FIXED

(Firefox :: Sync, defect)

Description

[Henri Sivonen (:hsivonen)]

Version Weave 1.0 rc.

Steps to reproduce:
 1) Set Firefox on one computer to remember the password for a site.
 2) Copy the Firefox profile to another computer.
 3) Install Weave on the first computer and set up an account.
 4) Change the password for the site on the first computer.
 5) Quit Firefox on the first computer.
 6) Start Firefox on the second computer.
 7) Install Weave on the second computer.
 8) Tell Weave to merge data.
 9) Try to log in to the site from either computer.

Actual results:
The site password is silently overwritten with the stale password from the second computer.

Expected results:
Expected passwords to have a timestamp of change and expected the last changed password (from the first computer in this case) to take precedence. If a timestamp doesn't exist and can't be made exist in shipped versions of Firefox, expected the merge function to prompt the user to choose which password to retain.

Comment 1

[Mike Connor [:mconnor]]

Password Manager doesn't have timestamps, IIRC.  Dolske, is there a bug on that?

Comment 2

[Justin Dolske [:Dolske]]

Bug 465636.

In the meantime, I'd probably suggest that in the event of a conflict, Weave automatically prefer the data from the Weave server. Seems more likely that people would set up Weave on a active/working system first, and later add in other devices that might be stale. Put another way, that minimizes the risk of having one newly added device clobber data that was already working on your other devices.

Of course doing this automatically will still be wrong in certain cases, but I suspect we don't want to risk deluging the user with a bunch of merge prompts.

Our of curiosity, when Weave syncs does it check to see if the client's clock is correct? Otherwise timestamps from systems with radically different clocks could cause some strange behavior.

Comment 3

[Ed Lee :Mardak]

Bug 550627 keeps track of when changes happen and compares the how long a record has been sitting on the server vs how long ago the password was changed locally.

Comment 4

[Ed Lee :Mardak]

This isn't as perfect as using the timestamps from the storage as we compare how long the record has been on the server. Because there can be a gap in time from when the change was made and when it actually ended up on the server, a record might seem younger.