User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/125.2 (KHTML, like Gecko) Safari/125.8 Build Identifier: We must keep up with the competition (i.e. Safari). Therefore, I propose we implement one of the most useful features (in my opinion) that Safari 2.0 will offer. The "Private Browsing" feature does not store cache, history, or any personal information entered (on forms and the like). Is this one doable before they get to it? Reproducible: Always Steps to Reproduce: Try to browse privately... Actual Results: Cache, history, personal info was stored. Expected Results: Not store any of it. Is this doable before 1.0?

JHosh is working on a rewrite of the entire preference panes and is adding a ton of new features. It might be interesting to talk this over with Mike and Josh as I agree that this feature would be very usefull and fits within our goal.

the firefox guys have been kicking this idea around for about 3 years now. we should probably try to talk to them about it since most of the work is in the backend.

This bug dependent on bug 178944?

Taking of the unconfirmed list.

This seems highly similar to Firefox's Bug 248970. Irrespective of that though I thought "Private Browsing" would be pointless, I actually find this feature very useful in Safari 2.

One easy way to implement this is to create an encrypted disk image when the user activates PB mode and copy history, cookies, auto-complete list, download list, site permissions inside the encrypted disk image. When the user is done, we just delete the disk image and everything will be okay.

All the data will still be there unencrypted if Camino crashes. Also changing locations of many profile pieces while Camino is running is probably not easy.

One way to work around the crash problem is to use a helper application that will clean up after Camino if it happens to crash in PB mode. As for the file location problems, this might be less problematic with mozstorage (suppose to come with 1.8.1?) Overall, I think the developer should seriously consider this approach as it might prove to be much simpler than the two-tier approach proposed in the Fx bug.

*** Bug 327385 has been marked as a duplicate of this bug. ***

Safari's alert when turning on private browsing: "When private browsing is turned on, webpages are not added to the history, items are automatically removed from the Downloads window, information isn't saved for AutoFill (including names and passwords), and searches are not added to the pop-up menu in the Google search box. Until you close the window, you can still click the Back and Forward buttons to return to webpages you have opened." This seems eminently reasonable. We already don't save stuff for auto-fill (although when that gets improved -- see bug 319792 -- we'll need to make sure we do the right thing). Not adding to history seems simple enough, and auto-clearing downloads also seems pretty simple. I'm not sure how our search history works. Has the back end made any more progress on this? It seems to me like we could probably do all the above on our own right now, but if Core is working toward this, I see no reason to duplicate the effort. cl

If it's not (very) hard, I don't think you should wait for something in core... they probably have bigger fish to fry, unless someone volunteers anyway. Here's my proposal: let's investigate the tasks here (don't cache, clear downloads, etc etc) and find out which are really simple and which might need some Core work. If something specifically (like a flag, API etc.) is needed from core, we can file a bug and hope there's a simple fix.

*** Bug 356921 has been marked as a duplicate of this bug. ***

When we implement this, we should consider allowing private browsing to persist across sessions. Safari cancels private browsing whenever the user quits, and it must be re-enabled manually each time. That seems possibly annoying, as I imagine two general use cases for private browsing: 1) pr0n mode 2) People who check every single option in Firefox's "Clear Private Data on Quit" pref. Safari's behaviour is bad for use-case (2) and maybe only marginally good for use-case (1), depending on whether the user quits immediately after their, uh, "session". If they quit, Safari's behaviour saves them a step, but if they don't, it doesn't really matter, as they'd have to manually switch back to "normal" browsing anyway.

Even if the core support lands in time, this is very likely too large in scope for the time frame we need keep 2.0 to (although if someone shows up with a working patch, I'd be happy to be proven wrong ;)

Private browsing support in core is soon going to land. After that, supporting it in Camino would be easy. Bug 462832 even makes this easier by moving the private browsing service to core, so it would be a trivial UI-only patch for Camino.

Trivial except that it would also depend on us doing the substantial amount of work necessary to use Gecko 1.9.1 in light of the early removal of xpfe from core in 1.9.1.

Another design decision is whether we follow the Safari/Firefox "all or nothing" model or the Chrome per-window model; the latter is apparently possible on the Gecko platform, since https://addons.mozilla.org/en-US/firefox/addon/59736 purports to do that. (That said, though, bug 462832 never landed, so even once on 1.9.x it's going to be far less trivial than comment 17 suggested.)

(In reply to comment #20) > Another design decision is whether we follow the Safari/Firefox "all or > nothing" model or the Chrome per-window model; the latter is apparently > possible on the Gecko platform, since > https://addons.mozilla.org/en-US/firefox/addon/59736 purports to do that. Actually, that's not quite true. That extension uses a trick of launching another instance of Firefox in a new profile and activating private browsing mode in that profile. This is not optimal, because the new profile does not share any of the user data existing in the original profile. I do have some thought on improving the platform support so that we can implement the private browsing mode on a per-window basis in Firefox (and other Gecko-based applications), but at this time those are merely some thoughts. The implementation might not be trivial, but I probably need to dump my current thoughts in the form of a blog post or a wiki page at some point... > (That said, though, bug 462832 never landed, so even once on 1.9.x it's going > to be far less trivial than comment 17 suggested.) I do have a patch posted on that bug, but it's been rotted a long time ago and I never got to update it again. I have put it on my (long) todo list again, so that I would hopefully get to work on it again soon. In the meantime, if someone is eager to help with that, I would be glad to provide help on what needs to be done for that bug.