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

Issue 798492 link

Starred by 34 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1
Hotlist-2


Sign in to add a comment

Users can be tracked via password manager

Project Member Reported by elawrence@chromium.org, Jan 2 2018

Issue description

https://freedom-to-tinker.com/2017/12/27/no-boundaries-for-user-identities-web-trackers-exploit-browser-login-managers/

tl;dr: Third-party scripts are collecting username info that is autofilled by Chrome's password manager and sending a (hashed) version of that data off to a third party site. This happens without explicit cooperation of the first party site and without any notice to the user.

Chrome's "Fill on account select" option: chrome://flags/#fill-on-account-select  is a mitigation, but requires manual activation (see https://textslashplain.com/2017/12/28/taking-off-your-nametag/).
 
Labels: OS-iOS

Comment 2 by zkoch@chromium.org, Jan 2 2018

Summary: Users can be tracked via password manager (was: Users can be tracked via autofill)
Updating title to more properly reflect, as all Autofill types require user action.

Comment 3 by zkoch@chromium.org, Jan 2 2018

Components: -UI>Browser>Autofill UI>Browser>Passwords
Owner: dvadym@chromium.org
Status: Assigned (was: Untriaged)
dvadym is planning to keep the username hidden until the first interaction with the page as a mitigation (this is already the case for the password) - though with an arguably limited effect.

A longer term approach could be to introduce a setting where the user can choose between autofill, fill on account select, and fill after typing a master password / scanning a fingerprint.


Comment 5 by yn...@vivaldi.com, Jan 3 2018

Does "interaction" mean just focus/mouse/scroll events, or does it mean actually user-initiated focus of a form field? In my (non-HTML/DOM-expert) opinion, only the latter will really mitigate the issue.

Comment 6 by dvadym@google.com, Jan 3 2018

 yn...@vivaldi.com: Interaction means that users clicks or types into content area. 
The idea of passwords autofill is to make login as simple as possible, introducing requirement of user initiated focus would require additional clicks (on username and/or password click).

One of the idea that we had is to wait until the user clicks on a submit button, but many sites don't use button/input elements, it's very hard to guess what's a submit button in each particular case.

Adding a setting for turning off, probably would be a solution for privacy concerning users (i.e. to make filling like in Incognito). As it's written in comment 4 we're considering to add additional user gesture for filling.

Comment 7 by yn...@vivaldi.com, Jan 4 2018

Thanks for the clarification.

Moving on, looking at the more fundamental reasons for the issue (all external Javascript have access to everything in the document) and potential long term solutions (not for the short term): Is it really necessary that every externally loaded Javascript must have the broad access they do have? At the very least, shouldn't the parent document grant permissions. While there may be external scripts that require such deep access, IMO Advertisers, analytics scripts, etc. doesn't really need such access and should be denied it by default. Such a change will probably require a lot of standards work, as well as development of more granular access frameworks.
Cc: se...@chromium.org
 Issue 798879  has been merged into this issue.
Labels: Hotlist-ConOps
This question has come up in our community forums (like here: https://productforums.google.com/forum/#!msg/chrome/9jSoxSdiIKg/aIY0LeR6AQAJ). Can we direct users to star this bug?
RE #9: Suggesting users star this Issue (and/or read the blog post cited in the comment #0) seems appropriate. 
Cc: tnagel@chromium.org
Project Member

Comment 12 by bugdroid1@chromium.org, Jan 8 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f69d6349c5e6be22df72d21b1f9f883ac9350870

commit f69d6349c5e6be22df72d21b1f9f883ac9350870
Author: Vadym Doroshenko <dvadym@chromium.org>
Date: Mon Jan 08 10:26:51 2018

Do not reveal username value till user gesture.

Passwords are not available for a page till user gesture.
But for usernames it was not implemented. This patch implements
this: use SetSuggestedValue for username and register
username_element to gatekeeper, which manages revealing
the input suggested value to JS after user action.

Along the way, a small improvement was implemented, setting
the username value only in one place which simplifies the code.

Bug: 798492
Change-Id: Ib37637dd861f44b94674c6d0060ebc91dfd73cff
Reviewed-on: https://chromium-review.googlesource.com/850394
Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
Reviewed-by: Dominic Battré <battre@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527598}
[modify] https://crrev.com/f69d6349c5e6be22df72d21b1f9f883ac9350870/chrome/browser/password_manager/credential_manager_browsertest.cc
[modify] https://crrev.com/f69d6349c5e6be22df72d21b1f9f883ac9350870/chrome/browser/password_manager/password_manager_browsertest.cc
[modify] https://crrev.com/f69d6349c5e6be22df72d21b1f9f883ac9350870/chrome/renderer/autofill/password_autofill_agent_browsertest.cc
[modify] https://crrev.com/f69d6349c5e6be22df72d21b1f9f883ac9350870/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/f69d6349c5e6be22df72d21b1f9f883ac9350870/components/autofill/content/renderer/password_autofill_agent.h

Owner: ----
Status: Available (was: Assigned)
I've landed a mitigation to this issue. Username is revealed to JavaScript only after user gesture in content area.
Project Member

Comment 14 by bugdroid1@chromium.org, Jan 8 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c43a88e2214e3173568cac5256b57d0f7d22ac15

commit c43a88e2214e3173568cac5256b57d0f7d22ac15
Author: Vadym Doroshenko <dvadym@chromium.org>
Date: Mon Jan 08 13:52:55 2018

Revert "Do not reveal username value till user gesture."

This reverts commit f69d6349c5e6be22df72d21b1f9f883ac9350870.

Reason for revert: this CL breaks many tests on build bots,
eg. 
https://ci.chromium.org/buildbot/chromium.memory/Linux%20ASan%20Tests%20(sandboxed)/42554 and 
https://uberchromegw.corp.google.com/i/chromium.chromiumos/builders/linux-chromeos-rel/builds/4123

Original change's description:
> Do not reveal username value till user gesture.
> 
> Passwords are not available for a page till user gesture.
> But for usernames it was not implemented. This patch implements
> this: use SetSuggestedValue for username and register
> username_element to gatekeeper, which manages revealing
> the input suggested value to JS after user action.
> 
> Along the way, a small improvement was implemented, setting
> the username value only in one place which simplifies the code.
> 
> Bug: 798492
> Change-Id: Ib37637dd861f44b94674c6d0060ebc91dfd73cff
> Reviewed-on: https://chromium-review.googlesource.com/850394
> Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
> Reviewed-by: Dominic Battré <battre@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#527598}

TBR=battre@chromium.org,dvadym@chromium.org

Change-Id: I53dba03674f0fa93f077f51dd481d951f8036825
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 798492
Reviewed-on: https://chromium-review.googlesource.com/852501
Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527627}
[modify] https://crrev.com/c43a88e2214e3173568cac5256b57d0f7d22ac15/chrome/browser/password_manager/credential_manager_browsertest.cc
[modify] https://crrev.com/c43a88e2214e3173568cac5256b57d0f7d22ac15/chrome/browser/password_manager/password_manager_browsertest.cc
[modify] https://crrev.com/c43a88e2214e3173568cac5256b57d0f7d22ac15/chrome/renderer/autofill/password_autofill_agent_browsertest.cc
[modify] https://crrev.com/c43a88e2214e3173568cac5256b57d0f7d22ac15/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/c43a88e2214e3173568cac5256b57d0f7d22ac15/components/autofill/content/renderer/password_autofill_agent.h

Labels: -Pri-3 Pri-1
Owner: dvadym@chromium.org
Status: Assigned (was: Available)
Project Member

Comment 16 by bugdroid1@chromium.org, Jan 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3d4d84928567f74d93d951932eafa1b3d779923b

commit 3d4d84928567f74d93d951932eafa1b3d779923b
Author: Vadym Doroshenko <dvadym@chromium.org>
Date: Thu Jan 11 11:00:09 2018

Reland "Do not reveal username value till user gesture."

Original change's description:
> Passwords are not available for a page till user gesture.
> But for usernames it was not implemented. This patch implements
> this: use SetSuggestedValue for username and register
> username_element to gatekeeper, which manages revealing
> the input suggested value to JS after user action.
>
> Along the way, a small improvement was implemented, setting
> the username value only in one place which simplifies the code.

> Bug: 798492
> Change-Id: Ib37637dd861f44b94674c6d0060ebc91dfd73cff
> Reviewed-on: https://chromium-review.googlesource.com/850394
> Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
> Reviewed-by: Dominic Battré <battre@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#527598}

Original Patch is PatchSet 1.
Flakiness was fixed on CL https://chromium-review.googlesource.com/c/chromium/src/+/859960
This CL differs from original only in small compilation fix in PatchSet 5 (compilation
errors were because of changes in another CL).

TBR=battre@chromium.org

Bug: 798492
Change-Id: Ife2f67ca2cd75372ef388d077acb9d53b47be92d
Reviewed-on: https://chromium-review.googlesource.com/854173
Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528593}
[modify] https://crrev.com/3d4d84928567f74d93d951932eafa1b3d779923b/chrome/browser/password_manager/credential_manager_browsertest.cc
[modify] https://crrev.com/3d4d84928567f74d93d951932eafa1b3d779923b/chrome/browser/password_manager/password_manager_browsertest.cc
[modify] https://crrev.com/3d4d84928567f74d93d951932eafa1b3d779923b/chrome/renderer/autofill/password_autofill_agent_browsertest.cc
[modify] https://crrev.com/3d4d84928567f74d93d951932eafa1b3d779923b/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/3d4d84928567f74d93d951932eafa1b3d779923b/components/autofill/content/renderer/password_autofill_agent.h

Project Member

Comment 17 by bugdroid1@chromium.org, Jan 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a9cbf22afd4ec4305334c7f953c15fc849043854

commit a9cbf22afd4ec4305334c7f953c15fc849043854
Author: Friedrich Horschig <fhorschig@chromium.org>
Date: Thu Jan 11 13:30:05 2018

Revert "Reland "Do not reveal username value till user gesture.""

This reverts commit 3d4d84928567f74d93d951932eafa1b3d779923b.

Reason for revert: ASan failed interactive_ui_tests with a PasswordManagerBrowserTestBase.UsernameChanged failure.
A connection seems likely. Could you please check that?
Build: https://uberchromegw.corp.google.com/i/chromium.memory/builders/Linux%20ASan%20Tests%20%28sandboxed%29/builds/42632

Original change's description:
> Reland "Do not reveal username value till user gesture."
> 
> Original change's description:
> > Passwords are not available for a page till user gesture.
> > But for usernames it was not implemented. This patch implements
> > this: use SetSuggestedValue for username and register
> > username_element to gatekeeper, which manages revealing
> > the input suggested value to JS after user action.
> >
> > Along the way, a small improvement was implemented, setting
> > the username value only in one place which simplifies the code.
> 
> > Bug: 798492
> > Change-Id: Ib37637dd861f44b94674c6d0060ebc91dfd73cff
> > Reviewed-on: https://chromium-review.googlesource.com/850394
> > Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
> > Reviewed-by: Dominic Battré <battre@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#527598}
> 
> Original Patch is PatchSet 1.
> Flakiness was fixed on CL https://chromium-review.googlesource.com/c/chromium/src/+/859960
> This CL differs from original only in small compilation fix in PatchSet 5 (compilation
> errors were because of changes in another CL).
> 
> TBR=battre@chromium.org
> 
> Bug: 798492
> Change-Id: Ife2f67ca2cd75372ef388d077acb9d53b47be92d
> Reviewed-on: https://chromium-review.googlesource.com/854173
> Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
> Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#528593}

TBR=dvadym@chromium.org

Change-Id: I081c713b5fe18b3d01d996eee4167000ef0bb906
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 798492
Reviewed-on: https://chromium-review.googlesource.com/860381
Reviewed-by: Friedrich Horschig <fhorschig@chromium.org>
Commit-Queue: Friedrich Horschig <fhorschig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528615}
[modify] https://crrev.com/a9cbf22afd4ec4305334c7f953c15fc849043854/chrome/browser/password_manager/credential_manager_browsertest.cc
[modify] https://crrev.com/a9cbf22afd4ec4305334c7f953c15fc849043854/chrome/browser/password_manager/password_manager_browsertest.cc
[modify] https://crrev.com/a9cbf22afd4ec4305334c7f953c15fc849043854/chrome/renderer/autofill/password_autofill_agent_browsertest.cc
[modify] https://crrev.com/a9cbf22afd4ec4305334c7f953c15fc849043854/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/a9cbf22afd4ec4305334c7f953c15fc849043854/components/autofill/content/renderer/password_autofill_agent.h

Project Member

Comment 18 by bugdroid1@chromium.org, Jan 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/33642ab33b8e98d381045b35c1af66282ef6acb4

commit 33642ab33b8e98d381045b35c1af66282ef6acb4
Author: Vadym Doroshenko <dvadym@chromium.org>
Date: Thu Jan 11 19:53:42 2018

Reland "Reland "Do not reveal username value till user gesture.""

This is a reland of 3d4d84928567f74d93d951932eafa1b3d779923b
Original change's description:
> Reland "Do not reveal username value till user gesture."
>
> Original change's description:
> > Passwords are not available for a page till user gesture.
> > But for usernames it was not implemented. This patch implements
> > this: use SetSuggestedValue for username and register
> > username_element to gatekeeper, which manages revealing
> > the input suggested value to JS after user action.
> >
> > Along the way, a small improvement was implemented, setting
> > the username value only in one place which simplifies the code.
>
> > Bug: 798492
> > Change-Id: Ib37637dd861f44b94674c6d0060ebc91dfd73cff
> > Reviewed-on: https://chromium-review.googlesource.com/850394
> > Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
> > Reviewed-by: Dominic Battré <battre@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#527598}
>
> Original Patch is PatchSet 1.
> Flakiness was fixed on CL https://chromium-review.googlesource.com/c/chromium/src/+/859960
> This CL differs from original only in small compilation fix in PatchSet 5 (compilation
> errors were because of changes in another CL).
>
> TBR=battre@chromium.org
>
> Bug: 798492
> Change-Id: Ife2f67ca2cd75372ef388d077acb9d53b47be92d
> Reviewed-on: https://chromium-review.googlesource.com/854173
> Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
> Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#528593}

Flakiness that was a reason of last revert was fixed on
https://chromium-review.googlesource.com/c/chromium/src/+/860649

TBR=battre@chromium.org

Bug: 798492
Change-Id: Ia277559ebe541da25d21f493d0ae2889c676aa9c
Reviewed-on: https://chromium-review.googlesource.com/862143
Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
Commit-Queue: Vadym Doroshenko <dvadym@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528716}
[modify] https://crrev.com/33642ab33b8e98d381045b35c1af66282ef6acb4/chrome/browser/password_manager/credential_manager_browsertest.cc
[modify] https://crrev.com/33642ab33b8e98d381045b35c1af66282ef6acb4/chrome/browser/password_manager/password_manager_browsertest.cc
[modify] https://crrev.com/33642ab33b8e98d381045b35c1af66282ef6acb4/chrome/renderer/autofill/password_autofill_agent_browsertest.cc
[modify] https://crrev.com/33642ab33b8e98d381045b35c1af66282ef6acb4/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/33642ab33b8e98d381045b35c1af66282ef6acb4/components/autofill/content/renderer/password_autofill_agent.h

Labels: -Pri-1 Pri-3
Owner: ----
Status: Available (was: Assigned)
After landing mitigation CL in #18 Chrome doesn't reveal username till user gesture in content area (mouse click, kestroke etc).
Cc: sc00335...@techmahindra.com
 Issue 801901  has been merged into this issue.

Comment 21 by stu...@anchev.net, Jan 17 2018

Considering it is possible to capture the values in fields after whatever action (mouse click or other) and even to create a JavaScript key-logger which would steal the credentials even without having saved passwords it seems to me there is a only one safe way:

Make Chromium NOT load 3rd party scripts on pages with login forms and display a warning if any such page tries to do it.

