Can you explain precisely, step-by-step, how you performed the "deleting all private information" operation?

Step 0. I used web.whatsapp.com for browser based WhatsApp version.I used WhatsApp For my tests, because a single screenshot of its web based interface could leak a lot of information about my last chats. For example, Gmail lists all inbox messages on one page, so a single screenshot might leak a batch of sensitive information about your communications. 

Step 1. I pressed Ctrl + H (for web browsing history)

Step 2. I pressed "Clear Browsing History" button on the left pane

Step 3. In the "Clear browser data" pop-up window, I have selected "the beginning of time" and have checked all checboxes (browsing history, download history, cached images and files, cookies and other site data, passwords, auto fill form data, hosted app data, media licenses)
Step 4. I have pressed "Clear Browsing data" button

Step 5. After all history and etc. data had been deleted, I restarted browser and visited "chrome-search://thumb/http://web.whatsapp.com", which revealed a screenshot of my WhatsApp chat. Even it was in low resolution I was able to see with whom I was chatting, and last messages I sent. 

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

PS: if needed I can record a step by step video

Assigning this to msramek@.

Passing to NTP owners.

- I think this should be classified as a privacy bug rather than a security bug, but that's for security folks to decide.

- In Chrome 61+, the thumbnail size is reduced to 308x192, which slightly mitigates the problem.

- For the actual problem: It looks like thumbnails aren't cleared when you clear history. Will have to investigate more.

Setting target milestone to M62 since this is a potential privacy issue. 

Too late for M62.

msramek@, can you help prioritize?
To summarize, the problem is: We capture thumbnails of pages you visit frequently (mostly those that show up on the NTP, though it's not quite 1:1). When clearing history, these thumbnails are not cleared. This allows some inference about the history that was supposed to be cleared: By visiting "chrome://thumb/http://website.com", you can check whether a thumbnail exists, and if so, infer that website.com was visited before in this profile.

It's kinda obscure, it only works one way (absence of a thumbnail doesn't tell you anything), and AFAIK it's always been this way, i.e. not a regression.

