Last Comment Bug 755996 - [New Tab Page] shows sensitive information in the thumbnails
: [New Tab Page] shows sensitive information in the thumbnails
Status: NEW
[follow-up to bug 754608, which morph...
: csectype-disclosure, privacy, sec-low
Product: Firefox
Classification: Client Software
Component: New Tab Page (show other bugs)
: 13 Branch
: All All
: -- major with 7 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 725189 823188 838646 845800 860138 895512 909507 930830 (view as bug list)
Depends on: 1093183 754608 822516 822867 1088203
Blocks: 455553
  Show dependency treegraph
 
Reported: 2012-05-16 21:01 PDT by Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
Modified: 2015-03-19 08:22 PDT (History)
48 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot (587.03 KB, image/png)
2012-10-10 19:56 PDT, Justin Dolske [:Dolske]
no flags Details
Screenshot showing poor aesthetics and usability of the screenshots (471.76 KB, image/png)
2012-10-14 22:14 PDT, Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
no flags Details
Screenshot showing "usability of the screenshots" is good enough for iPhone Google 2-factor barcode - try it yourself! (27.29 KB, image/png)
2013-02-07 04:11 PST, theshiftexchange
no flags Details

Description Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-05-16 21:01:06 PDT
+++ 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 gavin@gavinsharp.com 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 2012-06-05 21:07:50 PDT
> > 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 2 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2012-06-07 09:31:37 PDT
*** Bug 762438 has been marked as a duplicate of this bug. ***
Comment 3 Mike Kaply [:mkaply] 2012-07-25 09:18:15 PDT
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 2012-08-01 15:53:56 PDT
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] 2012-08-16 11:38:56 PDT
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 6 Marco Castelluccio [:marco] 2012-08-16 11:40:03 PDT
*** Bug 725189 has been marked as a duplicate of this bug. ***
Comment 7 coinman 2012-10-09 05:57:51 PDT
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] 2012-10-10 19:56:47 PDT
Created attachment 670225 [details]
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?) 2012-10-14 22:14:14 PDT
Created attachment 671319 [details]
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 10 Mardeg 2012-12-19 12:27:44 PST
*** Bug 823188 has been marked as a duplicate of this bug. ***
Comment 11 Mardeg 2013-01-20 03:30:58 PST
*** Bug 832738 has been marked as a duplicate of this bug. ***
Comment 12 Daniel Veditz [:dveditz] 2013-02-06 10:43:13 PST
*** Bug 838646 has been marked as a duplicate of this bug. ***
Comment 13 theshiftexchange 2013-02-07 04:11:48 PST
Created attachment 711257 [details]
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 2013-02-07 06:38:19 PST
Maybe the form data could be blurred/blacked out in the thumbnail.
Comment 15 Behdad Esfahbod 2013-02-07 12:01:02 PST
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 2013-02-08 09:44:22 PST
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] 2013-02-08 09:53:54 PST
(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 18 Matthias Versen [:Matti] 2013-02-27 15:16:56 PST
*** Bug 845800 has been marked as a duplicate of this bug. ***
Comment 19 :Gavin Sharp [email: gavin@gavinsharp.com] 2013-04-16 11:51:13 PDT
*** Bug 860138 has been marked as a duplicate of this bug. ***
Comment 20 Drew Willcoxon :adw 2013-08-28 20:05:48 PDT
*** Bug 909507 has been marked as a duplicate of this bug. ***
Comment 21 Johnathan Nightingale [:johnath] 2013-09-03 07:29:00 PDT
Hey Drew/Brian - how do we feel about this now, post thumbnail service?
Comment 22 Paul Silaghi, QA [:pauly] 2013-09-04 07:21:03 PDT
(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] 2013-09-04 08:06:03 PDT
> 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] 2013-09-04 08:16:47 PDT
(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 25 XtC4UaLL [:xtc4uall] 2013-10-04 17:16:43 PDT
*** Bug 895512 has been marked as a duplicate of this bug. ***
Comment 26 Bob Clary [:bc:] 2013-10-25 04:40:54 PDT
*** Bug 930830 has been marked as a duplicate of this bug. ***
Comment 27 SJ 2013-10-27 19:27:43 PDT
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: gavin@gavinsharp.com] 2013-11-01 14:20:27 PDT
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: gavin@gavinsharp.com] 2014-02-03 18:25:39 PST
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] 2014-05-20 22:28:29 PDT
Mass-move to Firefox::New Tab Page.

Filter on new-tab-page-component.
Comment 31 Daniel Veditz [:dveditz] 2014-11-03 10:40:45 PST
*** Bug 1093183 has been marked as a duplicate of this bug. ***
Comment 32 Dylan Cross 2014-11-03 13:45:55 PST
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.

Note You need to log in before you can comment on or make changes to this bug.