Thanks for your report.

is there a reason why you are using --user-data-dir rather than Chrome profiles (chrome://settings/people)?

I wrote a command-line script that manages (creates, destroys) profiles and launches Chrome with particular profiles. I'm not aware of a way to do that via the GUI that is quite as easy and smooth (i.e. call `chrome-wrapper foo-prof` and have it launch an instance with its own history, preferences, and potentially corresponding Google profile).

I could not reproduce this on 67.0.3396.87 on Linux.

by "local password storage of profile B" do you mean visit chrome://settings/passwords - or actually query the OS storage manually?

The passwords are visible on profile B at chrome://settings/passwords

This has been a persistent issue on multiple Xubuntu installations since at least 16.04 LTS, and still affect the latest 18.04.

hmm maybe it's using a different os_crypt password backend from me. Can you check histogram "PasswordManager.LinuxBackendStatistics" in chrome://histograms

Can you also try with Dev channel...?

This is the output for the histogram. I'll be happy to try Dev channel, how do I do that on Ubuntu?

Histogram: PasswordManager.LinuxBackendStatistics recorded 1 samples, mean = 10.0 (flags = 0x41)
0   ... 
10  ------------------------------------------------------------------------O (1 = 100.0%) {0.0%}
11  ... 

hmm I am also 10 which is "GNOME_NOFLAG_LIBSECRET" - so should be seeing the same behavior as you.

Are you signed into sync in the profile? Perhaps the passwords are syncing down?

You can try dev channel here -> https://www.google.com/chrome/browser/?platform=linux&extra=devchannel

I am somewhat embarrassed to report that I have found the likely cause of the issue.

To facilitate the fast creation of new profiles, I kept a "template" profile with a bunch of default configurations and pre-installed extensions, that the wrapper script would copy to a new data dir upon creating the profile.

It seems that profiles created from this template all share the same set of passwords, whereas profiles created from scratch (by providing a path of an empty directory to --user-data-dir) do not.

okay, glad to have found the issue. Thanks for the update. Marking WontFix.

Thanks. By any chance, is there a way to automatically configure Chrome instances, to replace the "template profile" method?

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot