info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Isolating sites from one another and dealing with multiple online identities
120 views
Skip to first unread message
Francois Marier
Jan 20, 2015, 11:16:47 PM1/20/15
to
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
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
Bram Pitoyo
Jan 20, 2015, 11:59:11 PM1/20/15
to
Our users care about getting things done, saving time, having fun, communicating with the world and staying in touch with their loved ones. Mozilla cares about privacy and security. How can our focus align with their concerns?
Everybody wants to be safe, but they feel helpless that the steps to get to safety is often hard, overwhelming and confusing - involving case-by-case memorisation and ad hoc tactics. Today, we're exploring three ideas that allow users to accomplish their tasks faster, in a way that's more secure and privacy-aware than ever.
User Profiles
When users want to share their computer/browser with other people (permanently or temporarily), they shouldn't worry about "mother-in-law snooping".
Containers
When users want to use many accounts for the same websites - professional/personal emails, multiple Twitter usernames, separate eBay buyer/seller - they shouldn't need to sign out or use another browser. When users open a sensitive site - banking, government services - they should be protected against potential attacks (e.g. cross-site request forgery).
Private Session
When users want to browse privately, the sites they open in secret shouldn't know about the other sites they open in secret.
The wiki has descriptions and mockups of each idea. We're looking forward to your contribution!
Everybody wants to be safe, but they feel helpless that the steps to get to safety is often hard, overwhelming and confusing - involving case-by-case memorisation and ad hoc tactics. Today, we're exploring three ideas that allow users to accomplish their tasks faster, in a way that's more secure and privacy-aware than ever.
User Profiles
When users want to share their computer/browser with other people (permanently or temporarily), they shouldn't worry about "mother-in-law snooping".
Containers
When users want to use many accounts for the same websites - professional/personal emails, multiple Twitter usernames, separate eBay buyer/seller - they shouldn't need to sign out or use another browser. When users open a sensitive site - banking, government services - they should be protected against potential attacks (e.g. cross-site request forgery).
Private Session
When users want to browse privately, the sites they open in secret shouldn't know about the other sites they open in secret.
The wiki has descriptions and mockups of each idea. We're looking forward to your contribution!
Monica Chew
Jan 21, 2015, 12:57:24 PM1/21/15
to Bram Pitoyo, dev-privacy
I think this is great idea and am looking forward to seeing work in this
area. The way people expect multiple profiles or containers to interact
with things like password manager or sync will also affect the architecture
of the solution.
I ran a small survey on how many people have multiple Twitter accounts. The
results (
https://www.google.com/insights/consumersurveys/view?survey=wwqcjgux42gtw&question=1&filter=&rw=1)
are that about 20% of Twitter users have multiple accounts. There is
definitely a need in this area!
Thanks,
Monica
> _______________________________________________
> dev-privacy mailing list
> dev-p...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-privacy
>
area. The way people expect multiple profiles or containers to interact
with things like password manager or sync will also affect the architecture
of the solution.
I ran a small survey on how many people have multiple Twitter accounts. The
results (
https://www.google.com/insights/consumersurveys/view?survey=wwqcjgux42gtw&question=1&filter=&rw=1)
are that about 20% of Twitter users have multiple accounts. There is
definitely a need in this area!
Thanks,
Monica
> dev-privacy mailing list
> dev-p...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-privacy
>
Ehsan Akhgari
Jan 21, 2015, 1:15:04 PM1/21/15
to Francois Marier, dev-p...@lists.mozilla.org
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
(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
Steve Workman
Jan 21, 2015, 2:02:48 PM1/21/15
to Ehsan Akhgari, dev-p...@lists.mozilla.org
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 <ehsan....@gmail.com>
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:
>
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 <ehsan....@gmail.com>
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:
>
Ehsan Akhgari
Jan 21, 2015, 2:17:32 PM1/21/15
to Steve Workman, dev-p...@lists.mozilla.org
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
> 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.
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?
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.
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?
> 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.
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.
But please note that there are a lot of other places outside of Necko
that are also aware of private browsing.
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 <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>> 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:
>
> <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
> dev-p...@lists.mozilla.org <mailto:dev-p...@lists.mozilla.org>
> https://lists.mozilla.org/__listinfo/dev-privacy
> <https://lists.mozilla.org/listinfo/dev-privacy>
>
>
> _________________________________________________
> dev-privacy mailing list
> dev-p...@lists.mozilla.org <mailto:dev-p...@lists.mozilla.org>
> https://lists.mozilla.org/__listinfo/dev-privacy
> <https://lists.mozilla.org/listinfo/dev-privacy>
>
>
Steve Workman
Jan 21, 2015, 2:27:15 PM1/21/15
to Ehsan Akhgari, dev-p...@lists.mozilla.org
On Wed, Jan 21, 2015 at 11:17 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:
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 <ehsan....@gmail.com
>> <mailto:ehsan....@gmail.com>> 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:
>>
>> 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_
wrote:
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?
>
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.
>
prototype.
>
> But please note that there are a lot of other places outside of Necko that
> are also aware of private browsing.
>
>
> 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 <ehsan....@gmail.com
>> <mailto:ehsan....@gmail.com>> 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:
>>
>> _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
>> dev-p...@lists.mozilla.org <mailto:dev-privacy@lists.
>> _________________________________________________
>> dev-privacy mailing list
Ehsan Akhgari
Jan 21, 2015, 7:20:35 PM1/21/15
to Steve Workman, dev-p...@lists.mozilla.org
> <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 :)
Nice!
> 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
> <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,
>
> We're currently doing some user research to figure out how we might do
> this best.
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?
> 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.
profile, right?
> 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.
information about your browsing in the first place (with the exception
of a few things, such as bookmarks, and downloaded files, which we can
ignore for now.) The way that it's implemented is (very simplistically)
by looking at a boolean flag corresponding to the docshell of the
"current page" in places where we need to write something to disk, and
choosing whether to do that based on the value of that flag.
Because of this, I think if you don't need this explicit guarantee,
building things on top of private browsing may just increase complexity
needlessly.
I would be happy to answer any questions you may have about how this all
works. Depending on the level of detail you're looking for, it may not
fit in one email! :-)
<https://dxr.mozilla.org/mozilla-central/search?q=NS_UsePrivateBrowsing>.
Plus the call sites to nsILoadContext::UsePrivateBrowsing:
<https://dxr.mozilla.org/mozilla-central/search?q=UsePrivateBrowsing&case=true>.
Plus a few places that use nsILoadContext::GetUsePrivateBrowsing
directly (they should stop!!):
<https://dxr.mozilla.org/mozilla-central/search?q=GetUsePrivateBrowsing&redirect=true>.
Plus the usages of mInPrivateBrowsing in docshell:
<https://dxr.mozilla.org/mozilla-central/search?q=mInPrivateBrowsing&case=true&redirect=true>.
I think that should give you almost all of the C++ code that is aware
of PB.
In JS code, the call sites to
PrivateBrowsingUtils.isWindowPrivate/isContentWindowPrivate:
<https://dxr.mozilla.org/mozilla-central/search?q=isWindowPrivate&case=true>
<https://dxr.mozilla.org/mozilla-central/search?q=isContentWindowPrivate&case=true>.
This should be most (but not all) of it.
Cheers,
Ehsan
> 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
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>
> <mailto:ehsan....@gmail.com>>> 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:
>
>
> 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:
>
> <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>>
> [2]
> https://wiki.mozilla.org/____Security/Contextual_Identity_____Project/User_Profiles
> <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
> <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/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
> <https://wiki.mozilla.org/Security/Contextual_Identity_Project/Private_Session>>
> ___________________________________________________
> <mailto:dev-privacy@lists.__mozilla.org
> <mailto:dev-p...@lists.mozilla.org>>
> https://lists.mozilla.org/____listinfo/dev-privacy
> <https://lists.mozilla.org/__listinfo/dev-privacy>
> <https://lists.mozilla.org/__listinfo/dev-privacy
> <https://lists.mozilla.org/listinfo/dev-privacy>>
>
>
> ___________________________________________________
> <mailto:dev-privacy@lists.__mozilla.org
> <mailto:dev-p...@lists.mozilla.org>>
> https://lists.mozilla.org/____listinfo/dev-privacy
> <https://lists.mozilla.org/__listinfo/dev-privacy>
> <https://lists.mozilla.org/__listinfo/dev-privacy
> <https://lists.mozilla.org/listinfo/dev-privacy>>
>
>
>
>
Francois Marier
Jan 21, 2015, 8:20:37 PM1/21/15
to
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)
> 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?
so that it's lightweight and that things like bookmarks and history are
shared.
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?
- you need to create a profile on disk, just to trash it later
- you can't share history and bookmarks
- a new Firefox process is started per profile
Francois
Ehsan Akhgari
Jan 22, 2015, 4:23:45 PM1/22/15
to Francois Marier, dev-p...@lists.mozilla.org
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
> 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.
very strongly that the existing appId support will not be enough.
> 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
> - you can't share history and bookmarks
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?)
> - a new Firefox process is started per profile
Steve Workman
Jan 22, 2015, 4:38:41 PM1/22/15
to Ehsan Akhgari, dev-p...@lists.mozilla.org, Francois Marier
On Thu, Jan 22, 2015 at 1:23 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:
> On 2015-01-21 8:20 PM, Francois Marier wrote:
>
>
> 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
>>
>
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
>>
>
>
> - a new Firefox process is started per profile
>>
>
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.
>>
>
>>
>>> 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.
> very strongly that the existing appId support will not be enough.
>
>
> 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.
> 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?)
>
>
> - a new Firefox process is started per profile
>>
>
> Why is this a bad thing?
Increased memory usage.
Steve Workman
Jan 22, 2015, 4:44:12 PM1/22/15
to Ehsan Akhgari, dev-p...@lists.mozilla.org, Francois Marier
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 <swor...@mozilla.com> wrote:
> On Thu, Jan 22, 2015 at 1:23 PM, Ehsan Akhgari <ehsan....@gmail.com>
> wrote:
>
>> On 2015-01-21 8:20 PM, Francois Marier wrote:
>>
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 <swor...@mozilla.com> wrote:
> On Thu, Jan 22, 2015 at 1:23 PM, Ehsan Akhgari <ehsan....@gmail.com>
> 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:
>>>>
>>>
>>>> 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>
>>>>>
>>>>> 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.
>>>
>>
>>>>> 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.
>
>>
>> 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
>>>
>>
>>>
>>>
>>> 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.
>
>>
>>
>
> 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.
>
>>
>> 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
>>>
>>
>>>
>>
Ehsan Akhgari
Jan 22, 2015, 5:26:14 PM1/22/15
to Steve Workman, dev-p...@lists.mozilla.org, Francois Marier
On 2015-01-22 4:38 PM, Steve Workman wrote:
> <https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers>
> <https://wiki.mozilla.org/__Security/Contextual_Identity___Project/Containers
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
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
>
>
But for the purpose of building a prototype I'd pick the easiest
approach to implement.
> - a new Firefox process is started per profile
>
>
instance of Firefox without the cruft in your main profile may result in
lower memory usage.
> On Thu, Jan 22, 2015 at 1:23 PM, Ehsan Akhgari <ehsan....@gmail.com
> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2015-01-21 8:20 PM, Francois Marier wrote:
>
> <mailto:ehsan....@gmail.com>> 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
>
> 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>>
>
> 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.
>
>
>
> 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
> 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.
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>
>
> 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
>
>
>
> 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
> 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.
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.
> 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.
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
>
>
> Increased memory usage.
instance of Firefox without the cruft in your main profile may result in
lower memory usage.
Ehsan Akhgari
Jan 22, 2015, 5:28:27 PM1/22/15
to Steve Workman, dev-p...@lists.mozilla.org, Francois Marier
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!
> 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?
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
> <mailto:swor...@mozilla.com>> wrote:
>
> On Thu, Jan 22, 2015 at 1:23 PM, Ehsan Akhgari
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>> wrote:
>
> On 2015-01-21 8:20 PM, Francois Marier wrote:
>
> On Thu, Jan 22, 2015 at 1:23 PM, Ehsan Akhgari
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>> 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:
>
>
> 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>
> <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.
>
>
>
> 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.
>
>
> 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
>
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
>
>
>
> Increased memory usage.
>
>
>
> _________________________________________________
> dev-privacy mailing list
> dev-p...@lists.mozilla.org <mailto:dev-p...@lists.mozilla.org>
> https://lists.mozilla.org/__listinfo/dev-privacy
> dev-privacy mailing list
> dev-p...@lists.mozilla.org <mailto:dev-p...@lists.mozilla.org>
> <https://lists.mozilla.org/listinfo/dev-privacy>
>
>
>
Andrea Marchesini
Jan 23, 2015, 4:38:34 AM1/23/15
to Steve Workman, Ehsan Akhgari, Francois Marier, dev-p...@lists.mozilla.org
I still don't have a strong opinion between profiles vs container. But here
my feedback to the discussion.
> 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.
>
Correct. The current limitation I see are:
1. window.open() fails. This because the current window.open checks some
permissions based on the app having the docShell.appId.
But just setting the appId in the docshell (this is what I do in priv8) I
just abuse of appid technologies because technically I don't have a real
app, fully installed.
So, window.open using nsIAppService will try to retrieve the
mozIApplication object from the appId. This fails and window.open throws an
exception.
Nothing impossible to fix, but there is some work to do.
I discussed a lot with sicking and bent about how to improve the appId
system and we all agree that would be nice, in the long run, to switch to
some kind of 'prefix' and split the app feature from the prefix
(container?) feature. This seems the perfect solution to the container
approach.
2. Some other function fails too: canvas.toDataURI... but I'm not 100% sure
about this. But I guess the reason is similar to point 1.
> 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.
>
Indeed. I guess we should also decide if we want to have this feature
window based on tab based.
Personally, the reason why I love priv8 (appId) more than switchy
(profiles) is that with priv8 I can have sandboxed tabs. This is literally
awesome for how I use the browser. I don't like to have multiple windows,
but tons of tabs.
Plus, if we have this feature based on tabs, we can do magic tricks like:
- sandboxes per origin - any time I open gmail or facebook or twitter, put
it in the container X...
- help the user to switch to the right container with a new UX.
- security analysis based on the browser history: I'm thinking about: "this
website is considered dangerous for some privacy concern, do you want me
(firefox) sandbox it?"
- one more thing would be: sandbox switching: I sandbox 'facebook.com'. One
day I do a mistake and I log-in on facebook in the default container (no
app). I can open some settings panel and do: "switch my facebook history
from the default container to the facebook container. And magically I
restore the division between containers.
> >
> > - a new Firefox process is started per profile
> >>
> >
b
my feedback to the discussion.
> 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.
>
1. window.open() fails. This because the current window.open checks some
permissions based on the app having the docShell.appId.
But just setting the appId in the docshell (this is what I do in priv8) I
just abuse of appid technologies because technically I don't have a real
app, fully installed.
So, window.open using nsIAppService will try to retrieve the
mozIApplication object from the appId. This fails and window.open throws an
exception.
Nothing impossible to fix, but there is some work to do.
I discussed a lot with sicking and bent about how to improve the appId
system and we all agree that would be nice, in the long run, to switch to
some kind of 'prefix' and split the app feature from the prefix
(container?) feature. This seems the perfect solution to the container
approach.
2. Some other function fails too: canvas.toDataURI... but I'm not 100% sure
about this. But I guess the reason is similar to point 1.
> 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.
>
window based on tab based.
Personally, the reason why I love priv8 (appId) more than switchy
(profiles) is that with priv8 I can have sandboxed tabs. This is literally
awesome for how I use the browser. I don't like to have multiple windows,
but tons of tabs.
Plus, if we have this feature based on tabs, we can do magic tricks like:
- sandboxes per origin - any time I open gmail or facebook or twitter, put
it in the container X...
- help the user to switch to the right container with a new UX.
- security analysis based on the browser history: I'm thinking about: "this
website is considered dangerous for some privacy concern, do you want me
(firefox) sandbox it?"
- one more thing would be: sandbox switching: I sandbox 'facebook.com'. One
day I do a mistake and I log-in on facebook in the default container (no
app). I can open some settings panel and do: "switch my facebook history
from the default container to the facebook container. And magically I
restore the division between containers.
> >
> > - a new Firefox process is started per profile
> >>
> >
> > Why is this a bad thing?
>
>
> Increased memory usage.
>
We are already starting tons of new processes with e10s, right?
>
>
> Increased memory usage.
>
b
Andrea Marchesini
Jan 23, 2015, 4:41:55 AM1/23/15
to Ehsan Akhgari, Steve Workman, Francois Marier, dev-p...@lists.mozilla.org
I look forward to see what you guys come up with!
>
>
Yeah! me too. Actually I'm totally happy to help!!
>
>
My dream is to get rid of priv8 and switchy and have the same functionality
in ff, natively!
When/how do we start? :)
b
Ehsan Akhgari
Jan 23, 2015, 2:27:58 PM1/23/15
to Andrea Marchesini, Steve Workman, Francois Marier, dev-p...@lists.mozilla.org
On 2015-01-23 4:38 AM, Andrea Marchesini wrote:
> I still don't have a strong opinion between profiles vs container. But
> here my feedback to the discussion.
>
> > 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.
>
>
> Correct. The current limitation I see are:
>
> 1. window.open() fails. This because the current window.open checks some
> permissions based on the app having the docShell.appId.
> But just setting the appId in the docshell (this is what I do in priv8)
> I just abuse of appid technologies because technically I don't have a
> real app, fully installed.
>
> So, window.open using nsIAppService will try to retrieve the
> mozIApplication object from the appId. This fails and window.open throws
> an exception.
>
> Nothing impossible to fix, but there is some work to do.
>
> I discussed a lot with sicking and bent about how to improve the appId
> system and we all agree that would be nice, in the long run, to switch
> to some kind of 'prefix' and split the app feature from the prefix
> (container?) feature. This seems the perfect solution to the container
> approach.
>
> 2. Some other function fails too: canvas.toDataURI... but I'm not 100%
> sure about this. But I guess the reason is similar to point 1.
Indeed, appId as currently stands is not suitable for _shipping_
> I still don't have a strong opinion between profiles vs container. But
> here my feedback to the discussion.
>
> > 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.
>
>
> Correct. The current limitation I see are:
>
> 1. window.open() fails. This because the current window.open checks some
> permissions based on the app having the docShell.appId.
> But just setting the appId in the docshell (this is what I do in priv8)
> I just abuse of appid technologies because technically I don't have a
> real app, fully installed.
>
> So, window.open using nsIAppService will try to retrieve the
> mozIApplication object from the appId. This fails and window.open throws
> an exception.
>
> Nothing impossible to fix, but there is some work to do.
>
> I discussed a lot with sicking and bent about how to improve the appId
> system and we all agree that would be nice, in the long run, to switch
> to some kind of 'prefix' and split the app feature from the prefix
> (container?) feature. This seems the perfect solution to the container
> approach.
>
> 2. Some other function fails too: canvas.toDataURI... but I'm not 100%
> sure about this. But I guess the reason is similar to point 1.
something based on. It is however suitable for building a prototype on,
but there will be these types of issues in the prototype (which is
probably fine.)
> 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.
>
>
> Indeed. I guess we should also decide if we want to have this feature
> window based on tab based.
> Personally, the reason why I love priv8 (appId) more than switchy
> (profiles) is that with priv8 I can have sandboxed tabs. This is
> literally awesome for how I use the browser. I don't like to have
> multiple windows, but tons of tabs.
with having a tab based container, as then we'd need to handle the cases
where a tab changes what container it loads content is.
Based on my experience with the private browsing feature (which is of
course not exactly the same) it can be very hard to fix all of those
edge cases.
> Plus, if we have this feature based on tabs, we can do magic tricks like:
>
> - sandboxes per origin - any time I open gmail or facebook or twitter,
> put it in the container X...
>
> - help the user to switch to the right container with a new UX.
>
> - security analysis based on the browser history: I'm thinking about:
> "this website is considered dangerous for some privacy concern, do you
> want me (firefox) sandbox it?"
>
> - one more thing would be: sandbox switching: I sandbox 'facebook.com
> in the default container (no app). I can open some settings panel and
> do: "switch my facebook history from the default container to the
> facebook container. And magically I restore the division between containers.
I think all of these can be implemented with an approach based on
> do: "switch my facebook history from the default container to the
> facebook container. And magically I restore the division between containers.
Windows as well.
> >
> > - a new Firefox process is started per profile
> >>
> >
> > Why is this a bad thing?
>
>
> Increased memory usage.
>
>
> We are already starting tons of new processes with e10s, right?
Yeah, the assumption that more processes means more memory is not
>
>
> Increased memory usage.
>
>
> We are already starting tons of new processes with e10s, right?
necessarily true.
Bram Pitoyo
Jan 26, 2015, 11:45:47 PM1/26/15
to
Hi Andrea,
Thanks so much for wanting to help with this project!
Although we're quite sure that Private Session is something that we want to happen, we're less sure about containers and multiple profiles.
To get a sense for the problem, we came up with a few design ideas on how to create, access and destroy containers and profiles. You can see them on the wiki.
But there are other questions that we'd like to know the answer to before we proceed:
Do our users have multiple accounts for the same website? If yes, what for, and how often do they use it and keep each account open? What do they expect each container/profile to do, as some information is shared between them, and some are separated? And how do they work around this problem today?
Do our users share their computers with many people? How do they do it so that each person keeps their own set of online identities? No browser today has any sort of protection against prying, overly inquisitive in-laws, so how do they work around this problem today?
Our intention for the research is to determine which problem is more prevalent and in need of a solution more quickly. I'd love to do both, but we can only tackle one at a time. And plus, one approach may be immediately more beneficial and should be pursued straight away.
Being the developer of two add-ons that solves the same problems we intended to solve, I think you have some important insights into this problem, and would love it if you could talk about feedbacks you've gotten and observations you've made.
* How do users think about separating identities in separate profiles vs. windows vs. tabs? What's their mental models?
* What are the most common sites that's been containerised, and how long do they typically keep it open?
* How many user profiles have each person typically create
* How do they subdivide their containers/profile? One for home & work, one for each family member, etc.
* What are some features that your users want most?
* What have you observed over the years, as more and more people use your add-ons?
I'm in NZ and you're in the UK, so scheduling meeting will be a bit tricky. You can let me know if there's a good time to talk this week, but answering by email might be easier!
Thanks so much for wanting to help with this project!
Although we're quite sure that Private Session is something that we want to happen, we're less sure about containers and multiple profiles.
To get a sense for the problem, we came up with a few design ideas on how to create, access and destroy containers and profiles. You can see them on the wiki.
But there are other questions that we'd like to know the answer to before we proceed:
Do our users have multiple accounts for the same website? If yes, what for, and how often do they use it and keep each account open? What do they expect each container/profile to do, as some information is shared between them, and some are separated? And how do they work around this problem today?
Do our users share their computers with many people? How do they do it so that each person keeps their own set of online identities? No browser today has any sort of protection against prying, overly inquisitive in-laws, so how do they work around this problem today?
Our intention for the research is to determine which problem is more prevalent and in need of a solution more quickly. I'd love to do both, but we can only tackle one at a time. And plus, one approach may be immediately more beneficial and should be pursued straight away.
Being the developer of two add-ons that solves the same problems we intended to solve, I think you have some important insights into this problem, and would love it if you could talk about feedbacks you've gotten and observations you've made.
* How do users think about separating identities in separate profiles vs. windows vs. tabs? What's their mental models?
* What are the most common sites that's been containerised, and how long do they typically keep it open?
* How many user profiles have each person typically create
* How do they subdivide their containers/profile? One for home & work, one for each family member, etc.
* What are some features that your users want most?
* What have you observed over the years, as more and more people use your add-ons?
I'm in NZ and you're in the UK, so scheduling meeting will be a bit tricky. You can let me know if there's a good time to talk this week, but answering by email might be easier!
Andrea Marchesini
Jan 27, 2015, 7:18:13 AM1/27/15
to Bram Pitoyo, dev-p...@lists.mozilla.org
I can just talk about the feedback, the emails I receive from priv8 and
switchy users. Here the answer I can give.
> Do our users have multiple accounts for the same website? If yes, what
> for, and how often do they use it and keep each account open? What do they
> expect each container/profile to do, as some information is shared between
> them, and some are separated? And how do they work around this problem
> today?
>
>From the feedback I receive from switchy and priv8, I would say that:
1. WebDevelopers: they need to test maybe websites with multiple accounts.
User/admin for instance. For maybe multiple users.
2. Multiple gmail accounts: work and private. Usually this doesn't happen
with facebook, but yes, with Gmail, it happens a lot (I do this too).
Currently, the work around is: multiple browser: chrome and firefox opened
at the same time. Chrome has the multi profile support built-in. Firefox
does not (... just a few do '-P' from the command line). For this reason
switchy and priv8 make people happy :)
>
> Do our users share their computers with many people? How do they do it so
> that each person keeps their own set of online identities? No browser today
> has any sort of protection against prying, overly inquisitive in-laws, so
> how do they work around this problem today?
>
>From the emails I receive, I don't see this as a real problem. Just 1 user
told me that he was using multifox and now he uses priv8 when he shares the
browser with other members of the family. I guess private browsing is
probably a better choice for this use-case.
> * How do users think about separating identities in separate profiles vs.
> windows vs. tabs? What's their mental models?
>
Ignoring the technical aspects, the main difference between my 2 addons is
that switchy is window (profile) based, priv8 is tab (appId) based. And,
yeah, it seems that priv8 has a lot more users (more then the double) of
switchy.
> * What are the most common sites that's been containerised, and how long
> do they typically keep it open?
>
gmail and google services (calendar, docs, etc), websites in construction.
> * How many user profiles have each person typically create
> * How do they subdivide their containers/profile? One for home & work, one
> for each family member, etc.
> * What are some features that your users want most?
> * What have you observed over the years, as more and more people use your
> add-ons?
>
No idea for these 4 questions. In case we want, maybe I can add a small
form in priv8/switchy asking a few questions to the user. I don't know if
I'll receive answers... but maybe yes.
>
> I'm in NZ and you're in the UK, so scheduling meeting will be a bit
> tricky. You can let me know if there's a good time to talk this week, but
> answering by email might be easier!
>
Well... 8pm my time is 8am your time. Too early for a meeting? :)
Let me know what you think about this answers.
BR,
b
switchy users. Here the answer I can give.
> Do our users have multiple accounts for the same website? If yes, what
> for, and how often do they use it and keep each account open? What do they
> expect each container/profile to do, as some information is shared between
> them, and some are separated? And how do they work around this problem
> today?
>
1. WebDevelopers: they need to test maybe websites with multiple accounts.
User/admin for instance. For maybe multiple users.
2. Multiple gmail accounts: work and private. Usually this doesn't happen
with facebook, but yes, with Gmail, it happens a lot (I do this too).
Currently, the work around is: multiple browser: chrome and firefox opened
at the same time. Chrome has the multi profile support built-in. Firefox
does not (... just a few do '-P' from the command line). For this reason
switchy and priv8 make people happy :)
>
> Do our users share their computers with many people? How do they do it so
> that each person keeps their own set of online identities? No browser today
> has any sort of protection against prying, overly inquisitive in-laws, so
> how do they work around this problem today?
>
told me that he was using multifox and now he uses priv8 when he shares the
browser with other members of the family. I guess private browsing is
probably a better choice for this use-case.
> * How do users think about separating identities in separate profiles vs.
> windows vs. tabs? What's their mental models?
>
that switchy is window (profile) based, priv8 is tab (appId) based. And,
yeah, it seems that priv8 has a lot more users (more then the double) of
switchy.
> * What are the most common sites that's been containerised, and how long
> do they typically keep it open?
>
> * How many user profiles have each person typically create
> * How do they subdivide their containers/profile? One for home & work, one
> for each family member, etc.
> * What are some features that your users want most?
> * What have you observed over the years, as more and more people use your
> add-ons?
>
form in priv8/switchy asking a few questions to the user. I don't know if
I'll receive answers... but maybe yes.
>
> I'm in NZ and you're in the UK, so scheduling meeting will be a bit
> tricky. You can let me know if there's a good time to talk this week, but
> answering by email might be easier!
>
Let me know what you think about this answers.
BR,
b
Mike Perry
Feb 1, 2015, 3:42:30 PM2/1/15
to dev-p...@lists.mozilla.org
Francois Marier:
containers for isolating identifiers to the URL bar domain (aka
double-keying). Our long-term goal is to produce a cookie/identifier
management UI that allows users to define their relationship to URL bar
sites in a way that resembles application management, rather than
managing a relationship to a myriad of third parties. Here's a mockup of
that UI idea, though obviously another layer of per-site account
management would also be nice:
https://www.torproject.org/projects/torbrowser/design/NewCookieManager.png
We already have some patches that do this isolation for the image cache
(which I don't think AppID-based containers would help for?), as well as
the content cache (for which they would), and for DOM Storage (for which
I am unsure). We've posted these patches in the Mozilla bugtracker under
this meta-bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=939354
We still lack patches for proper cookie and http auth double-keying. As
a stopgap, we disable third party cookies and third party http auth. We
also simply disable TLS session tickets rather than try to double-key
them, which obviously is sub-optimal for performance, but may have other
additional benefits against Tor traffic correlation/anonymity against
exit node observers.
We also want to disable HSTS for third parties while such isolation is
enabled (unless the URL bar domain uses HSTS). This will deal with the
HSTS supercookies, and should not pose a security risk if cookies and
cache are properly isolated.
I am wondering if the AppId/Container model might make Tor Browser's
first party isolation easier? Should we be trying to use it for our
current and future patches?
We're also eager to discuss ways of unifying our approach to privacy and
identity management with Mozilla's plans, such that ultimately we can
provide a safe Tor mode experience for normal Firefox users. In the
meantime, I think we would also benefit from sharing as much of the
implementation and plumbing as possible, as well.
--
Mike Perry
> 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.
For what it's worth, for Tor Browser we are interested in using
> 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.
containers for isolating identifiers to the URL bar domain (aka
double-keying). Our long-term goal is to produce a cookie/identifier
management UI that allows users to define their relationship to URL bar
sites in a way that resembles application management, rather than
managing a relationship to a myriad of third parties. Here's a mockup of
that UI idea, though obviously another layer of per-site account
management would also be nice:
https://www.torproject.org/projects/torbrowser/design/NewCookieManager.png
We already have some patches that do this isolation for the image cache
(which I don't think AppID-based containers would help for?), as well as
the content cache (for which they would), and for DOM Storage (for which
I am unsure). We've posted these patches in the Mozilla bugtracker under
this meta-bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=939354
We still lack patches for proper cookie and http auth double-keying. As
a stopgap, we disable third party cookies and third party http auth. We
also simply disable TLS session tickets rather than try to double-key
them, which obviously is sub-optimal for performance, but may have other
additional benefits against Tor traffic correlation/anonymity against
exit node observers.
We also want to disable HSTS for third parties while such isolation is
enabled (unless the URL bar domain uses HSTS). This will deal with the
HSTS supercookies, and should not pose a security risk if cookies and
cache are properly isolated.
I am wondering if the AppId/Container model might make Tor Browser's
first party isolation easier? Should we be trying to use it for our
current and future patches?
We're also eager to discuss ways of unifying our approach to privacy and
identity management with Mozilla's plans, such that ultimately we can
provide a safe Tor mode experience for normal Firefox users. In the
meantime, I think we would also benefit from sharing as much of the
implementation and plumbing as possible, as well.
--
Mike Perry
Bram Pitoyo
Feb 1, 2015, 11:32:36 PM2/1/15
to Andrea Marchesini, dev-p...@lists.mozilla.org
>
> 1. WebDevelopers: they need to test maybe websites with multiple accounts.
> 1. WebDevelopers: they need to test maybe websites with multiple accounts.
> 2. Multiple gmail accounts: work and private.
>
>
> Currently, the work around is: multiple browser: chrome and firefox opened
> at the same time.
>
It’s great to see our hypothesis confirmed. Yes, we think that these are
> at the same time.
>
the two main reasons why our users want session-specific browsing.
Chrome’s multiple users profile is stable and fast to run – although not
protected by password – so it would be interesting to see how people
ultimately uses it (ie. how many people use more than one profile? whether
it’s really usage between multiple people, or more person with multiple
accounts?)
I have three further questions for you that might yield interesting answers:
1. Why would users still want to open another mailbox in a separate
container, when Google already supports multiple accounts? Is it about
awareness (ie. users don’t know that Google can do it), about perception of
safety (if opened in the same session, data might leak), or something else?
2. What about uses in other types of websites other than email providers
and Google Apps? Social media comes to mind. In other words, is it common
to have more than one accounts in Twitter, Pinterest, Facebook, etc.? The
answer may be no, but I’m curious to see what other use cases they are.
3. Do you see evidences of of priv8 or switchy used to solve privacy and
security problems? For example, users would open banks or other personal
websites in their own containers so they don’t “infect” the main browsing
session.
Just 1 user told me that he was using multifox and now he uses priv8 when
> he shares the browser with other members of the family. I guess private
> browsing is probably a better choice for this use-case.
numbers prove that). I wonder why they prefer one over the other? If I have
to venture a guess, it’s because user profiles are seen as something
heavyweight – slow to create and hard to destroy – whereas tab sessions are
quick to create, dismiss and reopen.
No idea for these 4 questions. In case we want, maybe I can add a small
> form in priv8/switchy asking a few questions to the user. I don't know if
> I'll receive answers... but maybe yes.
utilise multiple accounts.
Question for Monica and Steve: in addition to the quantitative survey we’re
going to run, would we consider doing a more in-depth research, where we
interview a few people who uses multiple accounts? If yes, the add-ons user
might be great candidates.
Thanks for your help, Andrea!
On Wed, Jan 28, 2015 at 1:18 AM, Andrea Marchesini <amarc...@mozilla.com>
wrote:
> I can just talk about the feedback, the emails I receive from priv8 and
> switchy users. Here the answer I can give.
>
>
>> Do our users have multiple accounts for the same website? If yes, what
>> for, and how often do they use it and keep each account open? What do they
>> expect each container/profile to do, as some information is shared between
>> them, and some are separated? And how do they work around this problem
>> today?
>>
>
>> for, and how often do they use it and keep each account open? What do they
>> expect each container/profile to do, as some information is shared between
>> them, and some are separated? And how do they work around this problem
>> today?
>>
>
> From the feedback I receive from switchy and priv8, I would say that:
>
> 1. WebDevelopers: they need to test maybe websites with multiple accounts.
> User/admin for instance. For maybe multiple users.
>
> 2. Multiple gmail accounts: work and private. Usually this doesn't happen
> with facebook, but yes, with Gmail, it happens a lot (I do this too).
>
> Currently, the work around is: multiple browser: chrome and firefox opened
> at the same time. Chrome has the multi profile support built-in. Firefox
> does not (... just a few do '-P' from the command line). For this reason
> switchy and priv8 make people happy :)
>
>
>>
>
> 1. WebDevelopers: they need to test maybe websites with multiple accounts.
> User/admin for instance. For maybe multiple users.
>
> 2. Multiple gmail accounts: work and private. Usually this doesn't happen
> with facebook, but yes, with Gmail, it happens a lot (I do this too).
>
> Currently, the work around is: multiple browser: chrome and firefox opened
> at the same time. Chrome has the multi profile support built-in. Firefox
> does not (... just a few do '-P' from the command line). For this reason
> switchy and priv8 make people happy :)
>
>
>>
>> Do our users share their computers with many people? How do they do it so
>> that each person keeps their own set of online identities? No browser today
>> has any sort of protection against prying, overly inquisitive in-laws, so
>> how do they work around this problem today?
>>
>
>> that each person keeps their own set of online identities? No browser today
>> has any sort of protection against prying, overly inquisitive in-laws, so
>> how do they work around this problem today?
>>
>
> From the emails I receive, I don't see this as a real problem. Just 1 user
> told me that he was using multifox and now he uses priv8 when he shares the
> browser with other members of the family. I guess private browsing is
> probably a better choice for this use-case.
>
>
> told me that he was using multifox and now he uses priv8 when he shares the
> browser with other members of the family. I guess private browsing is
> probably a better choice for this use-case.
>
>
>> * How do users think about separating identities in separate profiles vs.
>> windows vs. tabs? What's their mental models?
>>
>
>> windows vs. tabs? What's their mental models?
>>
>
> Ignoring the technical aspects, the main difference between my 2 addons is
> that switchy is window (profile) based, priv8 is tab (appId) based. And,
> yeah, it seems that priv8 has a lot more users (more then the double) of
> switchy.
>
>
> that switchy is window (profile) based, priv8 is tab (appId) based. And,
> yeah, it seems that priv8 has a lot more users (more then the double) of
> switchy.
>
>
>> * What are the most common sites that's been containerised, and how long
>> do they typically keep it open?
>>
>
>> do they typically keep it open?
>>
>
> gmail and google services (calendar, docs, etc), websites in construction.
>
>
>
>
>> * How many user profiles have each person typically create
>> * How do they subdivide their containers/profile? One for home & work,
>> one for each family member, etc.
>> * What are some features that your users want most?
>> * What have you observed over the years, as more and more people use your
>> add-ons?
>>
>
>> * How do they subdivide their containers/profile? One for home & work,
>> one for each family member, etc.
>> * What are some features that your users want most?
>> * What have you observed over the years, as more and more people use your
>> add-ons?
>>
>
> No idea for these 4 questions. In case we want, maybe I can add a small
> form in priv8/switchy asking a few questions to the user. I don't know if
> I'll receive answers... but maybe yes.
>
>
>
>>
> form in priv8/switchy asking a few questions to the user. I don't know if
> I'll receive answers... but maybe yes.
>
>
>
>>
>> I'm in NZ and you're in the UK, so scheduling meeting will be a bit
>> tricky. You can let me know if there's a good time to talk this week, but
>> answering by email might be easier!
>>
>
>> tricky. You can let me know if there's a good time to talk this week, but
>> answering by email might be easier!
>>
>
Steve Workman
Feb 2, 2015, 8:25:15 PM2/2/15
to Mike Perry, dev-p...@lists.mozilla.org
On Sun, Feb 1, 2015 at 12:41 PM, Mike Perry <mike...@torproject.org>
wrote:
> Francois Marier:
don't even have a prototype built into Firefox yet; Baku's addon Priv8 is a
great example though.
>
> We already have some patches that do this isolation for the image cache
> ... and for DOM Storage....
> We still lack patches for proper cookie and http auth double-keying. ....
things like window.open() that do not work correctly. AppID is a B2G
concept that we hope to generalize for containers but that work hasn't
started yet. So, right not, we don't have anything for you to use. In the
future, yes, it seems like it could be a good model for your first party
isolation project.
Steve.
wrote:
> Francois Marier:
> > 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.
>
> > 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.
>
> For what it's worth, for Tor Browser we are interested in using
> containers for isolating identifiers to the URL bar domain (aka
> double-keying). Our long-term goal is to produce a cookie/identifier
> management UI that allows users to define their relationship to URL bar
> sites in a way that resembles application management, rather than
> managing a relationship to a myriad of third parties. Here's a mockup of
> that UI idea, though obviously another layer of per-site account
> management would also be nice:
> https://www.torproject.org/projects/torbrowser/design/NewCookieManager.png
>
Nice to have another potential user of Containers. Bear in mind that we
> containers for isolating identifiers to the URL bar domain (aka
> double-keying). Our long-term goal is to produce a cookie/identifier
> management UI that allows users to define their relationship to URL bar
> sites in a way that resembles application management, rather than
> managing a relationship to a myriad of third parties. Here's a mockup of
> that UI idea, though obviously another layer of per-site account
> management would also be nice:
> https://www.torproject.org/projects/torbrowser/design/NewCookieManager.png
>
don't even have a prototype built into Firefox yet; Baku's addon Priv8 is a
great example though.
>
> We already have some patches that do this isolation for the image cache
> We still lack patches for proper cookie and http auth double-keying. ....
> We also want to disable HSTS for third parties while such isolation is
> enabled...
>
> I am wondering if the AppId/Container model might make Tor Browser's
> first party isolation easier? Should we be trying to use it for our
> current and future patches?
>
For now, you could experiment with it. As Baku's email said, there are
> I am wondering if the AppId/Container model might make Tor Browser's
> first party isolation easier? Should we be trying to use it for our
> current and future patches?
>
things like window.open() that do not work correctly. AppID is a B2G
concept that we hope to generalize for containers but that work hasn't
started yet. So, right not, we don't have anything for you to use. In the
future, yes, it seems like it could be a good model for your first party
isolation project.
Steve.
Andrea Marchesini
Feb 5, 2015, 10:30:02 AM2/5/15
to Bram Pitoyo, dev-p...@lists.mozilla.org
> I have three further questions for you that might yield interesting
> answers:
>
> 1. Why would users still want to open another mailbox in a separate
> container, when Google already supports multiple accounts? Is it about
> awareness (ie. users don’t know that Google can do it), about perception of
> safety (if opened in the same session, data might leak), or something else?
>
>
What I see is: they don't want to mix google accounts. Then this works just
> answers:
>
> 1. Why would users still want to open another mailbox in a separate
> container, when Google already supports multiple accounts? Is it about
> awareness (ie. users don’t know that Google can do it), about perception of
> safety (if opened in the same session, data might leak), or something else?
>
>
with google accounts, what about other websites?
About gmail, personally I don't use this feature: can you have 2 accounts
opened at the same time or you can switch between them?
What about other websites (second question)? For instance: personal
facebook and a business account. Same for other social networks.
>
> 1. Do you see evidences of of priv8 or switchy used to solve privacy
> and security problems? For example, users would open banks or other
> personal websites in their own containers so they don’t “infect” the main
> browsing session.
>
>
This is how I use priv8 :) gmail in a sandbox, social networks in another
> personal websites in their own containers so they don’t “infect” the main
> browsing session.
>
>
one. By default I'm not logged in google and social networks.
But I think I'm part of the 'paranoiac group' of users...
b
Bram Pitoyo
Feb 9, 2015, 1:32:36 AM2/9/15
to
==TL;DR==
1. Multiple identities gives our users control over the presentation of their online selves and allow them to get their social tasks done
2. Google can't quite get multiple identities to work properly across a wide range of services
3. Both of these facts strengthen the argument that we need a way to deal with multiple online identities effectively, even when it breaks the site terms (in Facebook's case) and even when the site already supports it natively (in Google's case)
==Google and multiple identities==
> What I see is: they don't want to mix google accounts. Then this works just
> with google accounts, what about other websites?
> About gmail, personally I don't use this feature: can you have 2 accounts
> opened at the same time or you can switch between them?
Initially, I was sceptical of this use case. Two things changed my mind:
1. A lot of people I have talked to wanted to open two Gmail mailboxes, but are unaware that it's possible to do so. In that case, they would use another browser or Private Browsing.
2. Google's multiple sign-in implementation doesn't work reliably across its services. It's very tricky to get right, and has lots of breakages.
Consider this scenario:
* Open a new tab and sign into Gmail
* Open another tab and sign into Gmail with another account
* Open another tab and open Google Drive
Which account will Google Drive open? Account A because it was set as the first default, or account B because it's the latest one opened?
The answer, as it turned out, is "it depends":
* Drive will use the last (current) account
* Plus will use the first (default) account
* In certain cases, Google's sign-in cookie only lets you sign in with one account at a time (https://support.google.com/accounts/answer/179235). In that case, Drive will ask you to sign out of every other account before accessing it.
==Facebook and multiple identities==
> What about other websites (second question)? For instance: personal
> facebook and a business account. Same for other social networks.
I was also sceptical of this at first. Facebook Terms forbid creating more than one personal account. By doing site isolation, won't we encourage people to break ToS?
As it turned out, people have used Facebook in many unexpected ways:
* It's against the Facebook Terms to use your personal account to represent something other than yourself (e.g. business). But when you try to comply by converting your personal account into a public page, all your friends, posts and photos are gone.
* Some sites encourage opening separate profiles for separate uses: one is personal and used to talk to friends and families, the other one is professional and given away to employers and written in front of business cards.
* Even if you want to use Facebook as one personality, Facebook doesn't have sophisticated tools to segregate who sees your posts and interactions. What if you don't want one set of friends to see that you've posted something to the other sets of friends? You can restrict it, but you'd have to create a list for every single group of friends you have.
In short, multiple Facebook identities might not be officially sanctioned, but it's the way that some people have molded the service to fit their needs.
1. Multiple identities gives our users control over the presentation of their online selves and allow them to get their social tasks done
2. Google can't quite get multiple identities to work properly across a wide range of services
3. Both of these facts strengthen the argument that we need a way to deal with multiple online identities effectively, even when it breaks the site terms (in Facebook's case) and even when the site already supports it natively (in Google's case)
==Google and multiple identities==
> What I see is: they don't want to mix google accounts. Then this works just
> with google accounts, what about other websites?
> About gmail, personally I don't use this feature: can you have 2 accounts
> opened at the same time or you can switch between them?
1. A lot of people I have talked to wanted to open two Gmail mailboxes, but are unaware that it's possible to do so. In that case, they would use another browser or Private Browsing.
2. Google's multiple sign-in implementation doesn't work reliably across its services. It's very tricky to get right, and has lots of breakages.
Consider this scenario:
* Open a new tab and sign into Gmail
* Open another tab and sign into Gmail with another account
* Open another tab and open Google Drive
Which account will Google Drive open? Account A because it was set as the first default, or account B because it's the latest one opened?
The answer, as it turned out, is "it depends":
* Drive will use the last (current) account
* Plus will use the first (default) account
* In certain cases, Google's sign-in cookie only lets you sign in with one account at a time (https://support.google.com/accounts/answer/179235). In that case, Drive will ask you to sign out of every other account before accessing it.
==Facebook and multiple identities==
> What about other websites (second question)? For instance: personal
> facebook and a business account. Same for other social networks.
As it turned out, people have used Facebook in many unexpected ways:
* It's against the Facebook Terms to use your personal account to represent something other than yourself (e.g. business). But when you try to comply by converting your personal account into a public page, all your friends, posts and photos are gone.
* Some sites encourage opening separate profiles for separate uses: one is personal and used to talk to friends and families, the other one is professional and given away to employers and written in front of business cards.
* Even if you want to use Facebook as one personality, Facebook doesn't have sophisticated tools to segregate who sees your posts and interactions. What if you don't want one set of friends to see that you've posted something to the other sets of friends? You can restrict it, but you'd have to create a list for every single group of friends you have.
In short, multiple Facebook identities might not be officially sanctioned, but it's the way that some people have molded the service to fit their needs.
0 new messages