I like chrome, especially the incognito mode. The only thing I don’t like about it is how incognito is essentially a temporary profile.That means all of the incognito windows share the same cookies and temporary history and cache. This is great but is not what I want all of the time. Sometimes I want to sign into two separate Google accounts both in incognito for example. Since the cookies are shared this is not possible.
What I want are:
- A temporary profile that uses the default new state. It will also be deleted when the chrome process is terminated.
- Independent incognito windows – i.e. each has their own cache/history/cookies etc.
- Independent process trees.
So here is what I came up with:
:: Get a random name and remove the : in time
:: Remove the . in the time
:: Set the chrome home directory
:: Set where Chrome is
start /B /WAIT %CHROME_PATH% –user-data-dir=”%CHROME_USER_DATA%”
rmdir /S /Q “%CHROME_USER_DATA%”
Basically, what we are doing is generating a new temporary directory name and then asking Chrome to use that directory as the “User Data” directory. I use /WAIT to wait until the process is terminated, at which point the script deletes the temporary directory.
Here are some more notes:
So there seems to be one way of fixing this which is to create a new profile. This works fine in most cases except that the profiles are persistent. The good thing about profiles is that each profile can have a different set of extensions as well. In this way you can enable the plugins in one incognito profile but still have no plugins in another.
But still there seems to be some persistence problems with incognito, like the url history seems to be connected with the parent process’s history (doesn’t seem to make sense but that is what I see – type in an address in the normal window and it is suggested in incognito.) Who knows what else is connected.
Furthermore, all of the profiles use the same process tree – i.e. parent Chrome process. What this means is that the same start command with /WAIT won’t work with the –profile-directory parameter to issue a new profile directory because chrome will simply open up a new sub-process in that profile and return. When that happens you can’t delete the directory because Chrome is using it. In fact, you can’t delete the directory until the parent process has terminated. This effectively makes the rmdir command useless.
Another problem with the profiles is that there are some metadata information that is left behind. For example look in “Local State” inside the “User Data” directory. Once again the create a temporary profile and delete the folder method above won’t work because we didn’t remove the metadata.
As it turns out the user-data-dir parameter does some magic in the background and if the “User Data” directory is different it will start a completely new Chrome process tree. Since we are starting a whole new User Data structure, we don’t even have to worry about the profiles, just use the default profile and then it will get cleaned up when we delete the directory.
Now, there is probably a much easier way to achieve these goals – especially because running a batch script leaves the CMD window floating around – but this seems to be working fine for now.