New issue
Advanced search Search tips
Starred by 1 user
Status: Verified
Closed: Nov 13
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Bug-Security

Sign in to add a comment
Website thumbnail screenshot access even after all private data is deleted
Reported by, Aug 23 Back to list
UserAgent: Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Steps to reproduce the problem:
After deleting all private information, visiting the "chrome-search://thumb/http://website_name" url reveals a low resolution screenshot (424x284 pixels) of a visited website.

What is the expected behavior?

What went wrong?
Website thumbnail screenshot can be accessed even after deleting all private information such as history, cookies, thumbnails, images and etc (all checkboxes checked and "from begining of time" is selected) from Google Chrome webbrowser. Thumbnail can be accessed by visiting "chrome-search://thumb/http://website_name" url, which reveals a low resolution screenshot (424x284 pixels) of a visited website. You can see a thumbnail even after Chrome or OS restart. This is a security flaw, because for example someone could visit chrome-search://thumb/ and see a screenshot of Whatsapp communication with the list of contacts. 

Did this work before? N/A 

Chrome version: 60.0.3112.101  Channel: stable
OS Version: 6.2 (Windows 8)
Flash Version:
Components: UI>Browser>History Privacy
Labels: Needs-Feedback
Can you explain precisely, step-by-step, how you performed the "deleting all private information" operation?
Step 0. I used 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/", 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. 

Project Member Comment 4 by, Aug 24
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "" to the cc list and removing "Needs-Feedback" label.

For more details visit - Your friendly Sheriffbot
PS: if needed I can record a step by step video
Labels: Security_Impact-Stable Security_Severity-Low
Status: Assigned
Assigning this to msramek@.
Components: UI>Browser>NewTabPage
Passing to NTP owners.
Labels: OS-Chrome OS-Linux OS-Mac
- 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.
Labels: M-62 zine-triaged
Setting target milestone to M62 since this is a potential privacy issue. 
Labels: -M-62 M-63
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/", you can check whether a thumbnail exists, and if so, infer that 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.

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

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.
Status: Started
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...
Labels: Needs-Feedback
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?
Labels: -Pri-2 -M-63 Pri-3
Reducing prio and removing Milestone since it's not reproducible.

chrome://thumbnails before and after clearing history might also be interesting.
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
73.1 KB View Download
113 KB View Download
34.5 KB View Download
72.3 KB View Download
74.9 KB View Download
27.8 KB View Download
For the screenshot named 4.png. I have closed the tab and visited chrome-search://thumb/ 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.
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 to, 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.
Project Member Comment 25 by, Nov 8
The following revision refers to this bug:

commit 6c6888565ff1fde9ef21ef17c27ad4c8304643d2
Author: Marc Treib <>
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
Commit-Queue: Marc Treib <>
Reviewed-by: Sylvain Defresne <>
Cr-Commit-Position: refs/heads/master@{#514861}

This should fix it. I'll let you know when the change is available in Dev/Canary so it can be tested.
Status: Fixed
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
Project Member Comment 28 by, Nov 13
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
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 :)
Status: Verified
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

Many thanks for the report, though!
Labels: reward-ineligible
Labels: M-64
Labels: Release-0-M64
Labels: CVE-2018-6053
Project Member Comment 39 by, Feb 19 (4 days ago)
Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Sign in to add a comment