Unable to reproduce this issue on windows 10 with chrome #64.0.3282.140 as per steps mentioned in comment #0

Observation : 
Even after browser restart, cookies are still visible.

Attaching the screen-cast for reference.

brutakas@ Could you please look into it and let us know any steps i have missed while reproducing the scenario.

Thank You...

Not seeing a screen-cast.

However, I did some more testing and found out that there is an additional factor.

For Step#2, the allow pattern should be https://[*.]google.com (or https://[*.]google.com:443). I overlooked the fact that all of my auth cookies had the https://. By removing the https:// the cookies are no longer being deleted with my current settings.

The peculiar thing is when viewing a site using https and adding a new allow cookie rule using the cookie button in the top right of the address bar, chrome creates the rule using the above pattern e.g. https://[*.]bugs.chromium.org:443. It allows the cookie to be set while browsing just fine but exiting the browser doesn't seem to keep the cookies

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce this issue on reported version 64.0.3282.140 using windows 7 with steps mentioned below.

1. Navigated to chrome://settings/content/cookies and blocked cookies.
2. In Allow section added https://[*.]facebook.com 
3. Logged into facebook.com and observed cookies.
3. Closed chrome and opened again, observed logged into profile and cookies are seen.

@Reporter: Could you please check the screencast and let us know if we miss anything. If possible please provide video to understand the bug in a better way.

Thanks!

After some testing, it appears that the bug is site specific. I don't know how to identify a site that will do this.

The x-factor is that I had a rule for "Clear on exit" for [*.]google.com (which I made sure removed when testing any google.com sites).

For example, logging in to https://www.giantbomb.com/ with the following settings:

Blocked cookies
Clear on exit: [*.]google.com
Allow: [*.]giantbomb.com

Will work just fine for login and for closing the browser.

However when the allow rule is changed to https the cookies will not remain after the browser is closed.

Blocked cookies
Clear on exit: [*.]google.com
Allow: https://[*.]giantbomb.com
It may be important to note that after reopening the browser, I appear to be logged in but upon refreshing the page or navigating the site, I am no longer logged in.

If the clear on exit for google.com is removed then everything works fine in both cases ([*.]giantbomb.com vs https://[*.]giantbomb.com). The site saves its cookies on two different domains: "giantbomb.com" and "www.giantbomb.com".

I also just updated to v64.0.3282.167 and was able to reproduce the above.

I don't know if this even counts as a chrome issue anymore. I will have to try and see if I can get something similar to happen in firefox with similar cookie rules/settings.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I believe the issue is related to this change:  https://crbug.com/784312 

The issue with cookies is that they are not strictly bound to the origin that creates them. E.g. https://www.example.com can set cookies that can be read by http://example.com. 
We recently fixed an issue where blocking all cookies and setting www.example.com as Clear On exit would allow www.example.com to create a cookie for google.com that would never be cleared. As we don't track which site created a cookie, we decided to also delete cookies from blocked sites if there are Clear on exit rules.

You have found a similar issue: You allowed https://giantbomb.com to access cookies. https://giantbomb.com created a cookie that was not marked as secure. http://giantbomb.com is blocked, so due to the recent change we will delete its cookies. 

As you already noticed, a solution would be to allow [*.]giantbomb.com.

We could keep non-secure, blocked cookies for example.com if https://example.com is allowed?

Able to reproduce this issue on reported version 64.0.3282.167 , on latest beta 65.0.3325.73 and on latest canary 66.0.3350.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04 with steps mentioned in comment#8. On using https://[*.]giantbomb.com , and re=opening browser, observing logout.

Good Build: 64.0.3275.0
Bad Build: 64.0.3276.0

You are probably looking for a change made after 518646 (known good), but no later than 518647 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/0fdbe9100e1f0b8621f8fb2c283e1145eb521c59..369b5757b2a1b94c89dda2cb10576bd4026544d8

Reviewed-on: https://chromium-review.googlesource.com/766372

Suspecting same from changelog.

@ dullweber: Please confirm the issue and help in re-assigning if it is not related to your change.

Adding RB-Stable for M-64. Please change if not the case.

Thanks! 

As mentioned above, this is the right change. 

Only users with a specific combination of Clear On Exit, Allow and Block content settings are affected and there is a workaround, so I don't think this requires RB-Stable. We can think about a fix in M-66. As M65 is quite close already, it probably shouldn't be merged.

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

commit cb95a65980b204a38515c813f70da866e0328bee
Author: Christian Dullweber <dullweber@chromium.org>
Date: Mon Feb 26 14:24:23 2018

Improve blocked cookie deletion

The recent change to delete blocked cookies affects cookies set by https
sites if they are not marked secure. This prevents blocking http sites
from using cookies without affecting these non-secure cookies from
https sites. To fix this non-secure cookies will not be deleted if http
is blocked but https is allowed.

Bug:  811147 
Change-Id: Id6087acacc11702dd935c7a68e493f900266c0a9
Reviewed-on: https://chromium-review.googlesource.com/926369
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539125}
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/chrome/browser/extensions/extension_special_storage_policy.cc
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/chrome/browser/extensions/extension_special_storage_policy.h
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/chrome/browser/extensions/mock_extension_special_storage_policy.cc
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/chrome/browser/extensions/mock_extension_special_storage_policy.h
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/chrome/browser/sessions/session_data_deleter.cc
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/components/content_settings/core/browser/cookie_settings.cc
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/components/content_settings/core/browser/cookie_settings.h
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/components/content_settings/core/browser/cookie_settings_unittest.cc
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/content/browser/net/quota_policy_cookie_store.cc
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/extensions/shell/browser/shell_special_storage_policy.cc
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/extensions/shell/browser/shell_special_storage_policy.h
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/storage/browser/quota/special_storage_policy.h
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/storage/browser/test/mock_special_storage_policy.cc
[modify] https://crrev.com/cb95a65980b204a38515c813f70da866e0328bee/storage/browser/test/mock_special_storage_policy.h

The issue will be fixed in M66.