PasswordStore::GetLogins [1] and related places have a sizeable chunk of code to filter out credentials stored for http*://www.google.com. These credentials have been filtered out for years now, but not deleted to give the users chance to transfer them to accounts.google.com. It is time to delete those credentials and simplify Chrome's code. The proposal is 3-step:
(1) Add UMA to measure how much http*://www.google.com credentials people have stored.
(2) Add code to delete http*://www.google.com. This should be a one-off action, likely during the start of PasswordStore.
(3) Once the metrics from step (1) drop under 0.0001% users having some http*://www.google.com passwords stored, remove both the masking and the deleting code.
[1] https://cs.chromium.org/chromium/src/components/password_manager/core/browser/password_store.cc?rcl=0&l=180-202
PasswordStore::GetLogins [1] and related places have a sizeable chunk of code to filter out credentials stored for http*://www.google.com. These credentials have been filtered out for years now, but not deleted to give the users chance to transfer them to accounts.google.com. It is time to delete those credentials and simplify Chrome's code. The proposal is 3-step:
(1) Add UMA to measure how many users are there with credentials on http*://www.google.com whose credentials match an account of theirs on https://accounts.google.com.
(2) Share the results with Chrome Security and our product manager. Consult whether it makes sense to start deleting the www.google.com passwords, potentially escalate to product leads if needed. Settle on an upper bound X for the metric of (1) which will allow us to make the code unaware of www.googl.com credentials in step (4).
(3) If approved, add code to delete credentials for http*://www.google.com. This should be a one-off action, likely during the start of PasswordStore.
(4) Once the metrics from step (1) drop under X, remove both the masking and the deleting code.
[1] https://cs.chromium.org/chromium/src/components/password_manager/core/browser/password_store.cc?rcl=0&l=180-202
PasswordStore::GetLogins [1] and related places have a sizeable chunk of code to filter out credentials stored for http*://www.google.com. These credentials have been filtered out for years now, but not deleted to give the users chance to transfer them to accounts.google.com. It is time to delete those credentials and simplify Chrome's code. The proposal is 3-step:
(1) Add UMA to measure how many users are there with credentials on http*://www.google.com whose credentials match an account of theirs on https://accounts.google.com.
(2) Once the metric from (1) comes from stable, share the results with Chrome Security and our product manager. Consult whether it makes sense to start deleting the www.google.com passwords, potentially escalate to product leads if needed. Settle on an upper bound X for the metric of (1) which will allow us to make the code unaware of www.googl.com credentials in step (4).
(3) If approved, add code to delete credentials for http*://www.google.com. This should be a one-off action, likely during the start of PasswordStore.
(4) Once the metrics from step (1) drop under X, remove both the masking and the deleting code.
[1] https://cs.chromium.org/chromium/src/components/password_manager/core/browser/password_store.cc?rcl=0&l=180-202
Hi jww@!
I need an advice from you:
Does the proposal in this bug sound like a good idea security-wise?
Once you answer the above question, please assign back to me (comments like, e.g., requests to tweak the threshold in (3) are welcome).
Thanks!
Vaclav
This sounds like a great idea to me. I guess the only question is if the number is #3 is low enough? It sounds reasonable, but it does open users to an attack if they still hold those credentials. I think we should get sign off from higher-ups before doing it because of this.
Could we measure something slightly more specific, perhaps? Perhaps "users with credentials on http*://www.google.com whose credentials match an account of theirs on https://accounts.google.com? That might be a better metric for deciding whet it's "low enough."
Thanks!
I will fix the description to include your proposal for metrics in (1) and to explicitly mention discussing the metrics with Chrome security and the product leads before doing any changes.
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.
Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.
Sorry for the inconvenience if the bug really should have been left as Available.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Comment 1 by vabr@chromium.org
, Sep 9 2016Owner: jww@chromium.org
Status: Assigned (was: Available)