Thanks for filing the issue, able to reproduce the issue on Windows 10, Mac 10.12.6, Ubuntu 14.04 using chrome version 61.0.3163.100. issue is a non regression as observed from M55 Builds. "Clear cookies on Exit option available from M55 Builds (55.0.2841.0) under chrome://md-settings

Untriaged it so that issue gets addressed.

Thanks.!

You are welcome.

msramek: does someone from privacy want to investigate?

+cookies component which is probably the most relevant. Hopefully some cookies people will take this on.

I don't think the network stack team has ever been the maintainer this code, actually.  It's in content/browser/net/quota_policy_cookie_store.h, now, I believe, which we own, but no idea which team it came from - looks like a combination of initial.commit, darin, erikwright, and guohui, with rohitrao (iOS team) being responsible for the round of refactoring that resulted in its current form, back in 2015.

That having been said, we are probably going to have to significantly refactor it for the whole network service thing.

Also, have you tried using https://[*.]pinterest.com:443 instead?  Looks like they set at least some cookies on their top level domain.

Thanks for the info. Assigning this bug to you to get it out of the site settings triage queue. If you need some help from someone at the UI end let us know.

If it shouldn't assigned to you feel free to remove yourself and put it back as Untriaged and we'll find another owner.

As a practical matter, I've never worked on QuotaPolicyCookie store, and the network team has never owned per-site settings (Either configuration or enforcement), so it's unlikely I'll get to this.  I'm not even sure why we support this sort of configuration.

Punting this back into the triage queue, per request.  Also, I was wrong about this being in QuotaPolicyCookieStore - that only does clear cookies on quit.  This looks to be in components/content_settings/core/browser/cookie_settings.h, which isn't code the network stack team owns.

Re #7 - no, I haven't done any extensive testing. I just noticed and reported.

This has been fixed in  https://crbug.com/784312 

Doesn't look fixed

chromium-63.0.3239.84-127.1.x86_64

The fix is currently in Canary and Dev channels (>= 64.0.3276.0)
Chrome 64 will be stable in about 6 weeks.

Still an issue in chromium-64.0.3282.119-135.1.x86_64

In fact it seems worse after updating to v.64.

Now after each restart I have to type again my Gmail password although I haven't changed any settings.

I am using the HTML version of Gmail with JS fully disabled. Cookies are enabled for:

https://accounts.google.com:443
https://mail.google.com:443
https://myaccount.google.com:443

Before updating (when I used v.63) I didn't have to re-login on each browser restart.

Same issue with other sites. Example:

https://mbasic.facebook.com/ (again with JS fully disabled and cookies enabled for https://mbasic.facebook.com:443 as it has always been till now) now asks me to login after each browser restart. This has never happened in v.63

To clarify: both for gmail and for facebook the cookies are allowed in "Allow", not in "Clear on exit", i.e. expected to survive restart.

Correction:

It seems that the upgrade to v.64 causes some discrepancies with extension uMatrix which has a setting to auto delete cookies every N minutes (60 in my case) and instead uMatrix deletes them on every restart now:

https://github.com/gorhill/uMatrix/issues/932

If I disable this setting logins survive restarts.

However the main issue of this bug remains: cookies in "Clear on exit" list are not deleted.

(Sorry for the fragmented messages)

Chrome 64 currently has a bug that deletes Cookies on some devices on restart. 
As far as we know, the bug is unrelated to this change and a fix is currently being tested. Chrome will get an update soon. You can follow  issue 795827  for more information.

That explains it. Thanks!

Still an issue in chromium-64.0.3282.167-141.1.x86_64

I think I can reproduce it now:

uMatrix is adding a "Clear on Exit rule". Having any Clear on Exit rules causes the cleanup on exit to also remove cookies for blocked origins. 
You can currently stop the cookies from getting deleted by explicitly allowing "https://google.com". 
The issue is that at shutdown we don't know anymore that the cookie for google.com was created by accounts.google.com. I will look at the issue and try to find a better solution.

I always have all cookies blocked by default (as per step 1 in the OP) so any cookies that I have allowed are in the explicit whitelist. Regardless of that I am currently having more problems with  Issue 795827  which deletes cookies which it should not. It is a real mess and hard to test anything.

Still an issue.

[~]: rpm -q chromium 
chromium-65.0.3325.162-146.1.x86_64

To check if I understand the issue correctly, your settings are:

Block everything

Clear on Exit:
 [some domain]

Allow:
 https://accounts.google.com:443
 https://mail.google.com:443
 https://myaccount.google.com:443

You are getting logged out of google on restart?
Could you try to add a content setting
 Allow: google.com
If you don't want to be logged in while searching, you can add
 Block: www.google.com

Does this configuration keep you logged in after restart?

My chrome://settings/content/cookies settings currently are:

Block everything
Block third-party cookies

Block:
(no sites added)

Clear on exit:
https://mobile.twitter.com:443

Allow:
https://accounts.google.com:443
https://calendar.google.com:443
https://mail.google.com:443
... + some other, non-google sites


In chrome://settings/siteData I see:

accounts.google.com
4 cookies

google.com
Channel ID, 7 cookies

mail.google.com
4 cookies

I also have 2SV for my Google account.
When I restart chromium and try to navigate to https://mail.google.com I am being asked to enter my password (my username is remembered) and I am not asked to enter a 2SV code.

I don't use Google search. I use DuckDuckGo. But I will test your suggestion after submitting this comment and add another comment just to let you know.

I have set:

Allow: google.com
Block: www.google.com

and restarted.

Navigated to https://mail.google.com and I am still logged in.

Navigated to https://mobile.twitter.com/google (without logging in to Twitter) and in chrome://settings/siteData I see

twitter.com
8 cookies

Restart. And I am still logged in Gmail (as expected) and the twitter cookies are gone (as expected).

Still https://mbasic.facebook.com asks me for login and 2SV each time I restart even though I have:

Allow:
https://mbasic.facebook.com:443 (this is the version of the site which I use as it works without JS)

----
Question:

1. Why allowing google.com resulted in no longer being asked for Google password after restart, considering that in chrome://settings/siteData the same cookie show up (as before allowing it)?

2. Why FB forgets my login?

3. Why do I have:

google.com
Channel ID, 7 cookies

even before having allowed google.com? Is it because I am logged in my account in chromium itself? (which would mean that google.com cookies can never really be blocked, which would conflict the logic of question 1)

4. Why clicking on the "cookie" icon after having logged in FB shows:

Allowed:
facebook.com
mbasic.facebook.com

considering that in settings I have not allowed facebook.com but only mbasic.facebook.com?

More info similar to 4:

After having 'Allow: google.com' visiting https://mail.google.com and clicking the cookie icon shows google.com both in Allowed and Blocked tab.

'Allow: facebook.com' keeps me logged in on https://mbasic.facebook.com/ after restarting.

Sorry for the fragmented messages.

I hope you can shed some light on this matter as it is really confusing.

Cookies can be set on parent domains - i.e., mail.google.com can set cookies on google.com.  So if it does so for login cookies (Like to share login information with other Google services, like docs.google.com, etc), you need to keep those cookies on shutdown or else you'll be logged out.

That clarifies. Thanks.

But doesn't that really mean that it is futile to allow cookies for sub-domains only and that one should always allow cookies for the root domain (and selectively blacklist subdomains if necessary)?

Also could you comment about question 3 please?

Thanks for testing this. The issue is that we changed the behavior of cookies on blocked domains if there is a clear on exit setting.

There was a problem (the one reported in this bug) that if you block everything and set a few sites to ClearOnExit, some cookies would survive restart if they belong to a parent domain that is blocked.

But if you combine:
1. Block everything
2. Clear On Exit for some domain
3. Allow a subdomain that sets cookies on a parent domain 

You will get logged out of the subdomain.

Maybe that can be improved, some ideas:
 - Don't delete cookies for blocked domains if any subdomain is allowed. (does this cover all cases correctly?)
 - When storing a cookie, set a flag whether the cookie should be cleared on exit.
 - When storing a cookie, store the origin that created the cookie and do the cleanup based on this origin.

