top | item 14552186

(no title)

mikeecb | 8 years ago

One of the reasons the Chrome browser uses one process per tab is so that memory between web-pages is isolated. By doing this, an attacker in control of a renderer process cannot read data from another renderer process (web-page).

It seems like Firefox has made a security / memory tradeoff here since renderer processes can render multiple (4 by default) web-pages at a time.

discuss

order

teraflop|8 years ago

Chrome doesn't strictly follow the one-process-per-tab rule either. If you browse for a while with a bunch of tabs open, and then check Chrome's Task Manager, you'll see that it's quite common for a single process to render tabs from multiple different domains.

thnhtnhnhn|8 years ago

Correction: Firefox doesn't use n content processes which render 4 tabs each. By default, it uses 4 content processes which share the task of rendering your n tabs. (AFAIK, at creation time, each tab is assigned one of those rendering processes.)

chimeracoder|8 years ago

> One of the reasons the Chrome browser uses one process per tab

Chrome does not use a process per tab. It uses a process per domain (mostly), unless you middle click a link in which case it always shares the same process as the original tab.

bzbarsky|8 years ago

> It uses a process per domain (mostly)

No, that's not quite right. What they do really is closer to proces-per-tab (with some complications around cross-site navigation) unless you have more than some number of tabs, in which case they will just have them share processes. See https://www.chromium.org/developers/design-documents/process... and note that the default is to put multiple "independent" instances of the same site in different processes, even though they're same-domain. What you're describing is the non-default "Process-per-site" model.

> unless you middle click a link in which case it always shares the same process as the original tab

I believe they changed that behavior starting with Chrome 60. See https://codereview.chromium.org/2680353005/ which talks about ctrl-click, but I would assume (watch me turn out to be wrong!) that middle-click takes the same codepath.