On 2015-01-22 4:44 PM, Steve Workman wrote:
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.
That sounds great!
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?
Yes, indeed. Also, I think discussing the exact implementation strategy without having pinned down the exact UX may be premature, and that is something that a prototype can help us with. All of my comments were about implementation issues for something that we can ship, not about prototype level quality. :-)
I look forward to see what you guys come up with! Cheers, Ehsan
On Thu, Jan 22, 2015 at 1:38 PM, Steve Workman <[email protected] <mailto:[email protected]>> wrote: On Thu, Jan 22, 2015 at 1:23 PM, Ehsan Akhgari <[email protected] <mailto:[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> <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 <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] <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
