Edit added 18:06 BST (= British Summer Time, = UTC+1), 02 Aug 2017: The version of Opera I refer to in my bug report is the one that contains what Opera refers to as a VPN (really just a proxy) and can be downloaded from www.opera.com. This version of Opera is not available via the Linux Mint Software manager and once installed appears in the Software Manager as Opera-stable. In the Software Manager's Software Sources it appears in the "Additional repositories" section. The version of Opera available via the Linux Mint Software Manager is an internet suite and doesn't contain the VPN.

1. Do you still see the data in other UI surfaces in Chromium, e.g. chrome://settings/cookies, chrome://settings/passwords etc.?

2. If not, then is the problem discovered by BleachBit that the data was not shredded (i.e. deleted but still recoverable from the disk) as opposed to not being deleted?

3. If not, could that have been another profile of Chromium? Can you check the name of the directory where the data was found? Should be something like e.g.

~/.config/chromium/Profile\ 1/Local\ Storage/

Then if you go to

~/.config/chromium/Profile\ 1/Preferences

and grep for \"name\", do you see the name of the profile you're currently using?

1. I don't see any cookies in chrome://settings/cookies after selecting More tools > Clear browing data, but BleachBit is finding cookies, which is very confusing. I have no idea what is going on. I have Chromium set to not save passwords, but BleachBit also finds passwords to delete - what on earth is it finding? (There are no passwords saved in chrome://settings/passwords).

2. Um, not sure. Would BleachBit inform me if the data had not been shredded?

3. I only have one Chromium profile as I'm the only user of this computer.

Please see the attached BleachBit screenshots and a text file showing the BleachBit output.

Deleted: BleachBit screenshot (1 of 2).png 211 KB

	BleachBit screenshot (1 of 2).png 211 KB View Download

Deleted: BleachBit screenshot (2 of 2).png 200 KB

	BleachBit screenshot (2 of 2).png 200 KB View Download

Deleted: BleachBit output in text format 2.9 KB

BleachBit output in text format 2.9 KB View Download

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

2. I don't know how BleachBit works, but it was my guess that software like that would also look for soft-deleted files (i.e. unlinked from the filesystem, but not physically overwritten).

However, if you never saved your passwords, that wouldn't explain the fact that BleachBit found some either.

Does it allow you to also view the data that were found, or only the size?

Re soft-deleted files, I don't *think* that's how BleachBit works, but I could be wrong. But if it is, then surely Chromium should be overwriting files after deleting their pointers? It only takes a little longer deleting files this way and something that Chromium should be doing, no? Especially since this is a privacy issue.

The fact that BleachBit is deleting passwords that don't exist is very confusing. I'm going to contact BleachBit about this.

I'm concerned with any locations where evercookies could be stored (allowing cookies to be recreated after deletion) and neither Chromium nor BleachBit covers *all* the possible locations that I mentioned in my original bug report where such cookies could be stored. But that's another issue for another day.

Could you please install Linux Mint as a virtual machine in a hypervisor like VirtualBox or VMWare, install BleachBit via the Mint Software Manager (available via the main menu in the bottom left of the screen) and check it out for yourself and see if you can recreate the problem? When you install BleachBit you're provided with a standard and a root version. Use the standard (i.e. non-root) version.

Just focussing on cookie files for now (cache, history, etc can wait), they are found in the directory /home/user/.config/chromium/Default. The trouble is, I don't know how to access one of these files. Two are text files (Cookies.db, Cookies-journal (both currently 0 bytes)). I can open these text files, but then there's a file called Cookies which is an SQLite3 application, currently containing 36.9kB. 
I have SQLite3 installed on my computer and can open it in the terminal, but for the life of me I can't work out how to open that Cookies file.
I've been doing some Googling (well StartPaging actually) to try and find out what to do, but I'm at a loss.
This is what I've tried:
- open terminal
- type in sqlite3, then press Enter
- from the sqlite prompt, type: .open /home/user/.config/chromium/Default/Cookies
Nothing happens, I just get another sqlite prompt.
I also tried opening sqlite3 as sudo -- same result.
Can you advise me on what to do to open this Cookie file? I'm not new to Linux, having switched when XP support ended, but I've never really had much need for the terminal apart from sudo apt-get install, so I'm floundering at the moment.

