At what point in your steps did you clear existing data?

The second screenshot does not necessarily show that local storage is set for Google.com. Can you click the arrow to the right side of the UI to expand it, then take a screenshot of the content that appears underneath?

The steps are taken as follows: 
1. Set up permissions as shown (img 1) 
1. Clear all cookies and local storage (img 2)
2. Exit Chrome completely. Relaunch with a single empty tab open 
3. Visit google.com (img 3)
4. Check "all cookies and site data" (4a and 4b)
Same sequence works for facebook.com

Deleted: 1.png 82.0 KB

	1.png 82.0 KB View Download

Deleted: 2.png 49.1 KB

	2.png 49.1 KB View Download

Deleted: 3.png 66.4 KB

	3.png 66.4 KB View Download

Deleted: 4a.png 42.3 KB

	4a.png 42.3 KB View Download

Deleted: 4b.png 56.1 KB

	4b.png 56.1 KB View Download

Thank you for providing more feedback. Adding requester "elawrence@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

As a possibly related issue, other sites seem to be able to escape "clear on exit" setting. For example the following sequence:

1. Set up permissions as shown (img 1)
2. Clear all local storage and cookies. Exit and restart browser (Cmd + Q, verified)
3. Visit airbnb.com, visit tripadvisor.com
4. Exit and restart browser (Cmd + Q). Browser opens a single empty tab on startup.
5. Check "all local storage" - has local storage for airbnb.com and tripadvisor.com (img 2a, 2b)

Deleted: 1.png 81.1 KB

	1.png 81.1 KB View Download

Deleted: 2a.png 47.5 KB

	2a.png 47.5 KB View Download

Deleted: 2b.png 42.8 KB

	2b.png 42.8 KB View Download

The screenshot in c#2 shows 0 bytes of local storage data, so I don't think there's an issue there.

The screenshot "2b.png" in c#4 looks more interesting. I'm not entirely sure how database storage is expected to behave.

FWIW, as a user, to me it feels that if storage is blocked, there should be nothing stored (including any empty reference, which still could be used as a kind of a marker by the web site - for example using its unique name). Certainly not any amount of actual data.  

jsbell: Can you please help us figure out what the expectations are? If there is a bug, can you please delegate it to someone who can fix it? Thanks!

jsbell: can you please take a look and help triage this? thanks.

pwnall -- it seems that jsbell is OOO. Can you please take a look?

+dullweber@

Re #2, #5: There was a recent bug 773447 (already fixed in Canary) where local storage was cleared, but the entry for origin was not. This looks like the same thing in the other direction - when visiting the site again, a storage entry was not filled, but it was added.

Re #6: Absolutely, this is a privacy issue.

Re #7: The expectation for local storage is to follow cookie settings.

While I can reproduce the issue on Chrome 62, it doesn't appear in Chrome Beta 63. I guess the localstorage fix also solved this issue? (63.0.3239.30 on linux)

The Clear Browsing Data dialog is still showing a non-zero cookie count when sites have been visited while cookies are disabled. This is due to the "site-engagement" website-setting.
Websites can't read or write from these settings directly but they could infer whether a site has been visited based on behavior that is controlled by site-engagement. I will look into possible ways to solve this issue.

Setting to Security_Impact-None since this is really a privacy bug, not a security bug.

The localstorage issue is already fixed in Chrome 63.
The issue with website-settings is a separate problem, so I created a bug for it  https://crbug.com/782606 .

Just a note wrt. this issue - here is another manifestation. It appears that some sites may evade cookie policy and have actual cookies survive the session restart.

1. Ensure hafjell.no cookies allowed for session only
2. Clear cookies for site hafjell.no
3. Visit hafjell.no
4. Exit and restart browser, check cookies
I see a single __cfduid cookie still set from that site. 

Still testing chrome 62

Hm, I tried this but can't reproduce the issue. 

To clarify:
Do you have Chrome configured to restore tabs on start?
If yes, did you close hafjell.no after step 3?
Where are you checking cookies? chrome://settings/siteData?

- Chrome is configured not to restore tabs on start and to begin with an empty page
- Checking cookies under chrome://settings/siteData

Further clarification, reproducing this issue requires specific cookie settings:
1. Set global cookie setting to "blocked" (also "block 3rd party data")
2. Add the following to the "session only" list: [*.]www.hafjell.no 
3. Visit the site, exit browser, restart and verify 

If you add the following to the "session only" list: [*].hafjell.no (in addition to the previous entry) - the cookie will no longer survive restart.

The cookie that is set and survives restart is for hafjell.no. 
There are several cookies for www.hafjell.no that do not survive restart with either rule.

It would appear that permitting www.hafjell.no somehow allows cookies to be set for hafjell.no as well, but then on exit does not clear them (inconsistently applied filter?)

I can reproduce this issue. Thanks for the detailed explanations! I created a new bug to track it:  https://crbug.com/784312 

Adjusting labels: Since this is a privacy bug not security, no need for bug-security.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

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