Privacy: Zombie-cookies can't be deleted through the "Cookies and site data" UI
Reported by
jgill...@gmail.com,
Apr 7 2016
|
||||||||||||||||||||||
Issue descriptionPRIVACY ISSUE Some non-session cookies appear to turn into zombie-cookies, through an unknown mechanism. These cookies do not appear in the "Cookies and site data" UI. Additionally, clicking "Remove all" in that dialog does not delete them. Chromium continues to send them in request headers, even though the user cannot see that they exist without manually examining the Cookies sqlite database (or examining the headers Chromium sends). VERSION: Chrome Version: 49.0.2623.108 + stable Operating System: Built on Ubuntu 14.04, running on LinuxMint 17 (64-bit) REPRODUCTION STEPS 1. Create a fresh user-data directory, and start Chromium pointing at that directory (using --user-data-dir) 2. Navigate to https://www.eff.org/files/Changelog.txt (and note that this page does not set cookies) 3. Open up the developer tools, and set a cookie via Javascript via the console (say document.cookie="COOKIE=1; expires=Sat, 31 Dec 2016 12:00:00 UTC") 4. Navigate to chrome://settings/search#cookie and click on "Content Settings", then "All cookies and site data" 5. Verify the cookie has been set, then close the browser 6. Start Chromium again, again pointing to the same user-data directory (using --user-data-dir) 7. Navigate to chrome://settings/search#cookie and click on "Content Settings", then "All cookies and site data" 8. Verify the cookie for www.eff.org is not listed, even though it hasn't expired and was not a session cookie. 9. In that same tab, open up developer tools, and choose "Network" 10. In that same tab, navigate to https://www.eff.org/files/Changelog.txt and examine the request headers sent by Chromium 11. The cookie appears to be sent, even though it was not listed in the UI. (If it is not sent, try refreshing the page. There appears to be some sort of non-determinancy where sometimes the cookie is sent, and sometimes it isn't.) 12. Go back to chrome://settings/search#cookie and click on "Content Settings", then "All cookies and site data" 13. Click "Remove all" 14. If you navigate once again to https://www.eff.org/files/Changelog.txt you will see the cookie is still being sent 15. Close the browser 16. Examine the cookies table contained in the sqlite database user_data_dir/Default/Cookies 17. You will see that the cookie is still in the database, even though we supposedly removed all cookies ADDITIONAL NOTES * Not all cookies turn into zombie-cookies, for some reason. * This is not specific to cookies set via javascript. Cookies set via reply headers also sometimes demonstrate this behavior. * These zombie-cookies *do* disappear from the Cookies DB and are no longer sent when they expire * These zombie-cookies *are* successfully deleted by instead using the "Clear browsing data" UI path, which makes me think this bug has something to do with Issue 136498 The attached file is a tar/gzipped example of a user data dir which has such a zombie cookie.
,
Apr 8 2016
The exact reproduction steps only work until M50. In M51, I was able to reproduce the problem using chrome://net-internals and capturing the byte stream.
,
Apr 8 2016
https://codereview.chromium.org/1870973002/ is in code review.
,
Apr 12 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8e4a0b36ac3989db1afb69dff442fdc85af047da commit 8e4a0b36ac3989db1afb69dff442fdc85af047da Author: battre <battre@chromium.org> Date: Tue Apr 12 15:49:42 2016 Unhide "Zombie-cookies". Some cookies would not show up in chrome://settings/cookies or the site info dialog because the source_ in the CanonicalCookie is not persisted beyond browser restarts. https://crrev.com/a6acbbcaccdb4085f17d0eef1f266d48fa4baff0 created a filter to allow only access to HTTP or HTTPS cookies. This CL moves the filtering logic a few lines behind a fall back path. R=msramek@chromium.org,palmer@chromium.org,markusheintz@chromium.org BUG= 573317 , 601582 Review URL: https://codereview.chromium.org/1870973002 Cr-Commit-Position: refs/heads/master@{#386695} [modify] https://crrev.com/8e4a0b36ac3989db1afb69dff442fdc85af047da/chrome/browser/browsing_data/cookies_tree_model.cc [modify] https://crrev.com/8e4a0b36ac3989db1afb69dff442fdc85af047da/chrome/browser/browsing_data/cookies_tree_model_unittest.cc
,
Apr 15 2016
,
Apr 15 2016
Your change meets the bar and is auto-approved for M51 (branch: 2704)
,
Apr 15 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/44959317e61b85de3c25fdb066cbd8481871f637 commit 44959317e61b85de3c25fdb066cbd8481871f637 Author: Dominic Battre <battre@chromium.org> Date: Fri Apr 15 07:32:20 2016 Unhide "Zombie-cookies". Some cookies would not show up in chrome://settings/cookies or the site info dialog because the source_ in the CanonicalCookie is not persisted beyond browser restarts. https://crrev.com/a6acbbcaccdb4085f17d0eef1f266d48fa4baff0 created a filter to allow only access to HTTP or HTTPS cookies. This CL moves the filtering logic a few lines behind a fall back path. R=msramek@chromium.org,palmer@chromium.org,markusheintz@chromium.org BUG= 573317 , 601582 Review URL: https://codereview.chromium.org/1870973002 Cr-Commit-Position: refs/heads/master@{#386695} (cherry picked from commit 8e4a0b36ac3989db1afb69dff442fdc85af047da) Review URL: https://codereview.chromium.org/1891153002 . Cr-Commit-Position: refs/branch-heads/2704@{#69} Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251} [modify] https://crrev.com/44959317e61b85de3c25fdb066cbd8481871f637/chrome/browser/browsing_data/cookies_tree_model.cc [modify] https://crrev.com/44959317e61b85de3c25fdb066cbd8481871f637/chrome/browser/browsing_data/cookies_tree_model_unittest.cc
,
Apr 15 2016
Thanks for the report!
,
Apr 20 2016
Issue 589199 has been merged into this issue.
,
Apr 21 2016
Props also to Jered Wierzbicki, with whom we spotted this and confirmed it was real. And thanks to Jeremy for doing an amazing job of pinning down & writing up robust reproduction steps!
,
Apr 21 2016
Yes, I totally agree! Having the reproduction steps was incredibly helpful. Thank you!
,
Apr 21 2016
,
Apr 21 2016
[Automated comment] Request affecting a post-stable build (M50), manual review required.
,
Apr 21 2016
50 is already rolling, so this likely won't make it out there in some cases. I'll let a desktop TPM decide on merges, but for Android this has missed the cut.
,
Apr 21 2016
Looks like OS Linux based on the report, please make sure to tag your bugs, especially blockers / merges as that's how the TPMs sort things out...
,
Apr 21 2016
I've seen this happen on Mac and ChromeOS as well. (with the Mac version reported being fixed now)
,
Apr 21 2016
,
Apr 22 2016
Before we approve merge to M50, Could you please confirm whether this bug is baked/verified in Canary and safe to merge?
,
Apr 25 2016
I have observed and heard from several people that this is working on Canary.
,
May 6 2016
Approving merge to M50 branch 2661, based on comment #19. Please merge before 1:00 PM PST on Monday (05/09) so we can take it for next week stable refresh.
,
May 6 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b7c0ea69b403ef18e1381c3c78b5a9aea336aa70 commit b7c0ea69b403ef18e1381c3c78b5a9aea336aa70 Author: Dominic Battre <battre@chromium.org> Date: Fri May 06 19:26:55 2016 Unhide "Zombie-cookies". Some cookies would not show up in chrome://settings/cookies or the site info dialog because the source_ in the CanonicalCookie is not persisted beyond browser restarts. https://crrev.com/a6acbbcaccdb4085f17d0eef1f266d48fa4baff0 created a filter to allow only access to HTTP or HTTPS cookies. This CL moves the filtering logic a few lines behind a fall back path. R=msramek@chromium.org,palmer@chromium.org,markusheintz@chromium.org BUG= 573317 , 601582 Review URL: https://codereview.chromium.org/1870973002 Cr-Commit-Position: refs/heads/master@{#386695} (cherry picked from commit 8e4a0b36ac3989db1afb69dff442fdc85af047da) Review URL: https://codereview.chromium.org/1947933006 . Cr-Commit-Position: refs/branch-heads/2661@{#664} Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081} [modify] https://crrev.com/b7c0ea69b403ef18e1381c3c78b5a9aea336aa70/chrome/browser/browsing_data/cookies_tree_model.cc [modify] https://crrev.com/b7c0ea69b403ef18e1381c3c78b5a9aea336aa70/chrome/browser/browsing_data/cookies_tree_model_unittest.cc
,
May 11 2016
Tested the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.4 using chrome version 50.0.2661.102 with the below steps 1.start chrome using --user-data-dir 2.Navigate to https://www.eff.org/files/Changelog.txt 3.Open dev tools console and set cookie with (document.cookie="COOKIE=1; expires=Sat, 31 Dec 2016 12:00:00 UTC")) 4.Navigate to chrome://settings/search#cookie and click on "Content Settings", then "All cookies and site data" 5.Observed that the cookie is present for www.eff.org.closed the browser 6.Again start chrome using --user-data-dir 7.Navigate to chrome://settings/search#cookie and click on "Content Settings", then "All cookies and site data" 8.Verified the cookie www.eff.org is still present under "All cookies and site data" 9.clicked on Remove All 10.Navigated to "https://www.eff.org/files/Changelog.txt" 11.Verified Observed the cookie www.eff.org is not listed under "All cookies and site data". Please find the attached screen cast for the same.Adding TE-Verified label. Thanks,
|
||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||
Comment 1 by battre@chromium.org
, Apr 8 2016Labels: -Pri-3 M-51 Pri-1
Status: Available (was: Untriaged)