On Wed, Jan 21, 2015 at 11:17 AM, Ehsan Akhgari <[email protected]> wrote:
> On 2015-01-21 2:02 PM, Steve Workman wrote: > >> 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. >> > > For this use case, I think a solution based on appId should be fairly > sufficient. The most critical thing here is cookie separation, which you > get through appId. There may be some corner cases, such as a single URI > being served differently based on the login, but that should be extremely > rare. > > There are other issues here though, which are not easily fixable with an > implementation based on private browsing. For example, you may want your > two sessions autocomplete different username/passwords for Twitter. Or, > you may want a bookmark to <https://twitter.com/i/notifications> always > open in your home session. Or you may want to have two different copies of > that bookmark, each opening in its own session. None of these things can > be easily implemented on top of the existing private browsing. Have we > thought about these cases? > Yes :) https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers We're currently doing some user research to figure out how we might do this best. > > FWIW this is probably the #1 use case people (ab)use private browsing for, > so it's great to have this finally handled. :-) > > 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. >> > > I think this use case is pretty far away from both what private browsing > and appId isolation provide. Having an actual separate profile will > probably work best for this, but there are some issues to figure out here > too. For example, how to open links from external apps, or how to choose > to discard a profile, or what to do with the customizations in the user's > main profile (things such as customized prefs, add-ons, etc.) > Is there any reason we'd want these separate sessions to not write > anything to the disk? > A separare profile would be best yes, but being able to quickly open up an isolated, disposable, fresh session could be useful for developers. Re not writing anything to disk, I think I need a clarification here: I thought private browsing wrote to disk but then deleted everything once the session was complete? Either way, having the session automatically deleted is the benefit here. > > 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. >> > > For Necko, an appId based solution will give you most of what you want, > but there are issues to figure out. For example, I think right now we use > the in-memory cache for content loaded in private windows, and that cache > is shared across all of your private windows. Another example, our cookie > viewer UI can only deal with non-private appId=0 cookies. > Yes, definitely some work to be done here. Hopefully it's good enough for a prototype. > > But please note that there are a lot of other places outside of Necko that > are also aware of private browsing. > Can you give us a list of the places you're aware of? > > Cheers, > Ehsan > > 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] >> <mailto:[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 >> <https://wiki.mozilla.org/Security/Contextual_Identity_ >> Project/Containers> >> [2] >> https://wiki.mozilla.org/__Security/Contextual_Identity__ >> _Project/User_Profiles >> <https://wiki.mozilla.org/Security/Contextual_Identity_ >> Project/User_Profiles> >> [3] >> https://wiki.mozilla.org/__Security/Contextual_Identity__ >> _Project/Private_Session >> <https://wiki.mozilla.org/Security/Contextual_Identity_ >> Project/Private_Session> >> _________________________________________________ >> dev-privacy mailing list >> [email protected] <mailto:dev-privacy@lists. >> mozilla.org> >> https://lists.mozilla.org/__listinfo/dev-privacy >> <https://lists.mozilla.org/listinfo/dev-privacy> >> >> >> _________________________________________________ >> dev-privacy mailing list >> [email protected] <mailto:[email protected]> >> https://lists.mozilla.org/__listinfo/dev-privacy >> <https://lists.mozilla.org/listinfo/dev-privacy> >> >> >> > _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
