755996 - [New Tab Page] shows sensitive information in the thumbnails

Status: RESOLVED FIXED

(Firefox :: New Tab Page, defect, P3)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #754608 +++

(In reply to Thomas from Bug #754608 comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101
> Firefox/13.0
> Build ID: 20120509070325
> 
> Steps to reproduce:
> 
> When you open a new tab, clicking the +, a new tab will open with a blank
> page. Click on the grid in the upper right hand corner and a 3x3 page
> preview appears.
> 
> 
> Actual results:
> 
> I have found that there is too much information available to people when
> using this option. For instance, I filled out a form on the computer, and in
> the preview screen it showed my completed form, including my full name,
> address, phone number, etc.
> 
> 
> 
> Expected results:
> 
> This feature is too risky as is. Even if there is an option to shut this
> off, someone with a little know-how could just turn it back on and wait to
> retrieve someones information on a public computer.

(In reply to Brian Smith (:bsmith) from Bug #754608 comment #23)
> Nit: the caching of HTTPS pages is enabled by default, so the comments
> saying "don't cache thumbnails of HTTPS unless the user explicitly enabled
> it" are misleading.
> 
> More seriously, I do not think the patches in this bug do a lot to address
> the bug reporter's concerns. It does make sense to honor no-store but it
> seems like that is a very small part of solving this bug.
> 
> Consider a modern web application where it will be pretty normal for the
> application itself to be cacheable, and then load in sensitive (no-store)
> content via subresources and/or via XHR. For example, you can imagine an
> HTML 5 e-banking application that uses AppCache for the application
> HTML+JS+CSS, and then loads bank account information via XHR, and even does
> login/logout via XHR. Presumably, if we really think "no-store" is the way
> to prevent thumbnails of sensitive information, then it needs to take into
> account every load done on the page; that is, if you couldn't, in theory,
> reconstruct the page by re-loading everything exclusively from the cache,
> then for a no-store-based solution, you shouldn't save the thumbnail. On the
> other hand, if somebody using the computer could just go to the URL of the
> page that was captured and see the same information (e.g. because of saved
> cookies), then "honoring" no-store isn't much of a security benefit.
> 
> Also, we have non-HTTP data loads, WebSockets in particular, that don't have
> a way to say "no-store" that can and will be used to load sensitive
> information.
> 
> It seems very difficult to actually solve the bug reporter's problems, in
> general. However, I think there are several additional mitigations that
> could be taken:
> 
> 1. The bug reporter said "I filled out a form on the computer, and in the
> preview screen it showed my completed form, including my full name, address,
> phone number, etc." It seems to me that a good heuristic to prevent most
> instances of this would be to avoid including form fields in the screenshot.
> 
> 2. Like I mentioned above, if we care about no-store, we should take all the
> no-store headers into account.
> 
> 3. The bug reporter mentioned the idea of using a "public computer" or more
> generally a shared computer. Because all solutions for this are imperfect,
> it does seem reasonable to enable the computer administrator to disable
> thumbnails completely and permanently in a way that users cannot enable it.
> I think there might be an option to do so, but it isn't clear at all how to
> do so. (More generally, I think it would be beneficial if we had a "public
> kiosk" installation mode that made it really easy to flip all the relevant
> settings at once.) I think we are going to get lots of bug reports like
> this, for this feature and others, and it would be good to have a clear
> description of our design criteria for these features regarding the privacy
> issues for public/shared computers, so we don't have to rehash these issues
> over and over again.
> 
> 4. Like I mentioned above, a very thorough way of solving these issues would
> be to save a thumbnail of the page that was retrieved without any HTTP
> cookies or HTTP auth credentials sent in the requests (for the page, and for
> any sub-resources).
> 
> 5. Because the above mechanisms are far from perfect, and because we cannot
> detect all problematic cases, and because of WebSockets and other upcoming
> non-HTTP transport protocols, we should have some mechanism for a page to
> indicate that the current page (and/or some parts of the page; e.g. using
> CSS @media thumbnail or some such thing) should not be saved as part of the
> thumbnail, independent of cache-control:no-store.

(In reply to :Gavin Sharp (use [e-mail] for email) from Bug #754608 comment #24)
> Those are all valid points, but now that we've used this bug to track the
> landing of a patch, I don't think we should re-use it to track the larger
> issue, despite that larger issue being what the bug was originally filed
> about. Can you create a new bug and copy your comment there?

Comment 1

[Jesse Ruderman]

> > Consider a modern web application where it will be pretty normal for the
> > application itself to be cacheable, and then load in sensitive (no-store)
> > content via subresources and/or via XHR.

Such pages will probably want to prevent the Back button from restoring the page. So they'll have to use no-store on the app page too. (Or break bfcache in some other way, I guess.)

Comment 3

[Mike Kaply [:mkaply]]

Perhaps the problem here is simply that Mozilla's thumbnails are too big.

Chrome's thumbnails are small enough that you would never be able to view any sensitive information.

Comment 4

[Jesse Ruderman]

I disagree with the reasoning in comment 3:

* Sensitive text: while sensitive text tends to be small, making it unreadable by humans, an algorithm could probably infer the original text.

* Sensitive photos: these usually stay sensitive when shrunk.

On the other hand, I think this bug should be WONTFIX for the reasons in comment 1.

Comment 5

[Marco Castelluccio [:marco]]

I think there isn't a perfect way to avoid this problem, we could use the solution suggested by Michael in comment 3 and some heuristics (like not taking thumbnails of pages with filled forms) and have an option to completely disable the feature.
The problem right now is that a lot of web sites are using or are switching to HTTPS, and so a considerable percentage of the thumbnails aren't showed. For the common users this is a Firefox bug.

Comment 7

[dustnmud]

You could maybe add an option to manually grab a thumbnail on https sites. There could be an indication on the empty thumbnail, that this is done on purpose for privacy reasons, explaining that they can grab a screenshot if it is safe.

Comment 8

[Justin Dolske [:Dolske]]

Attachment: Screenshot

I suppose it's worth noting that this is exactly twice as bad on OS X systems with a retina display (ie, twice the pixels). Attached is a screenshot from a window sized almost-but-not-quite full screen, where even normal-sized text in the thumbnails is quite readable on the screen.

Comment 9

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Attachment: Screenshot showing poor aesthetics and usability of the screenshots

I think the whole idea of using a thumbnail based of the page needs to be rethought. I'm not sure if a new bug needs to be file or what. Look at how horrible my own personal new tab page looks. If GMail is one of the user's most common websites, it seems totally counter to the original design intent to display it as a plain gray box.

Comment 13

[theshiftexchange]

Attachment: Screenshot showing "usability of the screenshots" is good enough for iPhone Google 2-factor barcode - try it yourself!

The comments that the screenshots are poor quality and do not allow leakage of sensitive data is wrong.

This thumbnail shows a screenshot that Firefox 18 took while creating a google 2-factor token. If you use an iPhone 5 - you will be able to read the barcode and have access to a throw-a-way google account.

Comment 14

[Morgan Borman]

Maybe the form data could be blurred/blacked out in the thumbnail.

Comment 15

[Behdad Esfahbod]

This is not limited to form data.  In my homescreen, my bank account numbers can be read if someone is willing to do it.  Each digit takes at least two pixels of width, so all someone needs to do is to render digits at the size the bank does, scale them down, and compare the pixels.

Comment 16

[Timvde]

Just a random thought: would it be an option for Firefox to sideload and render a page in the background without any cookies or other session information when creating a thumbnail? Although I guess in that case it obviously shouldn't trigger as often as now, since it is quite resource consuming.

Comment 17

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Tim from comment #16)
> Just a random thought: would it be an option for Firefox to sideload and
> render a page in the background without any cookies or other session
> information when creating a thumbnail? Although I guess in that case it
> obviously shouldn't trigger as often as now, since it is quite resource
> consuming.

Yes, we're thinking about that but more as a workaround for sites that send 'Cache-Control: no-store' headers and don't have thumbnails at all right now.

Comment 21

[Johnathan Nightingale [:johnath]]

Hey Drew/Brian - how do we feel about this now, post thumbnail service?

Comment 22

[Paul Silaghi, QA [:pauly]]

(In reply to Johnathan Nightingale [:johnath] from comment #21)
> Hey Drew/Brian - how do we feel about this now, post thumbnail service?
http://img96.imageshack.us/img96/5426/x2r6.png - IMHO, this is too sensitive info

Comment 23

[Mike Kaply [:mkaply]]

> http://img96.imageshack.us/img96/5426/x2r6.png - IMHO, this is too sensitive info

Are you serious? How can a public picture (you aren't logged in) be too sensitive of info?

Comment 24

[Paul Silaghi, QA [:pauly]]

(In reply to Mike Kaply (:mkaply) from comment #23)
> (you aren't logged in)
It's obvious I visited (many times so that is a top site) that profile when I was logged in before.

Comment 27

[SJ]

Just adding some more information to this on why this issue is occurring, chrome only captures the first thumbnail of the website which is usually the home page of the application without any login, the issue here is Firefox instead of capturing just the first page it is trying to capture all the pages in an application so resulting in this issue.

Comment 28

[:Gavin Sharp [email: [e-mail]]]

Bug 809051 has already mitigated this issue somewhat (we thumbnail less often). Bug 809056 will mitigate this further - we'll thumbnail fewer pages in general (only those that show up on about:newtab).

Comment 29

[:Gavin Sharp [email: [e-mail]]]

Given comment 28, I'm going to suggest that we've fixed as much as we're going to fix here. If there are specific cases where we're still thumbnailing sensitive information that can be addressed with a specific solution, new bugs are welcome.

Comment 30

[Matthew N. [:MattN]]

Mass-move to Firefox::New Tab Page.

Filter on new-tab-page-component.

Comment 32

[Dylan Cross]

As a potential solution, could you scan a page's html for any forms, and if a page contains a form, have some image processing that'll add a solid gray box over the form area? Any thoughts? I suppose the image detection to locate the form wouldn't be difficult to produce / locate an existing version. 

That would work for a wide variety of pages and cases, as you wouldn't need specific information about the page or purpose, or have to implement with changes to settings.

Comment 34

[Daniel Veditz [:dveditz]]

Does the fix for bug 1457929 make this better for people? We should be capturing the non-logged-in state (in most cases, exception in "see also" bug 1493596).

For other kinds of sensitive information (forgot to use Private Browsing, did you?) the new tab page gives a bunch of contols now. Mousing over the top right of the thumbnail in the "Top Sites" section you can

• "Dismiss" it from appearing on the page
• remove it from your history (so it can't be a top site)
• Edit it and change the shown image to something else. You don't need to make your own image: if you put in the URL of a page we'll take a screenshot of that other page and use that.

Can we call this "fixed"?

Comment 36

[Pablo]

Hi kate

We are checking on really old bugs that had old functionality and much has been changed in so many years.
per last comment, do you know if we can resolve this old issue?

please let us know
thanks.

Comment 37

[Ed Lee :Mardak]

With bug 1680531, top sites shows a letter instead of a thumbnail by default.