Please use "Edit with form" above to edit this page.
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- right now private browsing is all or nothing
- want to enable concurrent private browsing so info does not leak between normal & private sessions
- down side is the global state is lost, there is no global 'private browsing' flag in the new implementation
- you can't keep your windows from before entering private browsing when entering private browsing (for example, watching a video), since entering private browsing mode closes existing windows/tabs and reopens them on exit in the current implementation
- all windows share the same private browsing session (2 different private windows are not in separate sessions). Which is the same as what we have now, but perhaps less understood by the user
What solutions/approaches were considered other than the proposed solution?
- looked at separate profiles, but that did not use existing profile so that things like add-ons and browsing history would disappear in private windows
**ian, I assume it means people in private mode still like to use their saved bookmarks and awesomebar history search, etc.
- also looked at e10s but that project stalled
Why was this solution chosen?
- This solution maintains the users profile and allows a session to enter private mode
- This solution allows entering private browsing mode for one window while maintaining existing windows in non-private browsing mode
Any security threats already considered in the design and why?
- feature does not interact with web content
- Other than allowing private/non-private at the same time functionality remains the same
- they would need a window reference, and shouldn't be able to get one
- There is no way for the non-private window to get a reference to the non-private window.
- or more likely: two separate pages, one private, both with a Facebook like button. What cookies does FB get for both?
- The cookies associated with the private/non-private cookie store. Each has separate cookies.
- Is their a boundary for the postmessage API? postmessage from Private browsing shoudn't access non-private browsing. Again here they would need a window reference, which they don't have.
- Unless an addon mixes window references? without understanding the implications. frames within private windows inherit privateness. what about a background window (a document that is not visible)? going to inherit private/non-private flag of its parent docshell
- session restore should not save private tabs
- could discourage people from restarting Firefox (e.g. upgrading)
- explicit restarts should perhaps be treated differently than shutdowns. do we want private browsing session to survive an explicit restart? No - what if firefox crashes on the restart, and then the data will persist on disk. We could just add a warning that the private windows will be lost after restart.
- There will be a visual distinction between private windows and non-private windows.
- dragging tabs between private and non-private windows - need to handle this case
- How do plugins work? Some (flash) now support private mode, but it's probably global when we initialize them.
- bug 722942 covers addressing this
- Does XHR get the right load context for cookies?
- Do workers get the right load context for cookies?
- dunno -- see action items
- will the new download panel show downloads only for the current window or globally? If global then PB will have to do some more work.
- bug 722859 covers the download manager change, and bug 564934 covers the new download manager
|Action Item Status
|Who||Action||By When||Completed date
|jdm ehsan |bug 740832 bug 729706 |Do workers get the right load context for cookies?||before code migrates to aurora||[DONE] 2012.03.10