Chrome not Safely Deleting Browsing History
When deleting the Chrome browser cache, some history items may prevail. Not for good.
The mean thing is that these "lost" history items won't show up directly in Chrome's app history, but are hidden in the database that Chrome uses to store the history items. This database is easily accessible from the terminal. Let's see how a typical Chrome history looks like:
To see your own browsing history, as saved in Chrome's database, open the Terminal app and enter the following command:
This should result in an output similar to the one shown in the picture above. Note the fourth column (a column is text or a number separated by |), this is the so called visit count: an indicator how often you visited this URL (it doesn't necessarily give a fair account, but that's another story). It should usually be greater than zero, because you've already visited any item in the history, right? Here comes the problem: We haven't been able to discover why, but Chrome sometimes zeroes this visit counter. That wouldn't be of any importance, but it appears that when you "Clear Browsing Data" within Chrome (from the Chrome menu), even when selecting "Browsing history", Chrome ignores entries with a zero visit count.
The result is that these items remain in the history. You won't find them in the browser, though, because there it doesn't show items with a zero count (which seems right, they shouldn't be in the history in any case). But you can still find them in the database, the command is the same as above:
The only way to safely delete these history items is to use the command line again and type the following command:
Caveat: The bug we found adds to the knowledge that even the "Private Surfing" modes of the major browsers are not safe, as recently evidenced by the favicon bug in Safari (fixed in Safari 8.0.5). We could not reproduce this bug on all machines or with all accounts, though, but we found considerable evidence. There seemed to be no relation to different configurations. However, the visit count doesn't seem to be the only trigger, as it doesn't help in reproducing the bug to zero some entry's visit count or to add a new dummy entry with
UPDATE: We filed this as Chromium bug #490913. (MacConfig)