Chromium

I want to think about this...

This might be some amount of work.  I think the problem is that the profile object is somewhat global.  
Originally, our design allowed multiple profiles in the same process, but somewhere along the way, we lost the
ability to do that.

I thought that incognito meant that everything was destroyed when you close Chrome, not
when you close a tab...? In that case this would be expected behavior.

1) Not a security issue.
2) By design, that would create a usability issue otherwise.

Just to correct https://crbug.com/chromium/24690#c3, should be destroyed when the last incognito window closes
(which may be before when the browser closes)

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

It is by design, but it annoying. Foe example: I have multiple Google Apps accounts on
the same domain, that I use for different things - multiple identities, if you want.
There is no way to use google chrome to have all inboxes open at the same time, and
incognito windows just help me have at most two open at the same time (one non-
incognito, one incognito).

I believe that the user should have a minimal control over that, like "one new
incognito window / tab with fresh cookie jar".

[Empty comment from Monorail migration]

as a note on the bug I filed (which stuart merged here) the design I expected was as proposed by xtophk..
inheritance down the incognito chain, but not across incognito windows.

I can see that this won't be implemented any time soon, but I don't see anything to
indicate why it's marked WontFix.

My use case is that I leave an incognito window up logged into a 2nd webmail account so I
can stay logged into both accounts, so now I end up with one long-running incognito session
that was only getting reset whenever I reboot. It's not exactly secure if people are using
it wrong!

At the very least, the wording on the incognito landing page should read:
"after you close all incognito windows"
instead of:
"after you close the incognito window"

[Empty comment from Monorail migration]

Won't fix, really?

[Comment Deleted]

Reason enough to move back to Firefox, I think so....

@arnolab45: I hate to be the bearer of bad news, but Firefox "InPrivate" mode is worse. It offers no cookie jar separation whatsoever. With Chrome, you can at least have a "normal" and an "incognito" window open at the same time, and have some separation of cookie jars.

As you can see from the bug history, there are substantial usability issues to implementing something like this. If you have constructive solutions, please document them for consideration.

Other profile and cookie jar separation approaches are being debated. Constructive ideas welcomed.

Firstly, thanks for your prompt response.

Being a HUGE Chrome fan this is a hard option to consider, moving back to Firefox and all.. I have many fb-twitter-gmail accounts for business purposes and jumping from one login to another to respond to various clients is a very big frustration for me.

Firefox has a plugin called ChocoTorta, this allows multiple tabs to be opened with no cookie sharing.

Idea: Why can't Chrome create separate cookie jar's for each incognito window opened?

its also referred to as cookiepie

@arnolab45: my main worry with one-jar-per-incognito-window is user expectation: it would break user expectation with the "right click"->"open in new window" operation.

UI guys - do you remember the details on what other user-visible stuff might break if this were changed?

is there no way to distinguish between a new incognito window and a new incognito tab for cookie jar posts by chrome?

in theory, any new tab opened in an incognito window should be posting to the same cookie jar as the original incognito window, right?

the same would go for a second and third "new" incognito window opened?

I mean, if you can create one incognito cookie jar and post the new tab's cookies to it, you should be able to create a second, third, fourth ....tenth ... cookie jar?

its all going to be deleted anyway as soon as the incognito window is closed, right?

maybe just a simple if statement that checks if an incog window already exists, and creates another one with an incremented value name,  [chromejar, incogjar1, incogjar2, incogjar3, incogjar4, incogjar5, etc] ...

of course there will have to be a way for chrome to identify the "current-posting" normalCookieJar or incogCookieJar from within every tab ..

just spit-balling here, haven't done any programming in a long time.. ;)

@scarybeasts: The current (v. 8.0.552.5 dev) implementation of the Open Link in New Window from within an Incognito window grayed out the option "Open Link in Incognito Window" and allowed "Open Link in New Window." When I selected that latter option, it actually opened a new incognito window. That seemed reversed to me.

If the option were shown correctly to be "Open Link in Incognito Window" while in an incognito window, that should address the question of what user expectation should be: it should be the same as when activating that command from within the regular window, that there should be no sharing of cookies.

It seems to me that the user expectation is:
"Every window/tab shoudl inherit from it's parent the cookiejar/settings/etc."

So, if that's the case, then once I open one incognito window, it's properties flow down to all of it's children. A NEW incognito window from the root/main/non-incognito window, however, should start a new set of properties/jars/etc. That shouldn't be too hard to understand for users, should it?

To sum up the behaviour described in https://crbug.com/chromium/24690#c25 and #26...

When in a normal window/tab:
* open link in new incognito window - opens an incognito window, **new** set of properties (cookie jar/settings/etc.)
* open link in new window - opens a new window which, based on user expection, shares the **same** properties

When in an incognito window/tab:
* open link in new incognito window - disabled, because it would mean creating **new** set of properties
* open link in new window - opens a new **incognito** window which, based on user expectation, shares the **same** properties with the initial incognito window

Well, this kind of sacrifices the language in order to get around a technical limitation (not being able to create a new set of properties for a 2nd incognito window). I am almost sure that people, when seeing grayed "new incognito window" and enabled "new window", will most likely ask themselves why so, since they are in an incognito environment, and they will not think of the technicalities behind it (that opening **new** window will copy the properties of the **incognito** window).

I would also recomend adding a yellow notification bar when opening a new incognito window saying that it shares/doesn't share (when/if this will be available) the cookies/history/etc. with previous incognito windows. Same notification could be used in the "new tab" template for an incognito window.

mircea.bardac:
you have mis-interpreted my comment I believe, you wrote:

"When in an incognito window/tab:
* open link in new incognito window - disabled, because it would mean creating **new** set of properties
* open link in new window - opens a new **incognito** window which, based on user expectation, shares the **same** properties with the initial incognito window"

I was aiming for:
When in an incognito window/tab:
 * open link in new incognito window - share the same state as the parent incognito window
 * open link in new window - opens a new **incognito** window which, based on user expectation, shares the **same** properties with the initial incognito window

(so your first bullet is incorrect, the second bullet is as I was outlining)

I would expand the 2 bullets you have with a third:
 * New incognito windows spawned from a normal window get a new cookie-jar/state-setup

Essentially a regular window spawns a completely new cookiejar (in a 'parent' incognito window), which gets inheritted by all children incognito windows of this 'parent'.

I agree on the state-sharing butter-bar though, that seems helpful.

Under this model, it's impossible to tell by looking at windows whether they share cookies or not. Users would have to keep a mental model of the interrelationship of every open incognito window, all of which would look the same, in order to predict what would happen in any of them.

Invisible state is pretty much always a confusing user experience.

> Under this model, it's impossible to tell by looking at windows whether
> they share cookies or not

Sure, so add a ticker to the window title...

Even putting aside considering pro/cons of having "a ticker in the window title",
another problem is that Chrome doesn't even have window titles.

But the critical reason why all Incognito windows share the same cookies/properties is
to allow/promote Chrome's tab drag-off-and-insert-into any other window.

Fundamentally, Chrome does *not* want to keep one set of cookies into one Incognito
window and its children.  One of Chrome's ease of use and flow features is easily
moving tabs between windows, including Incognito windows.  That's why all Incognito
windows must share one session together.

If one Incognito window and its children have one set of cookies/properties, then
another tab with different cookies/properties cannot be inserted into it.  And I
believe that is one fundamental functionality the Chrome devs are not willing to
restrict.

I think this design document [1] could be a fix for this bug, if a user could create multiple **temporary incognito profiles/identities**

[1] http://www.chromium.org/user-experience/multi-profiles

What if, instead of having the "new incognito window" button, you use the design document that Mircea.bardac posted a link to when handling incognito windows?

For example, in the drop-down menu where you sign on to your profile, have an "Incognito Profile" option. Based on how the design document sounds, wouldn't that be an easy fix to have multiple "Incognito Profiles" up, each with their own cookie jars and colors to distinguish themselves from each other? Each tab within that "incognito profile" would use all the same cookies, but opening 2 or 3 or more "incognito profiles" would be possible as they wouldn't share cookies between them. Furthermore, you could get rid of the current incognito options entirely, making Chrome seem a bit cleaner. It seems to me like it would be a quick fix that would make A LOT of people happy.

I have a few friends (myself included) that would use this feature a lot (and, in fact, initially assumed that's what the incognito windows did. But alas, they regrettably all shared a cookie jar). I have 3 E-mail accounts that I'd love to be signed into at the same time. I've been looking for an easy workaround, but I guess I just have to wait.

Please implement this feature. It seems like it would require minimal work but help make browsing the internet better for a decently sized chunk of people.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

Just to throw my 2c in: this feature would be of great use to web developers as it would allow them to test multiple accounts without flipping between browsers or clearing caches and cookies.

[Empty comment from Monorail migration]

Is anyone from Chrome reading this? Sounds like there's enough support to at least take this out of Won't fix.

Because of this limitation (I can only log into 2 accounts on Chrome), I had to open up Firefox for testing.

We're reading this bug, but we're not going to implement this feature.  Part of designing a product is choosing which features not to implement.  If we implemented every feature under the sun, we'd end up with a bloated product that was pulled in a thousand different directions.

I'm sorry that we're not able to address your use case at this time.  Hopefully the user experience folks will find a better way of addressing your use case in the future.

[Empty comment from Monorail migration]

Folks wanting to test things in multiple accounts will hopefully be better served by our work on true multi-profile support, which is currently ongoing.  This is aimed more directly at this use case and thus is almost certain to make people happier than hacks to incognito mode, which was never intended to be used for such things.

not a security issue. But that can be a good feature. Currently you can operate only two accounts simultaneously using chrome (one from standard window, another from incognito) there is no way to open third session on same server.

[Comment Deleted]

[Empty comment from Monorail migration]

I agree that this is a privacy issue to, since this is not the expected behavior of a "incognito" that shouldn't share any cookies. My coworkers, also web apps developers, agree. We would have expected any of these behaviors:

 - A cookie jar per tab, forcing to open session in each tab, if you don't like it just use regular windows, but this would be very useful for web apps developing.

 - A cookie jar per window, is not as restrictive, and a bit annoying if you need to act as multiple browsers, but, stills good for developing, and you wont have to open a session each time you open a new tab, because within each window cookies will be shared among tabs, and if you need a fresh session, just go and open another incognito window, that would have a new cookie jar.

But instead, we got a cookie jar shared among all windows and tabs of incognito, that's not too incognito, that's almost as annoying as opening several different browsers.

I agree on not merging incognito's tabs between windows, that should be a feature for regular windows only.

[Comment Deleted]

Hello,

There is one potential use case where this could be a "security" issue. I see many people borrowing a friend's computer for a minute and in order to avoid messing with the other person's tabs, they just open an Incognito window, do what they have to do (email, docs, g+, etc.), close the window, say 'thank you!' and go away. Well, if this "friend" prepares a minimized/hidden Incognito window beforehand, they can just wait for you to leave and then access your account(s). A similar problem could happen in internet cafes.

[Empty comment from Monorail migration]

Internet explorer has this implemented since version 8. It's called "new session" and launched from File -> New Session.

Firefox has a bug for this feature request https://bugzilla.mozilla.org/show_bug.cgi?id=463027 and a talk about it https://wiki.mozilla.org/Per-window_Private_Browsing 

Interesting that no one noticed that this behaviour is actually THE expected ONE when the user open a new window and end up logging in with the same credentials from another "private/incognito" window...

But ofcourse, who are we to complain, we are stupid and only the developers/big brother company know what is right for us...?

[Empty comment from Monorail migration]

Put the user first.  If you insist on not supplying the feature that the user asks for (each incognito is a separate cookie space), you are morally required to fix something so that users are not confused about what it is that an incognito window is supposed to do.

Use your imaginations.  "WontFix" is unimaginative.  There is a real problem here, and ignoring it won't make it go away.

+1. For applications of a collaborative nature, web developers need a way to easily have multiple *tabs* open each with a different session. A cookie jar for each tab would be my preference, but one per window would be tolerable.

I bet it would be an eye-opener if the Chromium devs just did a small usability survey on what Chrome users 'expect' Incognito to actually do. The current communication is misleading and as per my mental model, I expect each Incognito window to be an island by itself, not sharing *any* information with *any* other window. This is simpler for my brain to comprehend rather than having multiple Incognito windows with hands in the same cookie jar.

IMHO, switching profiles is a pain - it's much more convenient for me to open a new Incognito window anytime I want to sign-in to my non-primary Google account.

Seems like even the folks who write the Help content are unclear on how this feature works. From the http://www.google.com/chrome/intl/en/more/privacy.html page -
-------------
Managing your privacy in Chrome

1. Incognito mode

When you don't want your website visits or downloads to be recorded in your browsing and download histories, you can browse in incognito mode. In addition, any cookies created while in incognito mode are deleted after you close the incognito window.
-----------

It says *the* incognito window instead of *all*.

This issue also affects localStorage. It is shared among all chromium windows and a separate localStorage is shared among all incognito windows. This makes it impossible to use multiple session or test web apps as multiple users without launching other browsers.

Please consider fixing it or implementing a [SWITCH] that would allow to isolate incognito windows in their own cookie/storage space.

agree with the other posters here.  the idea of multiple incognito windows is a bit of an edge case, but there are very sound reasons the users would like to see isolation between incognito windows (pairing windows to "sessions").  although, i think this use case is more often us geeks trying to test things as multiple users which is not what incognito was really created for.

For testing with multiple accounts, which seems to be the whole point of this ticket, this has been implemented! See http://support.google.com/chrome/bin/answer.py?hl=en&answer=2364824. You can create multiple users and each window will have a different icon to associate it with a specific user. Each user's cookie jar will be isolated from the others.

Just found out about it myself, and it will be super useful for web development. Thanks chrome team!

yeah, but who's going to cleanup the mess after you finish working
with that different user? :)

On 11.10.2012, at 01:48, "chromium@googlecode.com"
<chromium@googlecode.com> wrote:

Since we appear to have 2 use cases here:
1. Average user using incognito mode and being able to easily drag & drop tabs between incognito windows without ever having to know what separate cookie jars even means.
2. Programmer/Web Developer/Advanced user who explicitly wants separate cookie jars for multi-account or web application testing purposes much more than they want the ability to drag and drop said incognito tabs.

A reasonably straight forward solution to the problem is then to offer an advanced option under settings to enable separate cookie jars for incognito windows, with the side effect of disabling incognito tab drag & drop between windows (new window creation could still be supported via cookie jar copying).

This option would be off by default, and left to the user to enable should they so wish.  This way it is up to the user to decide whether they want incognito tab drag & drop more or less than separate cookie jar functionality.

sounds great, 'make it so #2!'.

My 2c.

Right now you can't drop an incognito tab onto a 'regular' browsing window because it doesn't make sense to mix them. With that in mind, why not just make the window the session (for incognito) and stop users from dragging tabs between them?

I think that's a pretty easy to understand rule of thumb, tabs in the same incognito window share a session. ALL non incognito tabs no matter the window share a main session. You can't drag a tab to a different session.

Popups which create a new window are going to have to remember their parent. (I always thought popups should create a new tab anyhow, but that's a different story). I wouldn't want to program this, but it sure would be a useful feature.

[Empty comment from Monorail migration]

i think incognito means the website will not know who you are, what you did.
but if all incognito windows share the same cookie store, when i open the same website in two different incognito windows, it will be able to recognize me.
i don't thinks that's really incognito.

by the way, i think tab dragging is not a problem at all. coz different incognito session can have different subset on the top left icon. just like multiple account. nobody would mess them up.

The significant difference between multiple users and Incognito appears to be extensions. I can carry my extensions from my regular account across to an incognito window - however this is not the case for user accounts, adding extensions to these requires me to sign up for more Google accounts, which is less than ideal.

A command line switch like "--new-incognito" would be brilliant.

Or better yet, how about "--new-session" which could then be used either by itself to create a new regular browsing session, or combined with the existing "--incognito" switch to make a new incognito browsing session.

Considering the plethora of existing command line switches that already do some wild things, it doesn't seem like a stretch to add something like this, which would have such clear utility for developers, advanced users, and regular users alike.


(I join most others here in feeling that the natural expectation is that different incognito windows be independently "incognito", separate from each other. I was surprised when I started seeing ads in my incognito windows for a site that my wife had visited several days ago. A user ought to be able to live in incognito mode all the time and not have to close all windows just to get a new clean incognito session. If the command line switch existed I would use it frequently, but a way to do it through the UI seems called for too.)

I'm -1 for a command line switch, because it's reactive and won't do a thing to help the fact that you didn't even realize you were leaking a private session.

But really even the current behavior would be acceptable with better messaging. If you open a new incognito window, it should give you a banner that says "(N) incognito window(s) already open. Session history will be shared until the last incognito window is closed." Or better yet, as long as the history is tied together, the windows should feel more tied together, so new incognito tabs appear in the most recent incognito window if one is still open, with the option to tear them away or use "New Window" from there if you really want a separate window sharing the same incognito session (which 99% of users won't).

It's hard to fathom any justifiable argument against offering *the ability* to start a new incognito session. I've learned, though, that Google really knows how to dig in their heals; I have little hope Chrome will ever have this common-sense feature.

So for my own use on Windows I wrote a little batch file to do it, and thought I'd share it here. All it does is create a unique folder name (based on the current date+time), launch Chrome using that folder as its "user dir", wait for Chrome to close, and delete the folder.

Here it is:
    @echo off
    setlocal
   
    SET TargetUrl=%1
    IF "%TargetUrl%"=="" SET TargetUrl=http://www.google.com
   
    :TryCreateTempFolder
            :: Create the variable based on the current time
            SET TempFolder=tmp%Date%%Time%
            SET TempFolder=%TempFolder::=%
            SET TempFolder=%TempFolder:.=%
            SET TempFolder=%TempFolder:,=%
            SET TempFolder=%TempFolder: =%
            SET TempFolder=%TempFolder:-=%
            SET TempFolder=%TempFolder:/=%
            SET TempFolder=%TempFolder%
            :: If the folder already exists loop back up
            IF EXIST "%LOCALAPPDATA%.\Google\Chrome\%TempFolder%" (GOTO TryCreateTempFolder) ELSE (md %LOCALAPPDATA%.\Google\Chrome\%TempFolder%)

    cmd /C ""%LOCALAPPDATA%.\Google\Chrome\Application\chrome.exe" --user-data-dir="%LOCALAPPDATA%.\Google\Chrome\%TempFolder%" --incognito --app="%TargetUrl%""

    rmdir "%LOCALAPPDATA%.\Google\Chrome\%TempFolder%" /s /q

I made it launch in "app mode" so the tab bar wouldn't be visible (so as to decrease the risk of inadvertently reusing the session). Take that "--app=" out if you want to be able to see the address bar because, true to form, Google also refuses to offer a command line switch to hide just the tabs (http://productforums.google.com/forum/#!topic/chrome/cuMuY55utKM may look oddly familiar, on an emotional level, to those who have read the current one).

By the way, if you run the batch file you'll notice it leaves a command window open on screen for as long as you have Chrome open. If you're like me you'll want to launch it without that. There are a variety of techniques out there to do so, e.g. http://www.howtogeek.com/131597/can-i-run-a-windows-batch-file-without-a-visible-command-prompt/.

I miss this feature too. As web developer, I often need to test application as multiple users at once. Incognito mode is perfect for this, except I can have only two sessions at once.

The incognito chain proposed in the first comments is a good idea. Each new window opened from the menu has its own cookie jar, tabs within the smae window and detached tabs share the jar. To make apparent that there is multiple standalone instances of incognito window, label with number should be added to top left corner and to the window icon.

Yes, please, ANY of these solutions would be wonderful! It needs to be addressed.

In the mean time, I've improved upon my earlier solution on Windows, #75, and it's frankly very effective for what everyone in this thread wants: you can open any number of incognito instances and they're all independent of each other. Within any instance you can open further tabs/windows and they stay tied to that instance, as you would expect.

I use it all the time, it's my go-to Chrome shortcut now.

Attached.

I'd note that for 'give me a random incognito window' on linux-ish things:

#!/bin/sh
/usr/bin/google-chrome --incognito --user-data-dir=$(mktemp -d) --no-proxy-serve
r  http://example.org > /dev/null 2>&1 &


is perfectly workable as well... created a new 'profile' for the incognito to drop it's things into, spins a new chrome instance and when you reboot all's removed.

For the most common use case described aboe, separation of multiple web app logins for the same web app, there is an already-supported solution that is much simpler than #28 or #75 and perhaps preferable to #81 for some (esp. windows users.)

I use user profiles for this.  I create a new user in chrome, and log in using one account on my main user profile and the other account in the second user profile.  I've tested this and the incognito cookie jars are also not shared across profiles (which is as expected.)

For people with this use case, it has the added advantage that, if you want to keep your cookies and not log in every time, using separate user profiles allows you to do that.

The down side is that on Windows (7) you can't pin separate chrome command lines to the task bar, so you either have to create a desktop icon or start menu icon for your second user profile.  This is exacerbated by the fact that apps you pin to the taskbar have the custom app menu, so you can launch incognito right from there with a right click, but shortcuts on the desktop/menu use the standard windows shortcuts menu, so you can't.  But if you use a second user profile, you may not need incognito.

The command line is similar to #81, but instead of explicitly supplying a new temp dir each time, you use a pre-created directory.  In windows the command line for the shortcuts are
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --profile-directory="Profile 1"

and for incognito

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --profile-directory="Profile 1" --incognito

[Empty comment from Monorail migration]

this is a creative and working solution.  it's also very well written out.
 if i may venture to say, i think the thread may now want to turn towards
the thought of 'wouldn't it be cool if there was a key-combo that could
open new chrome windows with unique profiles.  wouldn't it be cool if that
was built into the system.  from the thread i feel the methodologies are
there to implement this into the base code and the validity of such a
feature seems to have been justified.

no?

@dancecal... you recognize that you use the 'start chromium with a new oddball profile' simply because the 'incognito shares a cookiejar' matter is true, right?

Why should I create random profiles all the time for testing? why can't I just kick out a new incognito window and get a fresh cookiejar?

Exactly. There are a handful of half-workarounds that try to make up for this feature being missing, but the only good solution necessarily has to be built into Chrome. And frankly it's not just a missing feature, it's misbehavior. Ask anyone you know (outside this thread) if they are aware that clicking "New Incognito Window" a second time will share cookies and all other session state with the first incognito window, and 9 out of 10 will be surprised, and rightly alarmed, to learn it. It's a borderline security hole in Chrome.

[Comment Deleted]

Based on the script of #81 I've published a script for Chromium under Linux:
https://github.com/MacWeber/chromium-incognito

Feel free to improve it and push code for Chrome, for example.

Although it's an extension / plug-in and not in core Chromium, MultiLogin has been working quite well for me: https://chrome.google.com/webstore/detail/nccllfnllopfpcbjdgjdlfmomnfgnnbk

It can open new tabs, each with their own cookie jar.

What an unexpected behaviour. I was really confused when discovered this behaviour. I expected new incognito window doesn't share cookies with anyone, including other incognito windows; otherwise it's not so incognito.

"Folks wanting to test things in multiple accounts will hopefully be better served by our work on true multi-profile support, which is currently ongoing."

No. Just no. I want the same extensions, settings, etc. and not bother setting up multiple profiles just to be able to quickly test something unauthenticated or with another user or without cookies (in case the application tracks stuff by cookie, too)

Yep. That "WontFix" is really a pity in this case.

+1

I could not state it better than those already have in this thread.  This behavior is clearly wrong.  Each incognito window should be an entirely separate sandbox, period.

I also support this. I was also surprised by that behaviour today.

+1 I strongly support Eric's statement: "Each incognito window should be an entirely separate sandbox, period."

Why the hell is this actually a debate? Every incog windows should of course be a separate sandbox... Duhhh.

Why in 7 years has this issue not be properly addressed? Ffs.

I support all that have been said - you cannot call this incognito but only for the first window you open. change the name or fix the bug.

Multi profile support does not properly address this issue. I want to be able to test multiple accounts, on the fly without knowing how many, in the same website. I'd expect to be able to open several incognito windows for each. The current state forces each test to be synchronous (I have to close down my incognito windows between each account) in which case I can't directly compare behavior or forces me to create a new Chrome profile for every two new test accounts. This isn't at all the intended purpose of profiles and is a lot of overhead.

Still expect every incognito tab to have their own isolated cookie jar.

Is anyone working on this issue? Or is it being planned to be implemented into Chrome? I would definitely like to have this feature as a web developer as there will be many instances/scenarios where I need to login to my application as different users at the same time.

This issue was Wonfix'ed in https://crbug.com/chromium/24690#c4.

If you want to login to your application as different users at the same time, use Chrome's multiple-profile feature.

> This issue was Wonfix'ed in https://crbug.com/chromium/24690#c4.
And that's why so many other comments pledge to re-open it!

> If you want to login to your application as different users at the same time, use Chrome's multiple-profile feature.


And this is stupid. By using different profiles you need to reinstall/configure extensions etc. This make no sense at all for most of the usecases where one wants separate incognito windows.

The heck. This is an insult to user privacy and usability. Most users would expect all manually opened incognito windows to be completely isolated from each other. "Hiding" this fact is almost malicious. Refusing to implement this feature is on the fringe to be a management driven decision. Well, I guess I finally have to switch to an alternative browser after all.

This isn't what is expected as a user - I expect there to be a complete separation or if this is decided as a 'wontfix' then at least rename the function to "New Shared Incognito Window" which I feel doesn't really make sense at all as a user.

Perhaps Mozilla's release of Contextual Identities will encourage a revisit of this issue.

"With Containers, users can open tabs in multiple different contexts – Personal, Work, Banking, and Shopping. Each context has a fully segregated cookie jar, meaning that the cookies, indexeddb, localStorage, and cache that sites have access to in the Work Container are completely different than they are in the Personal Container."

from https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/

+1  I assumed this was the case, but since it isn't I may have to revert back to a different browser for testing as multiple users.  I really do like Chrome's dev tools, though...

Shocked to discover this today. Not at all what I expected. Very disappointing from a development perspective.

[Comment Deleted]

Current behavior is not what I expected.

It is stated in https://crbug.com/chromium/24690#c4 that changing this "would create a usability issue".

Has it been verified by actual user research (i.e. UX team) that a preponderance of users expect the current behavior vs the proposed alternative?

There are privacy consequences for a user who misunderstands the current behavior.
What is the consequence if the behavior is changed?

Amazing that it's still not fixed!

How about putting a checkbox/button on incognito window where users can choose to share or not share the same cookie jar? Would be good to have some attention over this.

This is incredibly counter-intuitive behaviour and completely breaks the user expectations when opening a "new incognito window". I can't believe this has been known about and reported on for the better part of a decade and yet the team doesn't think it's worth fixing.

When you open "a new incognito window", you should get a window that is god damn incognito. You must have lower iq to expect something else.

One can use `chromium-browser --user-data-dir=/tmp/delmeX` where X is number of incognito window.

This might be helpful for those who can't use any better browser for some reason.

I was also unpleasantly surprised that the Incognito Windows share information. From time to time I tend to forget about this, it's not an intuitive behavior for me.

July 2017 and still this has not been resolved in any way.

My use case is SW development and testing. You need to code->deploy->test in very short cycles, but you might also need to keep alive one incognito window for other purposes (such as checking a secondary email account, as others had stated). In such cases, you cannot be testing aspects where session-isolation is a must.

Probably you can either develop an extension that provides this functionality, or maybe having a Developer Mode setting to enable this mode.

[Comment Deleted]

if you want to log in google services with more then one account,
you DON'T need to use chrome's multiple-profile feature,
this is the link you are looking for:

https://accounts.google.com/login

lol, "by design"...

get a grip, this is ridiculous

I would suggest that how this feature behaves should be configurable. If Google thinks all incognito windows should share the cookie jar that's fine, but it would be great to have the option to allow them to be separated. An advanced setting is probably what's needed here. My need arises from a need to be logged into multiple accounts, and it's not just google accounts but corporate accounts. To make it work for me I literally need to install and use a number of different browsers OR us VMs. This is serious overkill for something that should be so simple and straightforward.

Come on Google, it's time to allow us G Suite admins to admin several accounts at once, I have 15+ domains I need to admin and it's getting really annoying having to constantly log in/log out as well as remember to log out in all open sessions before I log into new ones.

If this is by design then your PDT needs to step up their game and rethink the design...

It would be great to have the option to allow share the cookie jar between all incognito windows.

This would make parallel automated tests via chrome so much easier. I would also argue that it makes sense that each window should get it's own instance of storage (cookies/local/session etc.)

[Empty comment from Monorail migration]

At least one of the Chromium based browsers already has a separate cookie jar for each incognito window: The CentBrowser.

Almost ten years later and Google still doesn't give a hoot about what its users want.

Please, google, give us isolated icognito windows, as the original poster suggested. PLEASE.

TL;DR: There is a painful workaround, to have an independent cookie jar per profile.
https://productforums.google.com/forum/#!topic/chrome/RhZq5hDh2kk
Now, google, tell me, if I just want to do a quick one time test with 20 independent sessions, I am forced to create 20 profiles first, that will hang around in my browser?

Surprise surprise, it's 2019 and this still happens. I just discovered this behavior today; I have to use a bunch of support sites that have terrible java SSO cookies and like one out of three times prevent me from logging in. So I always pop open an incognito window when I have trouble, except today, where I had the same problem in incognito mode. What?! How can an incognito window already have cookies saved in it?? What kind of upside-down world is this where ... oh, there's another incognito window open in the background that I didn't see (because I have bad browser hygiene and open a dozen separate windows sometimes). Wait, WHAT, incognito windows share cookies with each other?! So each window doesn't have a sandbox, but instead, all the windows live in the same sandbox? What?

So, yes, this is completely unexpected behavior. Very disappointing that Google just says, yeah, we know, this is totally counter-intuitive but all you developers can run this crazy long command to spin up an incognito window. Screw the web developer use case, how about the regular user use case, where you would EXPECT. AN INCOGNITO WINDOW. TO. BE. INCOGNITO.

Rather disappointing. I agree with the posters above; the behavior I had intuited was that each incognito window was in it's own sandbox. Since I knew you couldn't drag incognito tabs into regular windows, I had always just assumed you also couldn't drag incognito tabs into other incognito windows. It's laughable that any developer would try to claim that they can't change the behavior because they want to maintain the drag&drop capability between incognito windows, as though that's a more prominent expectation than that separate incognito windows would have separate sandboxes.

Seriously, this is not what users expect.

Well, it's even worse than that. I do NOT have a background Incognito tab (I checked in the chrome Task Manager, there's no "anon tab" in there), yet still the cookies are preserved. I don't think this ever happened before, but in 71.0.3578.98 it happens. :-(

[Comment Deleted]

+1 I strongly support Eric's statement: "Each incognito window should be an entirely separate sandbox, period."

FYI MUltiLogin on the store is spyware and you're fools for using it. There was a version without the spyware that was DMCA'd off the store.

Unfortunately this means that the only option to gain this feature is use Safari (where this is the default behavior of 'private' browsing windows/tabs) or Firefox (using the "Temporary Containers" add-on).

So far as incognito windows are concerned, Chromium handles this feature the worst and there is no practical work-around. Sad.

I was attempting to use multiple incognito windows to sign in as different users for Use-Case testing. And found this shared cookie jar very disconcerting.  At these least,  tab-groups should be in separate sandboxes.

Has anyone been able to confirm whether MultiLogin extension is spyware or not?

This issue was migrated from crbug.com/chromium/24690?no_tracker_redirect=1

[Monorail mergedwith: crbug.com/chromium/107210, crbug.com/chromium/109271, crbug.com/chromium/15632, crbug.com/chromium/29196, crbug.com/chromium/43270, crbug.com/chromium/691632, crbug.com/chromium/69290, crbug.com/chromium/74870, crbug.com/chromium/76242, crbug.com/chromium/82557, crbug.com/chromium/90153]
[Monorail components added to Component Tags custom field.]

Posting from 2024 and I, much like a lot of the people above, also thought separate incognito windows have their own sandbox. +1 to make it so from me.

FWIW, looks like Safari uses a clean slate for EACH Private Browsing window that is opened.  I came across this thread looking for a way to test one application with six different users. I know I could add a new chrome browser profile for each user I wanted to test, but that seemed too cumbersome and a bit overboard. As far as I can tell, session and local storage are kept separate in each Safari Private Browsing window. Hope that helps anyone looking for an alternative for this specific use case