On 2015-01-21 2:02 PM, Steve Workman wrote:
Hi Ehsan,
There are a couple of use cases that we've talked about here.
Elaborating on those might help us determine some goals. (Francois and
co. can jump in and correct me here if I've missed something).
1. Being able to login to the same site using different logins, in
separate private sessions.
E.g. You're a user that always opens Twitter in a private browsing
window - you don't want any twitter history or data stored locally; you
have two accounts, one for personal and one for work and you want to be
logged in to both at the same time.
Goal - Be able to have separate login sessions for the same service
opened at the same time in private browsing.
For this use case, I think a solution based on appId should be fairly
sufficient. The most critical thing here is cookie separation, which
you get through appId. There may be some corner cases, such as a single
URI being served differently based on the login, but that should be
extremely rare.
There are other issues here though, which are not easily fixable with an
implementation based on private browsing. For example, you may want
your two sessions autocomplete different username/passwords for Twitter.
Or, you may want a bookmark to <https://twitter.com/i/notifications>
always open in your home session. Or you may want to have two different
copies of that bookmark, each opening in its own session. None of these
things can be easily implemented on top of the existing private
browsing. Have we thought about these cases?
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?
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.
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 <[email protected]
<mailto:[email protected]>> wrote:
Hi Francois!
(I mostly looked at the private session wiki page, FWIW.)
When you're talking about isolation, what exact things do you want
to isolate from? Is it just the appId based cookie jars which give
you isolation across some storage mechanisms? Or are you trying to
achieve more than that? I prefer us to first agree on what goals we
would like to achieve irrespective of the existing appId based
isolation, to make sure that the implementation doesn't guide our
design.
Cheers,
Ehsan
On 2015-01-20 11:16 PM, Francois Marier wrote:
A few of us have been thinking about how to let users manage their
multiple online identities in Firefox, as well as how to isolate
sites
from one another. Our goal is to find tools we can offer to
privacy-conscious Firefox users.
Containers [1] was the first idea that Bram and I came up with.
It's a
lightweight way to keep sessions (i.e. cookies, local storage, etc.)
separate. A single person could have more than one container in
their
browser.
User profiles [2] is a set of ideas that Bram and Ryan Feeley
had about
how to expose (and extend) the existing browser profile
functionality to
users. Multiple people who share the same browser (e.g. a
family) could
use this more heavyweight separation to keep their sessions,
history and
bookmarks separate.
Finally, we also brainstormed a few ideas around private
sessions [3] to
address a few use cases around session isolation without interfering
with the existing purpose/goals of private browsing.
None of this is final (or even scheduled to be implemented at this
point), we're just exploring a few ideas and welcome any feedback.
Francois
[1]
https://wiki.mozilla.org/__Security/Contextual_Identity___Project/Containers
<https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers>
[2]
https://wiki.mozilla.org/__Security/Contextual_Identity___Project/User_Profiles
<https://wiki.mozilla.org/Security/Contextual_Identity_Project/User_Profiles>
[3]
https://wiki.mozilla.org/__Security/Contextual_Identity___Project/Private_Session
<https://wiki.mozilla.org/Security/Contextual_Identity_Project/Private_Session>
_________________________________________________
dev-privacy mailing list
[email protected] <mailto:[email protected]>
https://lists.mozilla.org/__listinfo/dev-privacy
<https://lists.mozilla.org/listinfo/dev-privacy>
_________________________________________________
dev-privacy mailing list
[email protected] <mailto:[email protected]>
https://lists.mozilla.org/__listinfo/dev-privacy
<https://lists.mozilla.org/listinfo/dev-privacy>
_______________________________________________
dev-privacy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-privacy