This will also make web developers more careful when they design the pages and will have positive effect on the web as a whole.

Comment 22 by yn...@vivaldi.com, Jan 17 2018

That might be a more reliable solution.

However, the present issue is "just" a part of a larger issue, the fact that third-party scripts are used to record the user's entire session and exfiltrate their data.

https://freedom-to-tinker.com/2017/11/15/no-boundaries-exfiltration-of-personal-data-by-session-replay-scripts/

https://freedom-to-tinker.com/2018/01/12/website-operators-are-in-the-dark-about-privacy-violations-by-third-party-scripts/

This issue is much broader (and should be handled as a separate issue), and the easiest to implement solution would be to ban all third-party scripts, or, the more complicated one, block their access to mouse/keyboard events and form fields.

The obvious workaround in both cases, though, is to host the exfiltration script on the first-party site, and still send the data to a third-party site.

Comment 23 by stu...@anchev.net, Jan 17 2018

Well, considering Spectre and Meltdown - the issue with JavaScript is actually even much broader. Personally I have disabled JS completely but the average layman has no idea about any of this.

Some radical changes obviously need to be made. All JS programs are practically installed without the user realizing that.

(Just thinking)

Comment 24 by yn...@vivaldi.com, Jan 17 2018

Continuing thinking, one possibility: Only grant a very limited set of permissions to all (including first party) external Javascripts, e.g. e.g they can create their own content in a specified frame, no access to the rest of the document; if the script needs more permissions it must be granted by the embedding site (asking the user is problematic, just look at app installation).

While the natural place to put such a permission grant is in the Javascript embedding tag, that would allow copy/paste of the tag with permissions without the author necessarily realizing what has been granted (I suspect most third-party scripts are embedded following "Paste this code in your page/template file" instructions). I think such a permission list should be put somewhere else, and referenced by a name that is unique to the site (e.g. required to contain the site host name; still possible to work around that, but it requires author cooperation).
Cc: msramek@chromium.org awhalley@chromium.org est...@chromium.org palmer@chromium.org
Labels: -Pri-3 Team-Security-UX OS-Fuchsia Pri-1
In my view, there are 2 problems:

1. Any ol' gesture in the content area is not a sufficient indicator of the person's intent to fill the form. In fact it's quite easy for web contents to induce and receive a gesture sufficient to cause a form fill.

Instead, I think we need to gate filling on a gesture in browser chrome, not in web contents.

2. Spectre is indeed a concern. We need to start considering a threat model that gives even less trust to renderer processes than we give them now. awhalley and I have a Q1 TODO to articulate a new, tighter threat model.

Per #22, I don't think turning off JS, or 3rd-party JS, is a complete solution, and in any case has severe web compatibility problems (obviously).

estark, msramek (others?): Who is a good person to pick this bug up? I think it should be Pri-1.
Cc: ainslie@chromium.org
+ainslie, who has a good plan.
Components: UI>Browser>Autofill
Cc: durgapandey@chromium.org zkoch@chromium.org
+zkoch and durga: I think this needs an owner, both PM and eng, from the autofill team.

What is ainslie's good plan?
Err sorry this needs an owner from the pwd manager team, not autofill.
What is "the bug"? So far it is unclear to me what could or should be done. I don't think that we have any satisfying answer that prevents scripts in a first-party-context from exfiltrating passwords. Fill-on-account-select is not a strong mitigation against this.

I wonder whether this particular bug should be closed as not-fixable. On the Spectre topic, we have other bugs discussing that.
> Fill-on-account-select is not a strong mitigation against this.

This is, arguably, the bug. One approach to fixing it is as described in #25, namely offer a mode of the password manager wherein password filling is mediated by UI interactions within the browser Chrome above the line-of-death.

Whether such a mode should be default or not will doubtless be subject of vigorous debate.
Re #30: from my perspective the bug is not that scripts in a first-party context can exfiltrate passwords, but that they can do so without the user having any intention of giving their username/password to the first party at all.

Re #31:

> within the browser Chrome above the line-of-death

