-> dbeam@ for triage.

In  Issue 724897  people suggested this might be an issue with the OS keychain.
I just checked my personal profile on my corp laptop (the original issue happened on my personal laptop) which runs Canary (my personal laptop runs Beta) and I see the passwords listed in chrome://settings (see screenshot)

So the only issue here is about password sync, which is tracked in 724897. I was misled by the message that seemed to suggest that I should have used necessarily passwords.google.com.

The only action I think should be left on this bug is just not showing that "passwords.google.com" link if I have a profile with passprhase, as in that case passwords.google.com is just going to bounce me back to chrome.

Deleted: Screen Shot 2017-05-22 at 4.32.18 PM.png 33.4 KB

	Screen Shot 2017-05-22 at 4.32.18 PM.png 33.4 KB View Download

Investigating this.

As an immediate workaround, you can get to the old setting page at chrome://settings-frame/passwords

Can you confirm that you are seeing passwords in chrome://settings-frame/passwords and not chrome://md-settings/passwords? Thanks!

I missed #2 when looking at this. Lowering priority and updating Summary.

Assigning to bettes@ to see if we should remove the link to passwords.google.com.

I feel we should keep the link because there are options there to change auto sign in and smart lock. Perhaps update the string since "Access your passwords from any device..." is not true when settings have a passphrase.

Another option is to update passwords.google.com to use the passphrase to unlock the passwords.

>> Another option is to update passwords.google.com to use the passphrase to unlock the passwords.

I don't understand the reasons why this wouldn't be true to begin with. Something tells me that this is just an unfortunate seam between two PAs.

We'd need a POC from the Google Passwords team to make a decision on this

>> I feel we should keep the link because there are options there to change auto sign in and smart lock. 

We should probably change the string to be more explicit and accurate for both passphrase_enabled and password_disabled users. It's a little unclear what the role of chrome://settings/passwords is if all the information is duplicated on passwords.google.com. Is this about locally saved vs. google saved? 

Passing this along to zkoch@ to prioritize and provide more direction on strings. It's possible that we should punt on this until more substantial passwords work can be done. 

I'm not sure it's a seam. I think there is quite a bit of technical work that would need to happen to make accessing these passwords on passwords.google.com viable. In general, though, the fate of passwords.google.com is uncertain, so I'm hesitant to invest there right now.

> It's a little unclear what the role of chrome://settings/passwords is if all the information is duplicated on passwords.google.com.

chrome://settings/passwords is much easier to use. passwords.google.com does a full GAIA re-auth, which can mean sending an SMS OTP, etc. In Chrome, it's faster and you just need your device p/w.

I agree we should remove this string for custom passphrase users.

I don't take issue with the current string. I think the fact that it's available across devices is useful and expresses the value statement, though open to making this more clear if we need to.