This bug report complains that users may borrow another user's logged-in Chrome instance and choose "Save Password", inadvertently saving that password into the original logged-in user's sync'd passwords.

Probably duplicate of either  Issue 659135  or  Issue 658588 

I 'm not happy with the state of our disclosure that "sign in" causes "sync", but the behaviour is intentional. Saving passwords like this is an intended use case, and per  Issue 659135  and [1] we do not plan to address this from a security perspective. (And users should generally not save passwords in computers that they don't own if other people have access.)

This report is asking us to prevent *accidents* in the special-case the state where a user gets a "save password" prompt while logging into a@gmail.com on the web, but signed into a@gmail.com in the browser, by adding a warning/message will help users catch if tis is unintended.
I don't immediately see another bug for that, but I don't think it's out of the question to add a new special case to GMail logins (I think we already prevent saving the password for an account if that account is logged in with password sync?).

sabineb@, battre@: Has this been considered, and/or is there a reason we wouldn't do it?
Feel free to close if we do not intend to add such a warning.

[1] https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-

+ewald,msarda who work on sign in and account consistency

English translation:
Vulnerability Details
When Google Chrome passwords are stored in Chrome on shared workplaces, it can happen that they are unintentionally stored in other peoples' Google account.
A concrete scenario that took place at our university is the following: Presentations are given from a common computer and are typically stored in the respective Google Drive. The first user logs in to Google Chrome, and the credentials of all users who present something are saved into the first Google Account, provided the users confirm the Save password dialog with Yes. This can happen because the following users may not be aware that the passwords are not stored locally and assume that they are discarded when the machine is reinstalled after the logout.

Reproduction case
1. Log in to Google Chrome using your own Google account [A@gmail.com], by clicking the "Sign into Chrome" button.
2. Visit arbitrary pages, such as drive.google.com
3. Logout of the user A@gmail.com (click on the user icon and "log out")
4. User B (B@gmail.com) logs on to drive.google.com, for example, and selects the option Save password because it assumes that the logon information is discarded when the computer is shut down, not knowing that their information is stored in this case not locally, but in the account of A.
5. Since A@gmail.com was logged into Chrome during the process, he can view the log-in data (email and password) of B, under the section "Manage password" after entering the Windows password in the plaintext and access other accounts. This is not only possible on the computer on which A and B have left their data since the data are stored in the account.

Solution:
If a user is signed in to Google Chrome with A@gmail.com, a warning should appear if you want to log in to B@gmail.com, while A@gmail.com is logged into the browser. If necessary, a warning should appear that the user data are not stored locally but in the account of A in order to generate the necessary awareness at B.

A few thoughts.

First, this entire issue will be solved with identity consistency. When user A clicks "sign out," they will be signed out of the browser (and they will stop syncing).

Second, the real issue here is that user A is signing *into Chrome*, instead of just signing *into Google services*. If user A is on a shared machine and just wants to access a Google web service (such as Google Drive), there is no reason for that user to sign into Chrome (and enable Chrome Sync). The user should instead be signing into Google, e.g. by navigating to drive.google.com and signing in.

I'm not sure why user A clicked a native "sign into Chrome" button instead of signing in through the content area. We also have a modal confirmation dialogue after the user finishes signing into Chrome, warning them that this will cause saved browser data to be synced to their Google Account (note that passwords are *explicitly* mentioned as one of these data). I'm not sure why this warning wasn't successfully deterring user A in the described scenario from signing into Chrome, but we fully disclose what the consequences for signing into Chrome are.

Overall, I don't think there's any action to take here, and I believe we should mark this as WontFix. I will defer to Sabine and let her comment on the idea of showing a special-cased warning dialogue when trying to save an @gmail.com password for an account that's different than the syncing account, but I don't think that really makes sense.

As Eli explained at comment #4, this will be fixed by the identity consistency. Maybe we should mark this as a duplicate of the identity consistency feature meta bug.

Marking as Polish, because that's how we mark user-facing issues in the Passwords component.

Thanks for the report.
I'm archiving this, though, because as explained above, Chrome team is aware of the issues with confusion between browser- and content-site sign-in.