The last suggestion sounds most appropriate. Otherwise one is enforced to allow all cookies for the root domain and hence for the all subdomains including those which one may not even know about which can result in privacy issues. Example:

One may want to check Gmail but may not want to necessarily associate his www.google.com or anyotherservice.google.com activity with the fact that he is simply checking his email.

How would you solve this?

Another issue:

I have a site installed on a local web server which is accessed through:

https://mysite.mytld:myport

If I have:

Allow: https://mysite.mytld:myport

it logs me out on each restart (the site does not use any 3rd party or subdomain cookies)

The workaround (similar to above) is to:

Allow: mysite.mytld

I wonder how this relates to all this, to secure cookies etc.

I think we found a good solution to correctly delete or keep cookies when cookies are stored on parent domains, origins with non-default port or non-secure cookies on secure sites. 
Here is the CL: https://crrev.com/c/975861

To correctly determine the content setting that applies to a cookie, we have to use domain matching (https://tools.ietf.org/html/rfc6265#section-5.1.3). 
This way we can determine which content setting could have influenced the cookie when it was created.

I am glad. Unfortunately I can't read the first link because it seems to require enabling JS which I am deliberately avoiding after the announcement of Spectre and Meltdown.

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

commit e1e1772f872b781549b6f471b568186cb53bf0d9
Author: Christian Dullweber <dullweber@chromium.org>
Date: Fri Apr 06 16:04:39 2018

Improve ClearOnExit behavior of cookies using domain matching

Use the domain matching algorithm to determine which content setting
rule could have influenced the creation of a cookie to correctly decide
whether it should be deleted on exit.
This fixes cases where cookies are visible to subdomains or
domains with non-default ports and directly looking up the origin of a
cookie in HostContentSettingsMap doesn't return the right result.

Bug:  775080 
Change-Id: If460537cf7a3de0a4a483d58ac1504637d9612be
Reviewed-on: https://chromium-review.googlesource.com/975861
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548793}
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/chrome/browser/extensions/extension_special_storage_policy.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/chrome/browser/extensions/extension_special_storage_policy.h
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/chrome/browser/extensions/mock_extension_special_storage_policy.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/chrome/browser/extensions/mock_extension_special_storage_policy.h
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/chrome/browser/sessions/session_data_deleter.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/components/content_settings/core/browser/cookie_settings.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/components/content_settings/core/browser/cookie_settings.h
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/components/content_settings/core/browser/cookie_settings_unittest.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/content/browser/net/quota_policy_cookie_store.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/extensions/shell/browser/shell_special_storage_policy.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/extensions/shell/browser/shell_special_storage_policy.h
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/net/cookies/canonical_cookie.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/net/cookies/cookie_util.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/net/cookies/cookie_util.h
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/net/cookies/cookie_util_unittest.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/storage/browser/quota/special_storage_policy.h
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/storage/browser/test/mock_special_storage_policy.cc
[modify] https://crrev.com/e1e1772f872b781549b6f471b568186cb53bf0d9/storage/browser/test/mock_special_storage_policy.h

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

commit f6e247dd4faa9aac2fadcc0772e9da69a3994165
Author: Christian Dullweber <dullweber@chromium.org>
Date: Mon Apr 09 14:19:24 2018

Check non-secure cookies against https settings

The change to allow non-secure cookies if https is allowed from
https://crrev.com/c/926369/5/components/content_settings/core/browser/cookie_settings.cc
still needs to be applied to properly match cookies for www.example.com against
a rule like https://[*.]example.com.

Bug:  775080 
Change-Id: I50f5b28663e816016e0d047b5dbceb16352667aa
Reviewed-on: https://chromium-review.googlesource.com/1002554
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Commit-Queue: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549168}
[modify] https://crrev.com/f6e247dd4faa9aac2fadcc0772e9da69a3994165/components/content_settings/core/browser/cookie_settings.cc
[modify] https://crrev.com/f6e247dd4faa9aac2fadcc0772e9da69a3994165/components/content_settings/core/browser/cookie_settings_unittest.cc

I believe these changes should handle cookie deletion much better. 
You can try it out in Chrome Canary and Dev releases greater than 67.0.3393.1.