On 2015-01-22 4:38 PM, Steve Workman 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.
As a prototype, yes, for sure! (I assume by feedback here you're mostly
talking about UX level 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.
Oh, I didn't mean putting up the profile manager dialog and get people
to create their own profiles. I meant doing that programmatically and
open up a window running in that profile. (Note that running concurrent
Firefox profiles has a few issues as well.)
- 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.
Indeed. It really depends on the exact UX that we're trying to achieve.
But for the purpose of building a prototype I'd pick the easiest
approach to implement.
- a new Firefox process is started per profile
Why is this a bad thing?
Increased memory usage.
That is not a given. Depending on your profile, running a separate
instance of Firefox without the cruft in your main profile may result in
lower memory usage.
_______________________________________________
dev-privacy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-privacy
