New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 636461 link

Starred by 1 user

Issue metadata

Status: Fixed
hobby only
Closed: Aug 2016
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug

Sign in to add a comment

Security: Overzealous password autocomplete unmasks Incognito users

Project Member Reported by, Aug 10 2016

Issue description

Google Chrome's password autofill can take place automatically even while Incognito, allowing a website to correlate a user's Incognito activity with their non-Incognito activity.

This is a variant of the issue IE had a for a short period:

Chrome Version: Version 54.0.2825.0 canary (64-bit)
Operating System: Windows 7

1. Outside of Incognito, in a non-corp account that allows SmartLock password autofill, visit 
2. Enter a password and submit the form.
3. Elect to save the password.

4. Close the browser and open a new Incognito instance.
5. Visit 
6. Click anywhere outside of the autofill box.

OBSERVE: Password field autofills.

Comment 1 by, Aug 10 2016

Components: UI>Browser>Incognito Privacy
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Restrict-View-Google Type-Bug
+some privacy folks, and flipping labels.

s/RVST/RVG/ just in case.

Comment 2 by, Aug 11 2016

Labels: Hotlist-Polish OS-Linux Pri-2
Status: Started (was: Unconfirmed)
Oops, this is a bug, and I can also reproduce on Linux. Thankfully it is not the case on every website (e.g., works fine), but still a bug.

Looking into it.

Comment 3 by, Aug 11 2016

PasswordAutofillAgent::TextFieldDidEndEditing feels the need to fill the current password field in cases when the "don't autofill" flag is on. This causes the observed bug.

I'm looking further into the code to understand why PasswordAutofillAgent::TextFieldDidEndEditing behaves in this way.

Comment 4 by, Aug 11 2016

The code there is to allow filling after the user typed the username without actually selecting suggestions. It is unclear why this only happens in the case when Chrome decides against autofilling. The behaviour has been there since porting from WebKit in 2010

It is unclear what this behaviour's benefits are. It even seems like contraproductive in cases when the user tries to type in their username without using suggestions to prevent autofilling. Getting rid of this code would make PasswordAutofillAgent simpler again, in addition to fixing this bug. I spoke to dvadym@, and it looks like a good idea to us to remove the code. I will give heads-up about this on today's team meeting as well.
Able to reproduce the issue with on mac win and Linux using chrome version 52.0.2743.116 and canary 54.0.2826.0

This is working fine with

Comment 6 by, Aug 11 2016

Uploaded, waiting for bots to turn green before sending out for review.
Project Member

Comment 7 by, Aug 11 2016

The following revision refers to this bug:

commit 36c4ef576660b52e1a5750b313ae3031ea1b4e81
Author: vabr <>
Date: Thu Aug 11 15:22:50 2016

Remove PasswordAutofillAgent::TextFieldDidEndEditing

PasswordAutofillAgent::TextFieldDidEndEditing provided special handling for
situations when automatic filling was blocked (Incognito, PSL-matched
credentials, etc.): in those cases, when the user filled the username to match
some of the fillable credentials, that credential was filled even though the
user did not select a fill suggestion.

It is no longer clear what was the motivation for this behaviour. The code has
been like this before it was ported from WebKit in 2010. It seems unnecessary,
a little unexpected, and leads to a bug when a page can trigger autofill of
credentials with empty usernames in cases where they should not be autofilled
(e.g., Incognito).

Therefore, this CL removes PasswordAutofillAgent::TextFieldDidEndEditing and
the associated functionality: credentials are now only filled when the user
selects a suggestion (or when the credentials are fit for automatic filling).
BUG= 636461 

Cr-Commit-Position: refs/heads/master@{#411335}


Comment 8 by, Aug 11 2016

Status: Fixed (was: Started)
elawrence@, can we lift the view restriction?
Labels: -Restrict-View-Google
Sure, done.

Sign in to add a comment