New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 758169 link

Starred by 1 user

Issue metadata

Status: Verified
Closed: Nov 2017
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 2017

Issue description

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?

Comment 3 by, Aug 24 2017

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 2017

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

Comment 5 by, Aug 24 2017

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

Comment 6 by, Aug 25 2017

Labels: Security_Impact-Stable Security_Severity-Low
Status: Assigned (was: Unconfirmed)
Assigning this to msramek@.
Components: UI>Browser>NewTabPage
Passing to NTP owners.

Comment 8 by, Aug 29 2017

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.

Comment 9 by, Sep 4 2017

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.

Comment 14 by, Sep 12 2017

Status: Started (was: Assigned)
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.

Comment 15 by, Sep 14 2017

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...

Comment 16 by, Sep 14 2017

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?

Comment 17 by, Oct 12 2017

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
For the screenshot named 4.png. I have closed the tab and visited chrome-search://thumb/ again after clearing history.

Comment 20 by, Oct 30 2017

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 2017

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.

Comment 27 by, Nov 13 2017

Status: Fixed (was: Started)
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 2017

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 :)

Comment 30 by, Nov 14 2017

Status: Verified (was: Fixed)
Thanks for verifying, and for your help in diagnosing the issue! It's much appreciated!
Just wondering if there is any reward applicable? :)

Comment 32 by, Nov 15 2017

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 2018

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
Labels: CVE_description-missing
Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment