Comments by non-members will not trigger notification emails to users who starred this issue.
All incognito windows share the same cookie jar
Reported by xto...@gmail.com, Oct 13 2009
[not exactly a security bug, more a potential privacy issue which could be improved on]. Currently, Chrome creates a fresh, empty cookie jar when "New Incognito Window" is invoked. This cookie jar will be shared among all incognito windows and tabs, and will only be destroyed when the last incognito window/tab is closed. If found this behavior to be surprising; I would have expected to get a fresh, separate cookie jar everytime I invoke "New Incognito WIndow". In particular, if I were to forget an incognito window (e.g., minimized or on a different desktop), the incognito "session" would survive much longer than I'd expect. At the same time, common usage scenarios within incognito windows require that some "related" tabs/windows share the same cookie jar; e.g. webapps may expect that a popup window they open has the same cookies as the parent window. Strawman proposal: - every time the user selects "New Incognito Window", a new window is opened and attached to a fresh, empty cookie jar. - when a new tab or popup is opened from within an incognito window, it inherits the parent window's cookie jar - one cannot drag a tab from an incognito window associated with one cookie jar onto a window associated with a separate jar (just as today, one can't drag tabs between incognito and regular windows). One can drag a tab between incognito windows associated with the same cookie jar. - possibly, this could be made more apparent by giving incognito windows a separate border color/stripes/checks/plaids for each cookie jar (i.e., incognito windows of the same color share one cookie jar). I suspect though that the coloring won't be necessary; this is the behavior that users might intuitively expect (at least I did).
Nov 6 2010,
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.
Nov 6 2010,
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.
Nov 26 2010,
I think this design document  could be a fix for this bug, if a user could create multiple **temporary incognito profiles/identities**  http://www.chromium.org/user-experience/multi-profiles
Nov 27 2010,
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.
Jan 12 2011,
Issue 69290 has been merged into this issue.
Jan 27 2011,
Would just like to re-up and express my support for the idea of enabling separate cookie jars for each new incognito window. I appreciate the dev's intent of preserving drag-drop between windows, but I think that shouldn't outweigh the option of having n number of sessions possible. Drag and drop tabs are great and should always be protected for the normal browsing experience, but imho incognito is used for specific tasks that would not require that functionality as often - at least not as often as the ability to open multiple sessions as is being requested. Comment 33 is a nice idea, but I don't really have a preference for how this gets implemented. Thanks for all the hard work on... everything.
Mar 4 2011,
Issue 74870 has been merged into this issue.
Mar 16 2011,
Issue 76242 has been merged into this issue.
Mar 29 2011,
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.
May 14 2011,
Issue 82557 has been merged into this issue.
May 18 2011,
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.
May 18 2011,
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.
May 18 2011,
May 31 2011,
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.
Jun 21 2011,
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.
Jul 27 2011,
Issue 90153 has been merged into this issue.
Sep 9 2011,
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.
Sep 9 2011,
I agree on not merging incognito's tabs between windows, that should be a feature for regular windows only.
Sep 22 2011,
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.
Dec 24 2011,
Issue 107210 has been merged into this issue.
Jan 15 2012,
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...?
Jan 15 2012,
Just a +1 on that - I really expected to have different cookies for each Incognito Window that I have opened and was a bit surprised when it didn't turn out that way. Hopefully we will see something similar if this is not going to happen...
Feb 6 2012,
Issue 109271 has been merged into this issue.
Feb 6 2012,
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.
Jun 21 2012,
+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.
Jul 11 2012,
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.
Jul 11 2012,
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*.
Aug 22 2012,
I use incognito as a developer to view my site under development with anon/logged in user. I'd like to be able to have say superuser/normal user/anon user logged in (without popping Firefox or Safari). I guess the correct use case for pr0n mode is "looking at pr0n" not "testing websites" :-) Maybe it would be feasible to make a plugin to support this?
Sep 6 2012,
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.
Oct 4 2012,
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.
Oct 10 2012,
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!
Oct 11 2012,
It doesn't seem that it was their intention to help us in this case when they made users: http://dev.chromium.org/user-experience/multi-profiles . It says nothing about web developers. But I agree, it will do the trick for me. That's what I needed for testing anyway, acting as several users in the same browser. I'll consider this case close. Although I'm not super happy for chromium having ignored us.
Oct 11 2012,
If you need clean jars each time, you can simply delete the users and recreate them later. Also, each user has a separate incognito jar. Is not the best, is not what we asked for, but it does work... sigh. it's ok I guess.
Jan 11 2013,
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.
Jan 11 2013,
sounds great, 'make it so #2!'.
Feb 20 2013,
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.
Mar 10 2013,
Jul 2 2013,
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.
Jul 17 2013,
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.
Aug 26 2013,
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.)
Aug 26 2013,
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).
Sep 8 2013,
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/.
Sep 11 2013,
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.
Mar 10 2014,
Another alternative -- Be able to select, create, and delete a cookie jar / history jar / session jar (any and all levels would be nice..). A new jar could *copy* an existing jar, but then be 100% independent. And of course, just like with the bookmark manager, you should be able to open a jar manager and drag and drop cookies between them. Then, incognito mode can be changed to 'new window / tab with new cookie jar'. There could be an option to delete cookie jar when this window / tab is closed. Or when all tabs using this jar are closed. Then, since jars aren't tied to modes, you can keep them around permanently. You can associate a site with a jar. you can have named windows and bookmark sets that open using a particular jar. And it would be a half skip and perhaps a jump to having third party cookie / history / session / bookmark managers. Well, maybe not bookmarks if this is used for competitive reasons :)
Jun 4 2014,
You are proposing too much complicated solutions which are not required. Just keep it simple, and solution outlined at 29.10.2010 #28 morr...@google.com fits the best. Only exception is that it doesn't have to be communicated to the user at all. At this moment I see two groups of people 1. Don't see any problem with current implementation of incognito behavior 2. SEE problem that cookies in new instances of incognito window are reused. If you implement the outlined behavior where child window from navigated links clones parent's environment then given solution does not influence THE FIRST GROUP and solves problem of THE SECOND GROUP. NO visual interpretation of "what kind of incognito window is present (FRESH NEW or CHILD CLONED ONE)" is required.
Jun 5 2014,
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.
Jun 5 2014,
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.
Jul 5 2014,
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
Jul 5 2014,
Jul 5 2014,
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?
Jul 6 2014,
@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?
Jul 6 2014,
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.
Oct 28 2014,
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.
Oct 29 2014,
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.
Oct 15 2015,
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.
Oct 20 2015,
"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)
Oct 20 2015,
Yep. That "WontFix" is really a pity in this case.
Jan 28 2016,
+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.
Feb 4 2016,
I also support this. I was also surprised by that behaviour today.
Feb 16 2016,
+1 I strongly support Eric's statement: "Each incognito window should be an entirely separate sandbox, period."
Feb 16 2016,
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.
Mar 15 2016,
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.
Mar 16 2016,
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.
May 4 2016,
Still expect every incognito tab to have their own isolated cookie jar.
May 12 2016,
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.
May 13 2016,
This issue was Wonfix'ed in Comment 4. If you want to login to your application as different users at the same time, use Chrome's multiple-profile feature.
May 14 2016,
> This issue was Wonfix'ed in Comment 4. And that's why so many other comments pledge to re-open it!
May 14 2016,
> 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.
Jun 5 2016,
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.
Jun 9 2016,
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.
Jun 16 2016,
Perhaps Mozilla's release of Contextual Identities will encourage a revisit of this issue.
Jun 16 2016,
"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/
Oct 6 2016,
+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...
Oct 21 2016,
Shocked to discover this today. Not at all what I expected. Very disappointing from a development perspective.
Nov 15 2016,
Current behavior is not what I expected. It is stated in comment 4 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?
Dec 7 2016,
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.
Jan 13 2017,
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.
Mar 31 2017,
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.
Apr 5 2017,
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.
Jul 18 2017,
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.
Jul 18 2017,
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.
Aug 15 2017,
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
Oct 18 2017,
lol, "by design"... get a grip, this is ridiculous
Oct 19 2017,
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.
Nov 17 2017,
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...
Dec 27 2017,
It would be great to have the option to allow share the cookie jar between all incognito windows.
Mar 9 2018,
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.)
Apr 12 2018,
Issue 691632 has been merged into this issue.
Apr 12 2018,
At least one of the Chromium based browsers already has a separate cookie jar for each incognito window: The CentBrowser.
Jun 22 2018,
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?
Jan 14 (3 days ago),
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.
Today (13 hours ago),
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. :-(
Showing comments 31 - 130 of 130 Older ›
Sign in to add a comment