Is it necessary to go that far? ISTM that FOAS would be enough, as long as FOAS is triggered by a UI that is drawn in the browser process and the gesture is received there.
How would fill-on-account-select help? Users do login to websites using passwords. Everytime this happens is an opportunity for a third-party script that runs in a first party-context to steal the password.
But users also sometimes don't log in to websites, and we don't need to leak their identity if they don't want to be identified to the website.

Comment 35 by yn...@vivaldi.com, Jan 17 2018

battre: The main issue in this report is that a third-party javascript can automatically extract and exfiltrate username and password without the knowledge or co-operation of either the website itself, or the user, because the username/password get filled in automatically when the form elements are generated. (I think it can be argued that even first-parties can do this and that is a problem, too, but third-parties are the more severe issue).

As far as I can tell there are just a few options for a fix:

* Delay filling until the user actively start a form operation. Considering the possibility of hidden fields, I think only visible fields should be filled, preferably only in the currently visible part of the document. This needs to avoid accepting synthesized events as indications of what the user is doing.

* Block access to username/password fields. This is less likely to lead to inadvertent access, but might cause some web site issues. I know there can be some sites that "require" access for their processing and form submit operations (have encountered at least one such in the past), but IMO they might do all that server side.

* Restrict third-party script capabilities and access, possibly allowing specific scripts wider access specifically from the containing document. This is, indeed, likely to break web functionality, but might improve security in general (especially for the the wider session-replay problem described in the referenced articles)

Either of the two first can probably be implemented quickly, especially the second one. IMO not fixing or mitigating the issue is not an option.

The wider exfiltration/session-play problem is a larger problem that should be handled in a separate issue, and probably require option #3, and that require standards action before it can be deployed.

Comment 36 by zkoch@chromium.org, Jan 17 2018

> But users also sometimes don't log in to websites, and we don't need to leak their identity if they don't want to be identified to the website.

But they created an account on this site, so their identity is already shared. So I'm a bit confused as to how much we're actually helping here.

I'm also skeptical of FOAS and share Dominic's concern that it doesn't really help much.

I'm also not wild about enabling FOAS with our current UI (we have 0 affordance that indicates we do have your username). But we have some design explorations in Q1 to make this more obvious. We could pair those with enabling FOAS by default, but I don't think we're there yet.

Comment 37 by yn...@vivaldi.com, Jan 17 2018

zkock: Yes, they created an account on the site. However, they did not agree to share their ID with a malicious third-party site.

From the linked article at the top:

>  First, a user fills out a login form on the page and asks the browser to save the login. The tracking script is not present on the login page [1]. Then, the user visits another page on the same website which includes the third-party tracking script. The tracking script inserts an invisible login form, which is automatically filled in by the browser’s login manager. The third-party script retrieves the user’s email address by reading the populated form and sends the email hashes to third-party servers.

I don't know, but it would not surprise me to find that some advertisers allow injection of these invisible forms. And that is before we consider hacked third-party sites.

Comment 38 by stu...@anchev.net, Jan 17 2018

Thinking further:

Perhaps instead of blocking 3rd party scripts totally (which may break the UI of the page) it may be possible to block 3rd party scripts from being able to do things like XHR, set/read cookies and anything else that can result in creating a "state" which can be transmitted - either while on the page or after navigating to another one, with or without having logged in.

Of course this still has the possibility of breaking things (e.g. loading images through XHR) but it may be less compared to totally blocking 3rd party JS.

Still this is a very superficial security measure in an age of flawed hardware.

Comment 39 by yn...@vivaldi.com, Jan 17 2018

An aspect of this that also needs to be considered, not just in relation to the password issue, but the more fundamental exfiltration issue and what third-party scripts have access to, is a legal one; In Europe the GDPR directive for protection of personal information goes into effect May 2018 (in about 3 months).

This directive require site owners to document and justify all data collection and processing, both their own and associated third-party collectors and processors. Punishments for failure to properly protect data are significant, millions of Euros or 4% of *global* revenue. This directive applies to anyone having operations in Europe (that is, having European users), also non-European companies.

Not being able to control what third-parties can do, for example via javascript embedded in their site, could expose site operators to significant legal liability.

Comment 40 by stu...@anchev.net, Jan 17 2018

> Punishments for failure to properly protect data are significant, millions of Euros or 4% of *global* revenue.

There can't be proper protection of data when the essential mechanism ensuring security in current computer technology (i.e. isolation) is broken and vulnerable at hardware level. Consider also all the issues with Intel ME, proprietary BIOS, mass surveillance, Vault 7 and 8 - all levels which neither the site owner controls, nor the web hosting providers. This is impossible to enforce. It is like enforcing anti-gravity.

Comment 41 by yn...@vivaldi.com, Jan 18 2018

I did say "properly". While I am not a lawyer, I doubt that using hardware with an issue like Meltdown/spectre would be considered a major liability, provided the OS and firmware was properly patched.

However, if your site includes third-party code on the site, with full access to all content, that can perform collection and processing of personal information that has not been documented  (and which you did not know about), or declared and enumerated to the user (that is also a requirement in the directive), then you might be on the hook. So the only way, currently, to protect yourself is to not use such third-party code (which, in a way, is preferable from a user security perspective). If you absolutely "have to" use such scripts then being able to, by default, limit access for such scripts would  definitely be a help liability-wise. Unfortunately, such access control is not currently possible.

Comment 42 by yn...@vivaldi.com, Jan 18 2018

BTW, just to look at the wider perspective (since it have been raised), the possibility or certainty that there are other severe vulnerabilities in the *external* environment (over which the application does not have any control) does not mean that one should ignore vulnerabilities and issues in the internal environment over which the application vendor(s) do have controls. Vendors close the holes that they can close, and implement mitigation techniques against other possible problems (e.g. use encryption over an unsecured network, encrypt sensitive data in persistent storage, or encrypt data in the memory to reduce plain text leaks via disks due to swapping).

Major environment issues like Meltdown are entirely out of scope for the current issue and the more fundamental problem it is part of (which is also mostly out of scope of this issue report), which can be exploited much more easily and reliably by an attacker with the right kind of access. The legal issue I mentioned might be used to decide which mitigation techniques are worthwhile to explore.

Comment 43 by stu...@anchev.net, Jan 18 2018

> I did say "properly".

You did but we can never know if firmware is patched properly as long as it is not libreboot. In fact - that "proper" patching may result in additional infection for surveillance purposes. Taking the user to court for this would be severe injustice.

> So the only way, currently, to protect yourself is to not use such third-party code

uBlock Origin and uMatrix help a great deal. Still - all we are talking about is like painting a wall with a huge hole in it.

Sorry for the off-topic. Let's leave developers do their work. They are aware of all these things.
Cc: ma...@chromium.org
Labels: -Pri-1 Pri-2
Lowering priority a bit, as we've landed one mitigation in #18 and I'm not aware of any plans to do more work here in the near future.
A major improvement might be to move account / session management from the webpage (HTML/JS) to the browser (and HTTP) and to standardize it. It could improve both usability and security. Think HTTP auth on steroids.

- User-controlled auto-sign-in / sign-out.
- Integration with email providers to skip the "Click this link to activate your account" dances.
- No need for users to deal with passwords.
I think this is also a problem in 1st party context (as was briefly mentioned in comment #35):
1. Create an account at example.com, store the password in pwd manager
2. Sign out of example.com
3. Clear cookies
4. Return to example.com for signed-out browsing

Afaiu, in the absence of FOAS, example.com may obtain the username of the user which at that point is totally unexpected. In other words, the password manager can be abused to restore a deleted cookie which seems like a significant problem to my mind.
Re comment #47:
If you clear your cookies in step 3, PasswordStoreDefault::DisableAutoSignInForOriginsImpl() disables auto-sign in until you have picked your credential the next time.
That seems like a good concept, but it doesn't repro for me:
1. Clear cookies
2. Visit Amazon sign-in page
3. Do not click into any of the form fields
4. JS console> document.getElementById("ap_email").value
--> "[redacted]@gmail.com"

Sign in to add a comment