PS In my previous comment, when I wrote "evercookies" (as opposed to Evercookies with an uppercase E) I meant any type of persistent cookie that can't be deleted through the browser (i.e. non-HTTP cookies).
PPS I've only just noticed this, but even though BleachBit detected 20.5kB of non-existent password data (see screenshot 1 of 2 above), when you look at the text file showing the BleachBit deleted files and search for "password", you can see that no password data has been deleted. This is even odder than I initially thought.

I think I know what the problem is:
After clearing browsing data in Chromium, the SQLite3 Cookies file remains in the directory /home/user/.config/chromium/Default.
However, after running BleachBit this file is deleted (and presumably it's recreated next time I open Chromium).
So in a nutshell, Chromium isn't deleting SQLite cookies.

I think JavaScript is required to set SQLite cookies and since I have uBlock Origin set to block 3rd party scripts that can only mean that 1st-party JavaScript is setting these cookies, doesn't it? Or am I mistaken?

This is a serious privacy concern, but there are plenty of other places zombie cookies can hide, which I listed in my original bug report.
In my opinion, browsers need to block all non-HTTP cookies and make it impossible for non-HTTP cookies to be set. All that would remain would be standard 1st and 3rd party HTTP cookies, which can easily be blocked/deleted through the browser settings.

All APIs in Chrome that allow websites to intentionally write data to disk respect the cookies settings (including 3rd party cookie blocking etc.)

Selecting "Cookies and site data" in the Clear Browsing Data dialog deletes all such data.

So I wouldn't be worried about non-HTTP cookies.


My suspicion is that we're looking at an empty cookies database. This is especially reinforced by you saying that the file is recreated on Chrome restart.

And then, a bug in BleachBit which sees the file but doesn't realize it only stores an empty database.

+mkwst@ can you please comment on my suspicion?

Could 36.9kB large Cookies.db be an empty database?

+mkwst@ for real this time

I hope you're right that this file is empty, but the file in question is simply named Cookies, not Cookies.db
There is a file named Cookies.db but it always contains 0 bytes and is a text file that I can open.

The file named Cookies has no file extension and is named in the file browser as MIME type application/x-sqlite3 and I can't open it (despite trying) as explained at the bottom of comment 8. If you could explain to me how to open this file, then I would know for certain if this file is empty or not.

See the attached RTF file which shows what happens after clearing browsing history in Chromium, then deleting files using BleachBit.
As I said, I need to be able to open these SQLite3 files to see what's in them.
Can you tell me how to do this?

I don't understand the reply from mkwst@chromium.org, as I find it ambiguous.
Does he/she mean "For real, this is an empty database this time" or "This database is for real this time [i.e. isn't empty]"?
And as I mentioned already Cookies.db is an empty text file. It's the file named Cookies (MIME type application/x-sqlite3) that I'm referring to.

Lastly, does Chromium prevent cookies (or any other means of tracking) from being placed in the following locations that I referred to in my original comment.
- HTTP ETags
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage
- HTML5 Database Storage via SQLite (No is the answer to this one. Since this is one of the locations that according to Wikipedia is where zombie cookies can hide, then Chromium in this instance is allowing non-HHTP cookies, isn't it?)
- Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
- Local Shared Objects (LSOs, aka Flash cookies)
- Silverlight Isolated Storage
- Cookie syncing scripts that function as a cache cookie and respawn the MUID cookie
- TCP Fast Open
- TLS's Session ID
- window.name caching
- IndexedDB (I've never seen any data saved in this location on my computer, but I don't know if this is because Chromium is stopping sites from writing to this location or because no website I've been to so far has tried to store any tracking data in this location)

The Evercookie developer is looking to add the following features - could Chromium block/spoof these?
- Caching in HTTP Authentication
- Using Java to produce a unique key based on NIC information

Are there any other locations where persistent cookies (or any other means of tracking a user) could be stored in Chromium?

Then there's all the various types of fingerprinting to consider which can identify & track users: canvas, browser, OS, hardware, behavioural biometrics. But that's a whole other topic for another time.

Deleted: Files in Default directory before deleting anything.rtf 36.1 KB

Files in Default directory before deleting anything.rtf 36.1 KB Download

That SQLite3 Cookies file (not Cookies.db) is almost certainly *not* empty.
Why do I say this? Because of the following:
- run BleachBit (the Cookies file is deleted)
- open Chromium (the Cookies file isn't recreated upon opening the browser)
- browse to this site and log in (the Cookies file is now recreated and contains 28.7 kB of data and cookies appear in Settings > Advanced > Content settings > Cookies: 1 cookie for bugs.chromium.org and 18 cookies (plus LocalStorage & ChannelID data) from Google because of logging in)

- HTTP ETags
Clear disk cache to get rid of these.

- HTML5 Session Storage
- HTML5 Local Storage
Clear site data to clear these.

- HTML5 Global Storage
This isn't a thing, to the extent of my knowledge.

- HTML5 Database Storage via SQLite (No is the answer to this one. Since this is one of the locations that according to Wikipedia is where zombie cookies can hide, then Chromium in this instance is allowing non-HHTP cookies, isn't it?)
I think you mean IndexDB here?

- Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
Clear disk cache.

- Local Shared Objects (LSOs, aka Flash cookies)
Clear site data.

- Silverlight Isolated Storage
Silverlight doesn't work with Chrome.

- Cookie syncing scripts that function as a cache cookie and respawn the MUID cookie
Clear site data.

- TCP Fast Open
This data is stored by the OS, not Chrome.

- TLS's Session ID
Clear site data.

- window.name caching
I don't believe this is cached across restarts.

- IndexedDB (I've never seen any data saved in this location on my computer, but I don't know if this is because Chromium is stopping sites from writing to this location or because no website I've been to so far has tried to store any tracking data in this location)
Clear site data.

The Evercookie developer is looking to add the following features - could Chromium block/spoof these?
- Caching in HTTP Authentication
If you tell us to store a password he entered, you have to clear the password manually.  If a site uses this in a URL, I can't remember if we add it to the per-session auth cache or not. If we do, clearing site data should clear it, I believe.  Restarting Chrome will, too.

- Using Java to produce a unique key based on NIC information
Chrome doesn't support Java.

Clearing the cache (And maybe site data, too?) also closes all open connections, which can implicitly be used to identify a user.

If you're using incognito mode, none of this will be stored on disk, anyways (Except on Android - there, it's all removed once you close the last incognito tab [Which we do on all other platforms, too, but it's never backed by disk on other platforms]).

If you click on the "secure" button on the left of the omnibox, you can see all cookies read or set by a site.  Anyhow, this doesn't seem to list any concrete concerns.  If you're concerned about the very existence of cookies, there are extensions that can block all cookies.

If you're interested in where cookies come from, you can use about:net-internals, and see background activity.  Chrome does make requests in the background on startup (To, for instance, determine your region to determine which search URL to use), which is likely where the cookies you're seeing on startup are coming from.  Most of these can be disabled.

Anyhow, I'm not seeing any actionable concerns here.

Reply to: mmenke@chromium.org (comment 16)

Firstly, have a look at the RTF attachment in comment 14 - you can see that files aren't being deleted that I think should be.

As I said in comment 10, browsers need to block all non-HTTP cookies.
Block, not delete after the fact. 
The trouble with permitting any non-HTTP cookies is that you're never sure when deleting them whether you've got rid of them all.

Incognito mode blocks browsing history, cookies & site data, and information entered in forms. This doesn't block all the locations where persistent cookies can hide. Incognito isn't a silver bullet against persistent cookies/trackers and shouldn't be regarded (or touted) as such.

Re HTML5 Global Storage, you wrote: "This isn't a thing, to the extent of my knowledge."
It is according to Samy Kamkar, the creator of Evercookies: https://samy.pl/evercookie/
I have no idea what HTML5 Global Storage is or how it works, I'm just relating what I've read online.
Samy Kamkar also mentions HTTP Strict Transport Security (HSTS) Pinning, which I haven't mentioned before. (And no I have no idea what it is or how it works. I'll need to research it).

Re HTML5 Database Storage via SQLite, you wrote "I think you mean IndexDB (sic) here".
I don't know what I mean, I'm just repeating what I've read online.
See: https://samy.pl/evercookie/ where HTML5 Database Storage via SQLite & HTML5 IndexedDB are two separate entries.

Re TCP Fast Open (TFO), you wrote: "This data is stored by the OS, not Chrome."
Stored where? Stored by what mechanism?
https://en.wikipedia.org/wiki/TCP_Fast_Open
"In computer networking, TCP Fast Open (TFO) is an extension to speed up the opening of successive Transmission Control Protocol (TCP) connections between two endpoints. It works by using a TFO cookie (a TCP option), which is a cryptographic cookie stored on the client and set upon the initial connection with the server."
Wikipedia continues: "Google Chrome and Chromium browsers have support for TFO on Linux, including Chrome OS and Android."
So this suggests that Chromium has control over how and where this TFO cookie is set, doesn't it?

Re window.name caching, you wrote "I don't believe this is cached across restarts."
Well, firstly I'd like to know for certain, and secondly why are cookies allowed to be saved in this location in the first place? This shouldn't be happening. Only standard, non-tracking 1st-party HTTP cookies should be allowed, i.e. cookies used purely to save user preferences on sites, not to track users across sites.

It's the tracking element of cookies I'm concerned about (and the fact that many are script-readable), not cookies per se.
1st-party HTTP cookies can be useful on certain sites to remember user preferences, but I clear out all my cookies, because I don't want persistent cookies on my machine. I shouldn't have to do this, but I'm forced to because browsers and most sites don't take privacy seriously.

And even after clearing out all the cookies and tracking data with BleachBit, how do I know I've got it all? I don't.
That's why non-HTTP cookies need to be blocked, not deleted after they've been set. That's like closing the stable door after the horse has bolted.

Incognito blocks all forms of persistent storage - that's the promise of incognito mode.

Note that blocking all forms of persistent storage when not in incognito breaks websites, makes the web slower (Etags, for instance, exist so that we can ask if a page in the cache can still be reused).

We support TFO by telling the system to use TFO if it already has a TFO cookie - the OS is what manages whether it has a TFO cookie or not.

Anyhow, I don't think there's any evidence of Chrome bug here.

Chrome has the ability to clear site data - if you don't trust that to work, you can just delete your profile directory.  Though if you don't trust Chrome itself, there's not really a whole lot we can do.

Note that the "global storage" link on https://samy.pl/evercookie/ links to "local storage" and "session storage".  HSTS pinning is also cleared when you clear the cache.  Ahh, SQLite was referring to WebSql (Which I believe is deprecated).  I assume it's also hooked up.

Looks like you didn't clear history, so of course the history wouldn't be cleared.  "Top sites" is for figuring out what goes on the NTP, I believe.  Anyhow, I'm not seeing any privacy bug here that needs to be fixed, so I'm going to go ahead and WontFix this.

You can't just close the bug report like that.
Well you can, you've just done it, but that's hardly a methodical way to proceed, since we haven't confirmed yet if this is a Chromium bug or not.

And you can't set the status as "Won't fix" because:
(a) That wording implies that there's something to fix, but you won't do it (as opposed to "Nothing to fix")
and (b) You don't know what the issue is yet, so you're jumping the gun by setting the status to "Won't fix".

You wrote "I don't think there's any evidence of [a] Chrome bug here."
You don't *think*? Well, that's not very scientific, is it? How about proof? How about doing some research to determine exactly what the issue is here? Is it a Chromium bug or a BleachBit one?

How about explaining to me how to open the SQLite3 files in /home/user/.config/chromium/Default?
I've asked twice how to open these files and been ignored twice.
Until I open these files I won't know what's in them.
Maybe it's all perfectly innocent data, but we won't know for definite until I open them.

I requested in comment 8 that you set up a virtual machine to get to the bottom of this. Have you done that?

Oh and I did clear my History as you can clearly see in the BleachBit screenshots in comment 5, so that comment of yours was inaccurate.

You need to re-open this bug report and carry out a proper investigation.
if you don't then your methodology leaves a lot to be desired.