In Chrome, every tab is its own process. Yet, logging in to a site, say, Facebook, persists across tabs. For that matter, in many cases, it persists across OS reboots. This seems inherently very very insecure, but I'm just wondering, how is Chrome implementing this? The reboot thing in particular means it is storing something like a session token even after the process is terminated, which allows seamlessly reconnecting, already authenticated, with secure sites.
With a cookie!
Chrome, like any other browser, is storing a cookie in your file system. Those cookies are what enable you to reconnect automatically to some site. Since it's in your file system, even if you reboot they will still be there. Multiple processes or not is irrelevant here.
Then you might wonder, if the cookies are in my file system, does it mean that any page can access them?
No. Only the page for which the cookie was created can access it. The one that enforces this policy is your browser. If your browser is doing its job correctly then you are ok since it will only send the cookie to the right site (server).
You can also access the cookies directly by looking at the file system, but for that you need to have access to the operating system. Webpages don't have access to that hence the browser is doing that job for them and only gives them the cookies they should be able to read.
You need to protect your cookies. Stealing your cookies is nearly the same as stealing your password/username. If someone or something, like a virus, steals the cookies residing on your computer, it can impersonate you on that website if you are currently logged in.
You can check, edit and add cookie with tool like firebug. So, if you want to mount a fake attack you can :
You will then be logged into that website in firefox as well as in chrome. This is a simplistic version of the hack session hijacking. You could transfer the cookie onto another computer if you want to.
From this page: http://blog.chromium.org/2008/09/multi-process-architecture.html
And from the section about Renderer tabs:
I'm assuming the "interactions with the disk, network, user input" part includes session cookies and such like.
First, in specific to Google Chrome you will find This article very useful. CullenJ mentioned before that Chrome uses processes not threads, but that is untrue. It uses both. According to the article linked above Chrome uses a thread to handle SQlite database operations and gives the example of cookie operations so we can assume that Chrome stores cookies in a SQLite database somewhere.
Now let's take a look at the following quote:
So, we know that google uses message passing and we can find more information on it reading about IPC.
If you were wondering what a named pipe is Wikipedia gives this definition:
Now, I would to get one last quote from the documentation dealing with multi process architecture. It reads as follows:
So this may not be how chrome does it exactly (but, you can read further into it following their documentation) but, based on what I've read so far I could implement a browser doing the following:
Now, I must add here that default cookie lifetime is when the browser closes it expires. So, to support across opening and closing the browser the website must tell it to override this lifetime (which many sites do).
Ok, so if a browser overrides its cookies lifetime then it is stored in the database (yes, on the file system) and will be read again when you go back to this site. Is it insecure to store it there? No, not if your computer is not compromised and that the OS is doing its job properly.
As a side note, operating systems have come along way in detecting and blocking attacks.
As far as going to another browser, they all do similar things for cookie storage and if it bothers you that much either use Chrome's Incognito mode or see this documentation which states: