Hi Ehsan, There are a couple of use cases that we've talked about here. Elaborating on those might help us determine some goals. (Francois and co. can jump in and correct me here if I've missed something).
1. Being able to login to the same site using different logins, in separate private sessions. E.g. You're a user that always opens Twitter in a private browsing window - you don't want any twitter history or data stored locally; you have two accounts, one for personal and one for work and you want to be logged in to both at the same time. Goal - Be able to have separate login sessions for the same service opened at the same time in private browsing. 2. You're a developer that wants a few disposable sessions for your site. You want to verify some dynamic/adaptive capabilities of your website in different sessions at the same time. Goal - Be able to have separate, disposable sessions for the same site open at the same time. On AppID, we've talked about using it to prototype this quickly; assuming that it meets agreed goals, we'd still need to adjust how that's done to incorporate Apps and contained sessions, possibly allow it to be extensible. But in general, it seems like it's a similar mechanism to how private browsing works. At least in Necko, there's a 'P' added to the hashkey of connections and cache entries to signal that the resource should be isolated in private browsing. We're suggesting that AppID's successor and that 'P' suffix could be added together to give unique private browsing sessions. It would be great to know what you think of the goals and the mechanism and if there's anything else we need to consider here. Thanks, Steve On Wed, Jan 21, 2015 at 10:14 AM, Ehsan Akhgari <[email protected]> wrote: > Hi Francois! > > (I mostly looked at the private session wiki page, FWIW.) > > When you're talking about isolation, what exact things do you want to > isolate from? Is it just the appId based cookie jars which give you > isolation across some storage mechanisms? Or are you trying to achieve > more than that? I prefer us to first agree on what goals we would like to > achieve irrespective of the existing appId based isolation, to make sure > that the implementation doesn't guide our design. > > Cheers, > Ehsan > > > On 2015-01-20 11:16 PM, Francois Marier wrote: > >> A few of us have been thinking about how to let users manage their >> multiple online identities in Firefox, as well as how to isolate sites >> from one another. Our goal is to find tools we can offer to >> privacy-conscious Firefox users. >> >> Containers [1] was the first idea that Bram and I came up with. It's a >> lightweight way to keep sessions (i.e. cookies, local storage, etc.) >> separate. A single person could have more than one container in their >> browser. >> >> User profiles [2] is a set of ideas that Bram and Ryan Feeley had about >> how to expose (and extend) the existing browser profile functionality to >> users. Multiple people who share the same browser (e.g. a family) could >> use this more heavyweight separation to keep their sessions, history and >> bookmarks separate. >> >> Finally, we also brainstormed a few ideas around private sessions [3] to >> address a few use cases around session isolation without interfering >> with the existing purpose/goals of private browsing. >> >> None of this is final (or even scheduled to be implemented at this >> point), we're just exploring a few ideas and welcome any feedback. >> >> Francois >> >> [1] https://wiki.mozilla.org/Security/Contextual_Identity_ >> Project/Containers >> [2] >> https://wiki.mozilla.org/Security/Contextual_Identity_ >> Project/User_Profiles >> [3] >> https://wiki.mozilla.org/Security/Contextual_Identity_ >> Project/Private_Session >> _______________________________________________ >> dev-privacy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-privacy >> >> > _______________________________________________ > dev-privacy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-privacy > _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
