It seems like those issues are mostly to do with the second use case I mentioned, i.e. lightweight, disposable sessions for web developers. Perhaps we should put that to the side and concentrate on use case 1, i.e. isolated PB sesssions for different logins. We can start with that and come back to the developer use case after.
Ehsan, from your feedback, it seems like we could proceed with a prototype here - I don't think I'm reading anything about impossible blockers, right? On Thu, Jan 22, 2015 at 1:38 PM, Steve Workman <[email protected]> wrote: > On Thu, Jan 22, 2015 at 1:23 PM, Ehsan Akhgari <[email protected]> > wrote: > >> On 2015-01-21 8:20 PM, Francois Marier wrote: >> >>> On 22/01/15 13:20, Ehsan Akhgari wrote: >>> >>>> On 2015-01-21 2:27 PM, Steve Workman wrote: >>>> >>>>> https://wiki.mozilla.org/Security/Contextual_Identity_ >>>>> Project/Containers >>>>> <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. >>>>> >>>> >>>> Obviously there is a ton of UX level stuff that we need to figure out, >>>> and I think that wiki page does a good job discussing them. But it's >>>> also discussing appId here, which confuses me. What do containers and >>>> appId have to do with each other? Based on reading the UX proposal >>>> there, my intuition is that this feature will be implemented on top of >>>> separate profiles, perhaps that's not what was intended? >>>> >>> >>> Containers would be implemented on top of appId (or a similar mechanism) >>> so that it's lightweight and that things like bookmarks and history are >>> shared. >>> >> >> It does make the implementation a lot more challenging, since I suspect >> very strongly that the existing appId support will not be enough. >> > > ... but a good start and good enough for a prototype to get feedback. > >> >> User profiles would be a revamped version of browser profiles: >>> >>> >>> https://wiki.mozilla.org/Security/Contextual_Identity_ >>> Project/User_Profiles >>> >>> A separare profile would be best yes, but being able to quickly open up >>>>> an isolated, disposable, fresh session could be useful for developers. >>>>> >>>> >>>> I completely agree, but that doesn't preclude the usage of a new >>>> profile, right? >>>> >>> >>> The perceived disadvantages of using a different profile in this case >>> were: >>> >>> - you need to create a profile on disk, just to trash it later >>> >> >> Why is that a bad thing? Profile creation should not be very expensive... >> > > But you still have to go through the steps of creating a new profile. A > contained window would be fewer clicks. Unless, of course, we had a single > click option for a disposable profile. > >> >> - you can't share history and bookmarks >>> >> >> You could fix this though by copying the places db into the new profile, >> right? (The problem would be much harder to handle if we wanted to retain >> other kinds of customizations and not just history and bookmarks... Do we?) >> > > You could, but then you'd have the issue of keeping them sync'd. > >> >> - a new Firefox process is started per profile >>> >> >> Why is this a bad thing? > > > Increased memory usage. > >> >> >> _______________________________________________ >> 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
