canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776
edits
Security/Reviews/PerWindowPrivateBrowsing: Difference between revisions
Security/Reviews/PerWindowPrivateBrowsing (view source)
Revision as of 22:06, 22 February 2012
, 22 February 2012no edit summary
No edit summary |
No edit summary |
||
| Line 14: | Line 14: | ||
* also looked at e10s but that project stalled | * also looked at e10s but that project stalled | ||
|SecReview solution chosen=* This solution maintains the users profile and allows a session to enter private mode | |SecReview 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 | * This solution allows entering private browsing mode for one window while maintaining existing windows in non-private browsing mode | ||
|SecReview threats considered=* feature does not interact with web content | |SecReview threats considered=* feature does not interact with web content | ||
* Other than allowing private/non-private at the same time functionality remains the same | * Other than allowing private/non-private at the same time functionality remains the same | ||
|SecReview threat brainstorming=* Assume we have two tabs (one private, one non-private) on the same domain. Can javascript running on one page affect the other? | |||
** 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? | |||
** it should | |||
* 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 | |||
}} | }} | ||
{{SecReviewActionStatus | {{SecReviewActionStatus | ||
|SecReview action item status=None | |SecReview action item status=None | ||
|Feature version=Firefox 13+ | |Feature version=Firefox 13+ | ||
|SecReview action items=<table border="1"> | |||
<tr> | |||
<td>Who</td><td>Action</td><td>By When</td><td>Completed date</td> | |||
</tr> | |||
<tr><td>jdm ehsan </td><td>Do workers get the right load context for cookies?</td><td>before code migrates to aurora</td><td>{{new|new}}</td> | |||
</tr> | |||
</table> | |||
}} | }} | ||