On 2015-01-21 2:27 PM, Steve Workman wrote:
On Wed, Jan 21, 2015 at 11:17 AM, Ehsan Akhgari <[email protected]
<mailto:[email protected]>> wrote:
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
<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!
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?
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.
I completely agree, but that doesn't preclude the usage of a new
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.
No, private browsing doesn't write anything to disk that can contain
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! :-)
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?
There's tons. One is the call sites to NS_UsePrivateBrowsing:
<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
<[email protected] <mailto:[email protected]>
<mailto:ehsan.akhgari@gmail.__com
<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>
<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
<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
<https://wiki.mozilla.org/Security/Contextual_Identity_Project/Private_Session>>
___________________________________________________
dev-privacy mailing list
[email protected]
<mailto:[email protected]>
<mailto:dev-privacy@lists.__mozilla.org
<mailto:[email protected]>>
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>>
___________________________________________________
dev-privacy mailing list
[email protected]
<mailto:[email protected]>
<mailto:dev-privacy@lists.__mozilla.org
<mailto:[email protected]>>
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>>
_______________________________________________
dev-privacy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-privacy