Deleting browsing history should delete any derived entries in other data storage backends (there's a lot of them - site engagement data, app banner data, webrtc logs, domain reliability beacons etc.).

Stored thumbnails certainly belong to this category, and should be cleared. If this bug has existed forever, I won't insist on M62 merge, but then again, the deletion code should not be that large.

Two questions to help me understand the problem:
- Are the thumbnails keyed by URL / origin / domain / something else?
- Are all thumbnails added as a result of the user's browsing activity, or is it possible for some of them to come from other sources (e.g. from a generic Zine suggestion that is served to everyone in a country)

- They're keyed by URL, with some special casing (query and fragment are ignored, http and https are considered equivalent, redirects are considered equivalent, possibly more).
- These thumbnails are only added as the result of browsing activity.

Thanks!

Then we should really just make the thumbnail service a HistoryServiceObserver and delete the corresponding entry when a URL is deleted.

We may over-delete a bit, e.g. if there are two history entries

http://example.com/?query=1
https://example.com/?query=2

that share a thumbnail, and the user only deletes one of them, we would delete a thumbnail that also belongs to the other one. I'm not sure how much that is a problem in practice. If it is, we could keep a thumbnail while any corresponding entry lives in the local history (3 months) - but that is also more work.

As every thumbnail is a byproduct of history, tying this to history deletion will ensure that we catch everything.

Given that one needs to know what they're looking for (i.e. query individual URLs in "chrome://thumb"), and that it's not a regression, I think I'm fine with leaving this as M=63 and Pri=2.

Turns out that TopSitesImpl (which manages the thumbnails in addition to the actual top sites) is already a HistoryServiceObserver, and does delete URLs and their thumbnails when history entries are deleted. At least in the common case, everything seems to work fine. I guess there must be some edge case where it doesn't.

I've tried and failed to reproduce this. I tried Chrome Stable (60), Beta (61) and a current trunk build. All properly cleared the thumbnails when history is deleted, both for "all time" and for limited time spans. I've also looked over the code, and couldn't find a case where we'd miss a deletion.
I'm out of ideas...

To the original reporter:
- Is this still reproducible for you? Does it happen every time or only sometimes?
- Are you signed in to Chrome Sync?
- Could you post the contents of chrome://ntp-tiles-internals both before and after clearing history?

Reducing prio and removing Milestone since it's not reproducible.

chrome://thumbnails before and after clearing history might also be interesting.

Hello.
Q:Is this still reproducible for you? Does it happen every time or only sometimes?
A: Yes. It happens every time.

Q: Are you signed in to Chrome Sync?
A: Not signed. It happens even if I am not logged into any Google services.

Q: Could you post the contents of chrome://ntp-tiles-internals both before and after clearing history? chrome://thumbnails before and after clearing history might also be interesting.
A: Here are my screenshots:
1.png - WhatsApp thumbnail Before clearing history
2.png - chrome://thumbnails Before clearing history
3.png - chrome://ntp-tiles-internals Before clearing history
4.png - WhatsApp thumbnail After clearing history
5.png - chrome://thumbnails After clearing history
6.png - chrome://ntp-tiles-internals After clearing history

Deleted: 1.png 73.1 KB

	1.png 73.1 KB View Download

Deleted: 2.png 113 KB

	2.png 113 KB View Download

Deleted: 3.png 34.5 KB

	3.png 34.5 KB View Download

Deleted: 4.png 72.3 KB

	4.png 72.3 KB View Download

Deleted: 5.png 74.9 KB

	5.png 74.9 KB View Download

Deleted: 6.png 27.8 KB

	6.png 27.8 KB View Download

For the screenshot named 4.png. I have closed the tab and visited chrome-search://thumb/http://web.whatsapp.com/ again after clearing history.

Thanks for the detailed investigation! I think your last comment explains it. Let me try to summarize the relevant points to make sure I understood correctly:
- While you're clearing history, the WhatsApp tab is still open.
- After clearing history, you close the WhatsApp tab.
Is that accurate? If so, I believe everything is working as intended. This is what's probably happening:
The thumbnail actually gets cleared when clearing browsing data. However, when you then close the tab, we take a new thumbnail. That's not entirely unreasonable: Open tabs also don't get closed when clearing browsing data, and arguably you "visited" the page again after clearing.

To verify, could you try again, but close the WhatsApp tab before clearing browsing data?

I have closed WhatsApp tab before clearing browing data. The result is the same. I have recorded my screen to show the steps I have performed.

Note: the issue became less critical after Chrome 61+ release. Before version 61, the thumbnail was larger and it was accessible even after clearing history, closing browser window and restarting OS.

Deleted: 2017-10-31 at 11-25-19.mp4 1.4 MB

	2017-10-31 at 11-25-19.mp4 1.4 MB View Download

Thanks for reporting back again! That proves that my assumption above was wrong, and the thumbnail is in fact *not* getting deleted.

Unfortunately I still couldn't reproduce this, or figure out where exactly the problem is. You're saying that in version 61, the thumbnail is *not* accessible anymore after restarting Chrome, right? That means the actual database is probably deleted correctly, but some in-memory cache isn't cleared. I'll have to investigate more...

Q:You're saying that in version 61, the thumbnail is *not* accessible anymore after restarting Chrome, right? 

A:Yes, you got it right. But it *was* accessible event after restaring Chrome, or restarting PC before Chrome version 61. In version 61, it remains somewhere in cache until user restarts Chrome. 

I've found the problem: When clearing browsing data, we fail to clear the in-memory cache of thumbnails. We *do* clear all "canonical URL" mappings, things like if a redirect happened (e.g. from google.com to google.de, or from http to https), so the thumbnail will only be accessible via the exact URL under which it was stored. That's why it doesn't always seem to reproduce.

The good news is, the fix should be simple.

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

commit 6c6888565ff1fde9ef21ef17c27ad4c8304643d2
Author: Marc Treib <treib@chromium.org>
Date: Wed Nov 08 17:03:38 2017

TopSites: Clear thumbnails from the cache when their URLs get removed

We already cleared the thumbnails from persistent storage, but they
remained in the in-memory cache, so they remained accessible (until the
next Chrome restart) even after all browsing data was cleared.

Bug:  758169 
Change-Id: Id916d22358430a82e6d5043ac04fa463a32f824f
Reviewed-on: https://chromium-review.googlesource.com/758640
Commit-Queue: Marc Treib <treib@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514861}
[modify] https://crrev.com/6c6888565ff1fde9ef21ef17c27ad4c8304643d2/components/history/core/browser/top_sites_cache.cc
[modify] https://crrev.com/6c6888565ff1fde9ef21ef17c27ad4c8304643d2/components/history/core/browser/top_sites_cache.h
[modify] https://crrev.com/6c6888565ff1fde9ef21ef17c27ad4c8304643d2/components/history/core/browser/top_sites_cache_unittest.cc
[modify] https://crrev.com/6c6888565ff1fde9ef21ef17c27ad4c8304643d2/components/history/core/browser/top_sites_impl.cc
[modify] https://crrev.com/6c6888565ff1fde9ef21ef17c27ad4c8304643d2/components/history/core/browser/top_sites_impl_unittest.cc

This should fix it. I'll let you know when the change is available in Dev/Canary so it can be tested.

The latest Chrome Canary (64.0.3265.0 or later) contains the fix.

If you want to try it out, you can get Chrome Canary (for Windows and Mac) at https://www.google.com/chrome/browser/canary.html.

I have installed Chrome Canary and tried to reproduce the issue. I confirm that the problem is fixed now and thumbnails are properly deleted. 
Thank you :)

Thanks for verifying, and for your help in diagnosing the issue! It's much appreciated!

Just wondering if there is any reward applicable? :)

I'm not super familiar with the rewards program(s), but I don't think so unfortunately. AFAIK rewards are generally given only for security bugs, while this is "only" a privacy issue. Maybe the security folks on CC here can give a more authoritative answer?

+awhalley@ for #31 and #32, since this is also marked as a security issue.

In this case, I'm afraid it's not covered by the VRP, per "deleting browsing data" of

https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Are-privacy-issues-considered-security-bugs-

Many thanks for the report, though!

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