Closed Bug 807449 Opened 12 years ago Closed 12 years ago

Incognito/Private-Browsing Tab Should not show up in Android's Recent Apps "Multitasking" popup after that tab has been closed.

Categories

(Firefox for Android Graveyard :: General, defect)

16 Branch
ARM
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: donrhummy, Assigned: bnicholson)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121024073032

Steps to reproduce:

This is a preemptive bug since I know Mozilla's working on the ability to do private browing in just a tab and this is an important part of what "private" means. Chrome makes the mistake of allowing the incognito window to be shown in the "multitasking" thumbnails, so I want Firefox to not make the same mistake.


Actual results:

Someone would be browsing privately and after leaving the app and clicking the "multitasking" button to get recent apps, they'd see a thumbnail showing their private browsing session.


Expected results:

Either:

1. Shows a thumbnail of a blank web page that says "Private" (This is the ideal situation, but may not be possible)

2. Doesn't show up at all (this is possible)
Blocks: pb
Showing a thumbnail in the app list is what I would have expected. What's the use case for the expected behavior you're describing? If someone else is using your phone, they could simply open the app to see the page. The only thing I can think of would be someone looking over your shoulder, but that would be a more common problem on desktops than phones - and in Windows, we don't obfuscate the thumbnail for the private session.
I think no matter the use case, private browsing thumbnails shouldn't be shown. That said, I believe it's considered extremely difficult to remove thumbnails. Perhaps though, what could be done, is that about:home is displayed on close, navigation away from and that replaces the thumbnail.
I'd like to echo Brian's question -- it's not clear to me what use case you are supporting by hiding private thumbnails in the tab menu, or why this was a mistake on Chrome's part. 

For example, blocking out thumbnails would make the "comparison shopping for engagement rings" use case a much more awkward experience on mobile, since it would be harder to tell which tab is which.  

If the concern is not easily being able to distinguish between normal and private tabs, we already have plans to separate the two in a visually distinct manner so that people know which ones are which. Mockup in progress > http://cl.ly/image/0e442x160G2G
Private Browsing should be about protecting user's privacy by not saving information that can show the user's browsing history *after* they're done.  I don't believe that this is a real problem, since if someone can access your device while you still have a private tab open, no amount of protection on our part is going to be enough!
Private Browsing is about protecting users' privacy. However how do you define privacy? What I consider private, may not be the same as yours and vice versa? Let's say that privacy to someone is protecting some work related activity they have to do at someone's house (let's say they're over for dinner and on-call) and that the website they've had to access through their friends tablet contains some incredibly sensitive data. The very point of privacy browser is to defend that a user can undertake any task within leaving a trail or evidence as to exactly what the device (be it laptop, tablet or smartphone) was doing. Should the user go about their task, finish and hand back the tablet, in no which way should the owner of the tablet be able to simply open up Recent Apps and get a glimpse of whatever it is that was viewed.

Or as an extension of the engagement ring scenario. Let's say that the groom to be is out with his girlfriend. He's received a text message that tells him the ring is back in stock and he needs to reserve it now. He tries to load it, but his battery dies, so he asks his girlfriend for the phone. She eagerly gives it to him because she's been suspecting for a while that he'd finally pop the question and she's thinking that he never asks to use her phone. Being the smart woman that she is, she's rocking an Android and so passes him the phone. He makes some room and flips into private browsing mode and secures the ring for his wife to be. He's now full of confidence because he knows everything is ready to fall into place. He clicks exit, passes back the phone and thinks to himself "this weekend, I'll make her the happiest woman alive". However being that she's exited and nosy, she clicks the Recent Apps button and surprise blown.

Or you have a friend that simply hasn't jumped onto the smartphone bandwagon yet. You're out for the night, and it's your job to keep the friend away from his house as his girlfriend is arranging a surprise party. She says she'll let you know when its a good time to bring him back. However because your friend hasn't jumped onto the smartphone bandwagon but apparently wants to die unless he can check his facebook, etc. You're letting him use your phone on occasion. And as such have told the girlfriend to DM you on facebook. You've made sure you've logged out of the facebook app to ensure the surprise isn't ruined and you're checking via the browser. However to make sure the secret is kept, you keep using Private Browsing and clicking exit. Because he's flipping back and forth via the Recent Apps button, you need to ensure the secret doesn't get out.

Or you have the almost-paranoid guy that has a fit every time anyone goes to facebook and leaves their cookies on his phone. However he's secured the date of his life but she's always wanting to use his phone to check her facebook she doesn't want to kill her battery. However she's really only looking for a guy to occupy her time in between seeing her secret celebrity boyfriend that no one can know about and so she can't let the secret out and lose him for she just couldn't go on.

Or there's porn and the parents that allow their kids to use their phones to play Agent Dash and Jetpack Joyride. The kid flipping between apps, really shouldn't be prompted to ask their parent "what's that?"
I'm sure people have different expectations about what private browsing provides, but that doesn't mean that those assumptions will be correct.  We should be explicit about what private browsing does and doesn't when you open a new private browsing tab, same way that we do on the desktop.

As I said, if you hand off your device to someone else without closing all of the open private tabs, all bets are off.
(In reply to Ehsan Akhgari [:ehsan] from comment #6)
> As I said, if you hand off your device to someone else without closing all
> of the open private tabs, all bets are off.

The problem is that if you exit from a PB tab, the thumbnail of the last used tab still shows in the recent tabs list. It's akin to using private browsing on a desktop device and when you click Windows Button + Tab it still shows a preview of the PB window/tab even though you've closed it.
(In reply to comment #7)
> (In reply to Ehsan Akhgari [:ehsan] from comment #6)
> > As I said, if you hand off your device to someone else without closing all
> > of the open private tabs, all bets are off.
> 
> The problem is that if you exit from a PB tab, the thumbnail of the last used
> tab still shows in the recent tabs list. It's akin to using private browsing on
> a desktop device and when you click Windows Button + Tab it still shows a
> preview of the PB window/tab even though you've closed it.

Oh, I see.  Yeah *that* is unacceptable.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Incognito/Private-Browsing Tab Should not show up in Android's Recent Apps "Multitasking" popup → Incognito/Private-Browsing Tab Should not show up in Android's Recent Apps "Multitasking" popup after that tab has been closed.
I doubt there's any way for us to delete the thumbnail only when Fennec is killed, so we'll likely have to prevent a thumbnail from being generated whenever the browser is in private browsing mode.
(In reply to comment #9)
> I doubt there's any way for us to delete the thumbnail only when Fennec is
> killed, so we'll likely have to prevent a thumbnail from being generated
> whenever the browser is in private browsing mode.

Makes sense.
tracking-fennec: --- → ?
OS: Linux → Android
Hardware: x86_64 → ARM
Given #comment9 can I propose the title is changed to "Prevent Private Browsing tabs from generating system level previews"?
Assignee: nobody → bnicholson
tracking-fennec: ? → 19+
Unfortunately, I've had enormous difficulty trying to get this working.

The first approach I tried, and the one that seems most obvious, is overriding onCreateThumbnail() [1] to simply return true. For whatever reason, though, this method doesn't appear to be called at all in ICS (see [2]), making it a dead end.

In same thread as [2], there's the suggestion to try using the FLAG_SECURE flag [3], which supposedly prevents screenshots for the window. Here's the behavior I've observed using this flag:

* When setting the flag (i.e., creating a private browsing tab), pushing the home button, and then opening the recent apps list, the thumbnail is still shown. But if Fennec is reopened, the home button is pressed again, and the recent apps list is then opened again, the thumbnail is black. As long as you're in a private browsing tab, it stays black for all subsequent openings of the recent apps list.
* When clearing the flag (i.e., switching back to a non-private browsing tab), pushing the home button, and then opening the recent apps list, the thumbnail is still black. But if Fennec is reopened, the home button is pressed again, and the recent apps list is then opened again, the thumbnail once again appears. As long as you're in a non-private browsing tab, the thumbnails is shown for all subsequent openings of the recent apps list.
* When setting this flag in onCreate(), it works the first time the recent apps list is opened. But this isn't terribly useful unless we always want to show a black thumbnail (for both private and non-private tabs).

Looking at [4], it appears the flag is only used when constructing a new Surface. I tried a number of hacks via reflection (like getting a reference to ViewRootImpl's surface [5] and calling setFlags() [6] on it), but to no avail. I've also tried hiding/obscuring the GeckoApp layout in onPause(), but apparently, the screenshot is taken right before the onPause() callback.

I'm out of ideas, and at this point, it looks like our options are to either 1) ignore this bug, 2) always show a black thumbnail, or 3) never show a Fennec thumbnail in the recent apps list (it doesn't appear possible to remove an app from the recent apps list at runtime). It's worth noting that both Chrome and the stock browser go with option #1 and always show thumbnails - even for private tabs.

[1] http://developer.android.com/reference/android/app/Activity.html#onCreateThumbnail%28android.graphics.Bitmap,%20android.graphics.Canvas%29
[2] http://code.google.com/p/android/issues/detail?id=29370
[3] http://developer.android.com/reference/android/view/WindowManager.LayoutParams.html#FLAG_SECURE
[4] http://androidxref.com/4.0.4/xref/frameworks/base/services/java/com/android/server/wm/WindowState.java#668
[5] http://androidxref.com/4.0.4/xref/frameworks/base/core/java/android/view/ViewRootImpl.java#228
[6] http://androidxref.com/4.0.4/xref/frameworks/base/core/java/android/view/Surface.java#485
If anyone else wants to give this a go, here's a simple patch that tries to use onCreateThumbnail() and FLAG_SECURE as described above.
Have you looked into what chromium does here?
(In reply to Ehsan Akhgari [:ehsan] from comment #14)
> Have you looked into what chromium does here?

Stock and Chrome do not attempt to hide the thumbanil
Hmm.  How bad would it be for us to go with the black screen approach?
I wouldn't recommend it. It would make Fennec look broken. Would it be impossible to create a blank screen and then invoke the onPause() callback? Can we file a bug on Android to try and get them to put some work in on their end so that FLAG_SECURE and onCreateThumbnail() work as expected? Or possibly post the patch ourselves? Either way, it would seem that fixing this is dependent on an OS level bug.
(In reply to Paul [sabret00the] from comment #17)
> I wouldn't recommend it. It would make Fennec look broken. Would it be
> impossible to create a blank screen and then invoke the onPause() callback?

I've already tried that (see second to last paragraph in comment 12).

> Can we file a bug on Android to try and get them to put some work in on
> their end so that FLAG_SECURE and onCreateThumbnail() work as expected? Or
> possibly post the patch ourselves? Either way, it would seem that fixing
> this is dependent on an OS level bug.

There's already a bug filed for onCreateThumbnail() (http://code.google.com/p/android/issues/detail?id=29370). Even if it's fixed, though, we still support devices as far back as Froyo, so bugs fixed in future Android versions are only of limited help.
(In reply to Brian Nicholson (:bnicholson) from comment #18)
> There's already a bug filed for onCreateThumbnail()
> (http://code.google.com/p/android/issues/detail?id=29370). Even if it's
> fixed, though, we still support devices as far back as Froyo, so bugs fixed
> in future Android versions are only of limited help.

Perhaps, but better to have a forward facing solution than no solution at all.
I haven't had any luck with this, so renom'ing in case this is still worth any effort.
tracking-fennec: 19+ → ?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
tracking-fennec: ? → ---
I'm still seeing this behavior (pull down menu media item persists after Private Browsing tab has been closed) and it flies in the face of what "private browsing" purports to offer - e.g. "Browse without a trace". (This issue also affects standard browsing, which is annoying, but there aren't necessarily as many privacy concerns in that scenario.)

Here's a contrived example which highlights the unexpected behavior and why it could be undesirable: 
- Alice borrow Bob's phone and listens to a politically sensitive podcast 
- Alice closes the Private Browsing tab (prior to pausing/stopping the media item) and hands the phone back to Bob 
- By pulling down the quick settings/app activity menu, Bob can see that Alice was listening to a podcast called "Calexit Now"
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: