Closed Bug 762938 Opened 13 years ago Closed 13 years ago

Decide about new tab page interaction in private browsing mode

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: ttaubert, Unassigned)

References

Details

When implementing the new tab page we didn't really spec out how new tab pages should behave in private browsing mode. There are a couple of options I have in mind: 1) We can show about:newtab with a separate storage for PB mode. So the user would be able to add/move/remove links on the page but all these modifications are lost when leaving PB. 2) We can show about:newtab, hide the pin/remove buttons and disabled drag-and-drop. This way we'd have a static version of the newtab page to provide the user with their links. 3) We can maybe just show about:blank which doesn't sound like the best option. 4) We can always show about:privatebrowsing when opening a new tab which is similar to what Chrome does. This would also remove surprises for users such as bug 762438. Also somewhat related to bug 748530. I'd personally favor [4]. [2] would probably also be acceptable as a fallback. All other options don't really make sense to me but it's a UX decision after all.
No longer blocks: 722990
Blocks: 722990
3 or 4 should be our immediate solution. I'm leaning towards 4.
4 is fine with me as well.
The new tab URL is configurable. If a user wants a page with a search bar when opening a new tab (didn't we have plans for merging about:home and about:newtab?), disabling this functionality during private browsing makes even less sense. I'm not sure I understand 2. What private data is leaked by pinning and removing thumbnails?
(In reply to Dão Gottwald [:dao] from comment #3) > The new tab URL is configurable. If a user wants a page with a search bar > when opening a new tab (didn't we have plans for merging about:home and > about:newtab?), disabling this functionality during private browsing makes > even less sense. We could introduce a pref that specifies the new tab url for PB mode but I'm not sure we really need or want that. I don't know about the current state of the about:home/newtab merge but in my opinion it makes sense to even then display about:privatebrowsing when opening a new tab. > I'm not sure I understand 2. What private data is leaked by pinning and > removing thumbnails? There's no private data leak. A configurable newtab page doesn't seem useful to me if all modifications are lost when exiting. That's the current behavior and probably no one expects that.
(In reply to Tim Taubert [:ttaubert] from comment #4) > (In reply to Dão Gottwald [:dao] from comment #3) > > The new tab URL is configurable. If a user wants a page with a search bar > > when opening a new tab (didn't we have plans for merging about:home and > > about:newtab?), disabling this functionality during private browsing makes > > even less sense. > > We could introduce a pref that specifies the new tab url for PB mode but I'm > not sure we really need or want that. I don't know about the current state > of the about:home/newtab merge but in my opinion it makes sense to even then > display about:privatebrowsing when opening a new tab. When people expect certain useful things when opening a new tab, hiding them complicates their work flow. So I don't think it makes much sense.
(In reply to Tim Taubert [:ttaubert] from comment #4) > There's no private data leak. A configurable newtab page doesn't seem useful > to me if all modifications are lost when exiting. That's the current > behavior and probably no one expects that. Why can't we persist that data?
We can, we currently just don't do it. The only danger I see here is that one might drag a "private" link onto the new tab page. Probably very low-risk and rather expected behavior. This doesn't help at all with telling the user that they're now in private browsing mode but maybe the new tab page isn't the right place to do that anyway.
(In reply to Ehsan Akhgari [:ehsan] from comment #6) > (In reply to Tim Taubert [:ttaubert] from comment #4) > > There's no private data leak. A configurable newtab page doesn't seem useful > > to me if all modifications are lost when exiting. That's the current > > behavior and probably no one expects that. > > Why can't we persist that data? Not storing my activity during private browsing is kind of fundamental to private browsing. Imagine I'm in that mode doing some research for a surprise 10th anniversary vacation with my wife. I figure I'm going to save myself some time and pin a few hawaii travel pages so I can quickly get back to them. Later on my wife picks up the laptop, goes to do some porn browsing, and sees all my surprise vacation plans. That's not cool.
(In reply to Tim Taubert [:ttaubert] from comment #7) > We can, we currently just don't do it. The only danger I see here is that > one might drag a "private" link onto the new tab page. Probably very > low-risk and rather expected behavior. This doesn't help at all with telling > the user that they're now in private browsing mode but maybe the new tab > page isn't the right place to do that anyway. Then we should change the existing behavior. Dragging a new link to the home page is an explicit action, same as bookmarking a link, and should be allowed in PB mode.
(In reply to Asa Dotzler [:asa] from comment #8) > (In reply to Ehsan Akhgari [:ehsan] from comment #6) > > (In reply to Tim Taubert [:ttaubert] from comment #4) > > > There's no private data leak. A configurable newtab page doesn't seem useful > > > to me if all modifications are lost when exiting. That's the current > > > behavior and probably no one expects that. > > > > Why can't we persist that data? > > Not storing my activity during private browsing is kind of fundamental to > private browsing. > > Imagine I'm in that mode doing some research for a surprise 10th anniversary > vacation with my wife. I figure I'm going to save myself some time and pin a > few hawaii travel pages so I can quickly get back to them. Later on my wife > picks up the laptop, goes to do some porn browsing, and sees all my surprise > vacation plans. That's not cool. There's a fine line between disallowing what the user explicitly asks for, and respect their privacy. What we've chosen to do in the past is to not store data that is collected implicitly as the user browses around (such as history) but allow data which the user explicitly asks us to store (such as bookmarks) to be stored.
(In reply to Ehsan Akhgari [:ehsan] from comment #10) > (In reply to Asa Dotzler [:asa] from comment #8) > > (In reply to Ehsan Akhgari [:ehsan] from comment #6) > > > (In reply to Tim Taubert [:ttaubert] from comment #4) > > > > There's no private data leak. A configurable newtab page doesn't seem useful > > > > to me if all modifications are lost when exiting. That's the current > > > > behavior and probably no one expects that. > > > > > > Why can't we persist that data? > > > > Not storing my activity during private browsing is kind of fundamental to > > private browsing. > > > > Imagine I'm in that mode doing some research for a surprise 10th anniversary > > vacation with my wife. I figure I'm going to save myself some time and pin a > > few hawaii travel pages so I can quickly get back to them. Later on my wife > > picks up the laptop, goes to do some porn browsing, and sees all my surprise > > vacation plans. That's not cool. > > There's a fine line between disallowing what the user explicitly asks for, > and respect their privacy. What we've chosen to do in the past is to not > store data that is collected implicitly as the user browses around (such as > history) but allow data which the user explicitly asks us to store (such as > bookmarks) to be stored. I think this is the wrong behavior. Most users are not going to assume that some things will be deleted at the end of the session and other things are going to be preserved. Typing a URL is explicit, and we don't save that. Creating and using a login is explicit, I hope we don't save that.
(In reply to Asa Dotzler [:asa] from comment #11) > (In reply to Ehsan Akhgari [:ehsan] from comment #10) > > (In reply to Asa Dotzler [:asa] from comment #8) > > > (In reply to Ehsan Akhgari [:ehsan] from comment #6) > > > > (In reply to Tim Taubert [:ttaubert] from comment #4) > > > > > There's no private data leak. A configurable newtab page doesn't seem useful > > > > > to me if all modifications are lost when exiting. That's the current > > > > > behavior and probably no one expects that. > > > > > > > > Why can't we persist that data? > > > > > > Not storing my activity during private browsing is kind of fundamental to > > > private browsing. > > > > > > Imagine I'm in that mode doing some research for a surprise 10th anniversary > > > vacation with my wife. I figure I'm going to save myself some time and pin a > > > few hawaii travel pages so I can quickly get back to them. Later on my wife > > > picks up the laptop, goes to do some porn browsing, and sees all my surprise > > > vacation plans. That's not cool. > > > > There's a fine line between disallowing what the user explicitly asks for, > > and respect their privacy. What we've chosen to do in the past is to not > > store data that is collected implicitly as the user browses around (such as > > history) but allow data which the user explicitly asks us to store (such as > > bookmarks) to be stored. > > I think this is the wrong behavior. Most users are not going to assume that > some things will be deleted at the end of the session and other things are > going to be preserved. Typing a URL is explicit, and we don't save that. > Creating and using a login is explicit, I hope we don't save that. Well, like I said there's a fine line. We clearly message the users in about:privatebrowsing on what is protected in this mode and what is not. While I'm open to discuss the change in behavior, I don't think this bug is the place to do it.
tl;dr: Let's show about:privatebrowsing in PBM on new tabs. If a user has configured a custom New Tab Page, let's continue to show that custom page in PBM. Explanation: What we should strive for here is consistency with user's expectations of private browsing mode with Firefox's current behavior. Ehsan and Asa have pretty much nailed the challenge here: are thumbnails in New Tab page explicitly created data like Bookmarks, such that users should be able to create and retrieve them in PBM? Or, are they more implicitly created like history, where they should not persist after PBM? I argue that we should steer on the safe side and not allow users to create a pinned thumbnail in PBM that would persist outside it. This is because it's not very obvious that doing so this creates an object like a bookmark. Bookmarking is explicit - users see the folder and category and the action of creating bookmarks is well understood. Sliding an object or pinning a tab into New Tab Page is less clear - and users unexpectedly seeing a site moved there during PBM in normal mode or a new PBM session could be calamitous. However, it also wouldn't work to have a New Tab Page in PBM where non-private thumbnails are displayed but the user couldn't pin anything. This partially functional state would put the user in an inconsistent mode where New Tab appears on sight to be normal, but then some operations don't work. So, that leaves us with: - 3 about:blank - 4 about:privatebrowsing - 5 A New Tab that's fresh for every PBM and deleted after it 5 Is the most visually consistent within Firefox, but for people who know how to use New Tab Page, the fact that they're create essentially bookmarks that will disappear will cause mode problems. 3 doesn't cause misconceptions, but it also not very useful. 4, on the other hand, gives us the benefit of actually reminding users they're in PBM and, in a sense, providing that explanation of why the normal NTB isn't there.
Saurabh, please see comment 13. Let me know if you're interested to implement this.
Ehsan, I would love to work on fixing this bug.
Depends on: 763468
We'll implement comment #13 in bug 763468.
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: uiwanted
Resolution: --- → FIXED
I can see that this bug is marked as fixed. I'd like to add a comment though as I hope to get some feedback. For your information: my use case is that I use private browsing rather often for everyday browsing to avoid cookies & cluttered history (not knowing if this is a common use case). The about:pb page on every new tab draws lots of attention to it, which includes bystanders, which is bugging (me) in some way I guess. Furthermore, I can not imagine that users will actually read the given information more than once. Considering that there have been quite a few bugs about reducing general visual complexity/noise, I can not really understand the decision here. I can imagine that just disabling about:newtab (as with browser.newtabpage.enabled=false) and instead showing a notice about the effects of re-enabling it in PB mode would be nice. The user could enable it for the session or permanently (which could even be combined with bug 748530, which I filed, and was mentioned in comment #0 already). Alternatively, adding a new very light version of about:pb for new tabs would at least reduce attention/noise. Thanks for reading ;)
Are you using the always-on private browsing mode? (Go to Preferences, Privacy, and see if "Never remember history" is selected). If yes, that's something that we need to fix, it doesn't make a lot of sense to show about:privatebrowsing in that mode.
(In reply to Ehsan Akhgari [:ehsan] from comment #18) No, I am really just "complaining" because I use private browsing rather often for everyday browsing and I don't like this new solution for the stated reasons.
It turned out that what I suspected in comment 18 is indeed a bug, see bug 767835. For everyday browsing, I'd suggest you change the newtab URL pref, since your use case is not something that a lot of people share... Thanks! :-)
(In reply to Ehsan Akhgari [:ehsan] from comment #20) > For everyday browsing, I'd suggest you change the newtab URL pref, since > your use case is not something that a lot of people share... Ok, I only just found out I might set it to about:newtab# or something similar, as it needs to be different from the default...
You need to log in before you can comment on or make changes to this bug.