Closed Bug 1627696 Opened 5 years ago Closed 5 years ago

The "Created" timestamp is wrongly updated for the logins saved/created when logged into FxA then synced on other profile

Categories

(Firefox :: Sync, defect)

Desktop
All
defect
Not set
critical

Tracking

()

RESOLVED INVALID
Tracking Status
firefox76 --- wontfix
firefox77 --- wontfix

People

(Reporter: cmuntean, Unassigned)

References

Details

Attachments

(1 file)

[Affected versions]:

  • Nightly 76.0a1 (Build ID: 20200406092400)

[Affected Platforms]:

  • Windows 10 x64
  • Mac 10.14.6
  • Unbuntu 18.04 x64

[Prerequisites]:

  • Be logged to FxA account.

[Steps to reproduce]:

  1. Open the Firefox browser with the profile from prerequisites.
  2. Navigate to "about:logins" page and create a new login.
  3. Go to the profile's directory and open logins.json.
  4. Change the "timeCreated", "timeLastUsed" and "timePasswordChanged" values of the created login to "1338544168000".
  5. Restart the browser and observe that the "Created" section is updated to June 1, 2012.
  6. Click the "Firefox Account" toolbar button and click the "Sync Now" option.
  7. Close the Firefox profile.
  8. Create and open a new Firefox profile.
  9. Navigate to "about:logins" and sync logins.
  10. Observe the login created in step 2.

[Expected result]:

  • The "Created" and "Last used" timestamp remains set to June 1, 2012.

[Actual result]:

  • The "Created" and "Last used" timestamp is updated with the current date.

[Notes]:

  • This issue affects the breached accounts since their create date is updated after syncing logins on other profiles. The breached accounts will no longer be marked as breached.
  • One strange thing that I have noticed is that if you create an account when you are not logged to FxA, then you log in to FxA, sync logins then even if you sync them on other Firefox profiles the "Created" and "Last used" timestamp is not updated for them.
  • I need to investigate more if this is also reproducible on Firefox 75 and 74 and if it's a regression.
  • Attached a screen recording with the issue.
Priority: -- → P3
Summary: The "Created" and "Last used" timestamp is wrongly updated for the logins saved/created when logged into FxA then synced on other profile → The "Created" timestamp is wrongly updated for the logins saved/created when logged into FxA then synced on other profile

Setting needinfo to find when this regressed.

Flags: needinfo?(cosmin.muntean)

Jared is right about last used and bug 555755 may change that.

It's not expected to be able to change logins.json outside of Firefox and have Sync work properly as Sync relies on listening for changes to storage while it's running. See, for example, the text on this project that imports passwords:

Note: If you have Sync enabled, you'll have to disconnect and reconnect your Firefox account after importing the passwords.

Is there STR doesn't involve editing the file outside Firefox? If not, this is WONTFIX IMO. It's at least not an about:logins bug, it would be a Sync one.

(In reply to Cosmin Muntean [:cmuntean], Ecosystem QA from comment #0)

  • This issue affects the breached accounts since their create date is updated after syncing logins on other profiles. The breached accounts will no longer be marked as breached.

Btw. only "Last modified" (timePasswordChanged) is relevant for the breach login calculation ("Created" is ignored). Both of these do Sync as long as you don't make the changes to the file outside Firefox.

  • One strange thing that I have noticed is that if you create an account when you are not logged to FxA, then you log in to FxA, sync logins then even if you sync them on other Firefox profiles the "Created" and "Last used" timestamp is not updated for them.

Are you talking about having matching logins already on this other device? How did you get them to the other device? Did you use Sync or manually re-created them? There is a difference between in one case the GUID will be the same but not in the other.

See Also: → 555755

Is there STR doesn't involve editing the file outside Firefox? If not, this is WONTFIX IMO. It's at least not an about:logins bug, it would be a Sync one.

Unfortunately, I haven't found other STR that doesn't involve editing the logins.json file. Not sure but probably this is the only way to reproduce the issue.
Also, I have managed to reproduce this on FIrefox 75 release, so probably this is not a regression or a current one.

  • One strange thing that I have noticed is that if you create an account when you are not logged to FxA, then you log in to FxA, sync logins then even if you sync them on other Firefox profiles the "Created" and "Last used" timestamp is not updated for them.

Are you talking about having matching logins already on this other device? How did you get them to the other device? Did you use Sync or manually re-created them? There is a difference between in one case the GUID will be the same but not in the other.

I will try to explain what actually happens and why I think this is a strange behavior. Please follow the following STR:

Create a new Firefox profile (let's name it profile A):

  • Step 1: On this new profile create a new login for https://dropbox.com, then edit the logins.json file in order to modify the "timeCreated", "timeLastUsed" and "timePasswordChanged" values to "1338544168000" then restart the browser. Now the login's "Created, "Last modified" and "Last used" timestamps are set to "June 1, 2012" and the login is marked as breached.
  • Step 2: Navigate to "about:logins" and singing to sync. Create a new login on dropbox and change the "timeCreated", "timeLastUsed" and "timePasswordChanged" values to "1338544168000" so the login to be marked as breached.
  • Step 3: Sync the profile by clicking the "Firefox Account" toolbar button -> "Sync Now" option. Close the browser.

Create another Firefox profile (let's name it profile B):

  • Step 1: Navigate to "about:logins" and singing to sync with the FxA account used above. Both created logins on Dropbox are synced, the timestamp is still set to "June 1, 2012" and marked as breached.
  • Step 2: In "about:logins" create a third login on Dropbox. Open logins.json and change the "timeCreated", "timeLastUsed" and "timePasswordChanged" values to "1338544168000" so the login to be marked as breached. Restart the browser.
  • Step 3: Sync the profile by clicking the "Firefox Account" toolbar button -> "Sync Now" option. Close the browser.

Create another Firefox profile (let's name it profile C):

  • Step 1: Navigate to "about:logins" and singing to sync. Observe the logins synced.

[Actual results]:

  • The first two logins created on profile A have the timestamps still set to "June 1, 2012" and marked as breached.
  • The third created login, that one on Profile B has the timestamps set to the current date and is no longer marked as breached.

However, if you think that this issue cannot be encountered by the users in any way we can close this issue as invalid.

Flags: needinfo?(cosmin.muntean) → needinfo?(MattN+bmo)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

(In reply to Cosmin Muntean [:cmuntean], Ecosystem QA from comment #4)

  • Step 2: In "about:logins" create a third login on Dropbox. Open logins.json and change the "timeCreated", "timeLastUsed" and "timePasswordChanged" values to "1338544168000" so the login to be marked as breached. Restart the browser.
  • Step 3: Sync the profile by clicking the "Firefox Account" toolbar button -> "Sync Now" option. Close the browser.

IIUC this doesn't actually Sync anything to the server at this point since the login wasn't changed (from the Sync engine perspective) since the change happened outside of Firefox.

Create another Firefox profile (let's name it profile C):

  • Step 1: Navigate to "about:logins" and singing to sync. Observe the logins synced.

[Actual results]:

  • The first two logins created on profile A have the timestamps still set to "June 1, 2012" and marked as breached.
  • The third created login, that one on Profile B has the timestamps set to the current date and is no longer marked as breached.

This aligns with what I expected and is the reason for the warning in that other project's README. Sync only tracks changes from within Firefox so edits to logins.json aren't tracked. The Sync engine doesn't check that everything on the client still matches everything on the server on every startup. If you change the username of the saved logins that would cause it to be uploaded to the server, otherwise you can reset the sync state for the logins engine, or disconnect and re-connect Sync to have it compare everything again.

However, if you think that this issue cannot be encountered by the users in any way we can close this issue as invalid.

I think it's only in edge cases or when users use external tools to manipulate logins.json but disconnecting and re-connecting Sync would address it. The Sync team would know more details about this so you could move this to the Sync component if you want to dig into it farther. Otherwise I would mark it as WONTFIX. I'll leave that up to you to decide.

Flags: needinfo?(MattN+bmo)

@Matthew, thank you for looking into this.

I will move this bug in the Sync component to see if the Sync team has any concerns regarding this issue. If not we can close it.

Component: about:logins → Sync

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Priority: P3 → --
Flags: needinfo?(markh)

Hi Mark, is someone looking at this? Can you please (let) triage this bug? Thank you!

Sorry for the delay, but all the above information from Matt and Jared is correct - Sync simply doesn't know that the login needs to be resynced when the .json is edited. However, even if it did see only lastUsed change, it still wouldn't force a sync in that case - and finally, if it did sync a timestamp which moved lastUsed backwards 8 years, we'd probably consider that a bug anyway (because clocks are hard :)

So as per comment 7, I'm closing this.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(markh)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: