4 ms·

I'm really glad Mozilla has been working on this. A lot of comments here talk about UI responsiveness being the key benefit, but another huge win is that it li

by jude- 12y ago

I'm really glad Mozilla has been working on this. A lot of comments here talk about UI responsiveness being the key benefit, but another huge win is that it limits the damage a browser zero-day can do. With this model, a compromised tab will no longer be able to directly read the contents of other tabs, since the other tabs live in separate address spaces. This of course assumes a compromised tab can't go on to compromise the browser kernel (i.e. the process that manages tabs and shared tab state) or trick the kernel into giving it unauthorized data from other tabs. However, formally verifying that a kernel implementation prevents this is feasible in practice [1]. [1] http://goto.ucsd.edu/quark/ http://goto.ucsd.edu/quark/

pcwalton 12y ago
> With this model, a compromised tab will no longer be able to directly read the contents of other tabs, since the other tabs live in separate address spaces. ... assuming those tabs are cross-origin. > This of course assumes a compromised tab can't go on to compromise the browser kernel Also assumes that a compromised tab can't go on to compromise the OS kernel.
- jude- 12y ago
  > ... assuming those tabs are cross-origin. Not sure why this has to be a condition. Perhaps tabs loading pages from the same origin will both have read/write access to some shared data in the browser kernel (like the site's cookies), but they still run in separate address spaces regardless. A compromised tab won't be able to directly access another tab's RAM, as is the case with single-process browsers. > Also assumes that a compromised tab can't go on to compromise the OS kernel. Very true. However, my argument was that a multi-process model limits (but obviously does not eliminate) the impact of zero-days. In the single process model, the attacker could compromise any tab and have all tab state available with no additional effort. In the multi-process model, the attacker would have to compromise the right tab, compromise a different tab and trick the browser kernel to performing the requisite operations, or somehow bypass the OS's memory protection. Each of these require more work than before.
  - pcwalton 12y ago
    > Not sure why this has to be a condition. Because they can share JavaScript objects.
    - jude- 12y ago
      Sure, tabs can load static assets from a read-only cache instead of re-fetching everything from the origin (be it an in-browser cache run by the browser kernel, or a Web cache somewhere between you and the origin). But surely, the tabs run private instances of the layout engine and javascript VM when they process the page, no? When would it ever make sense for multiple tabs to directly access each other's runtime state?
      - pcwalton 12y ago
        > But surely, the tabs run private instances of the layout engine and javascript VM when they process the page, no? No. For example, you can get direct access to another tab's "window" object in this way, as long as it's same-origin: https://developer.mozilla.org/en-US/docs/Web/API/window.opener https://developer.mozilla.org/en-US/docs/Web/API/window.open... > When would it ever make sense for multiple tabs to directly access each other's runtime state? For Web compatibility.
        jude- 12y ago
        I'm not sure that your example prevents the implementation of per-tab javascript VMs. Wouldn't the browser be designed such that its kernel mediated all tab-to-tab runtime state queries? Then, tabs wouldn't directly access each other's state, and the kernel would interpose security policies (such as same-origin-only requests) between tabs regardless of a tab's behavior. To keep this arrangement transparent to programmers, the tab's javascript VM would map access to shared state (like a window's opener) onto the appropriate call to the kernel, obviating the need for direct inter-tab memory access while preserving compatibility.
        12y ago

by jude- 12y ago

pcwalton 12y ago

> With this model, a compromised tab will no longer be able to directly read the contents of other tabs, since the other tabs live in separate address spaces. ... assuming those tabs are cross-origin. > This of course assumes a compromised tab can't go on to compromise the browser kernel Also assumes that a compromised tab can't go on to compromise the OS kernel.

jude- 12y ago
> ... assuming those tabs are cross-origin. Not sure why this has to be a condition. Perhaps tabs loading pages from the same origin will both have read/write access to some shared data in the browser kernel (like the site's cookies), but they still run in separate address spaces regardless. A compromised tab won't be able to directly access another tab's RAM, as is the case with single-process browsers. > Also assumes that a compromised tab can't go on to compromise the OS kernel. Very true. However, my argument was that a multi-process model limits (but obviously does not eliminate) the impact of zero-days. In the single process model, the attacker could compromise any tab and have all tab state available with no additional effort. In the multi-process model, the attacker would have to compromise the right tab, compromise a different tab and trick the browser kernel to performing the requisite operations, or somehow bypass the OS's memory protection. Each of these require more work than before.
- pcwalton 12y ago
  > Not sure why this has to be a condition. Because they can share JavaScript objects.
  - jude- 12y ago
    Sure, tabs can load static assets from a read-only cache instead of re-fetching everything from the origin (be it an in-browser cache run by the browser kernel, or a Web cache somewhere between you and the origin). But surely, the tabs run private instances of the layout engine and javascript VM when they process the page, no? When would it ever make sense for multiple tabs to directly access each other's runtime state?
    - pcwalton 12y ago
      > But surely, the tabs run private instances of the layout engine and javascript VM when they process the page, no? No. For example, you can get direct access to another tab's "window" object in this way, as long as it's same-origin: https://developer.mozilla.org/en-US/docs/Web/API/window.opener https://developer.mozilla.org/en-US/docs/Web/API/window.open... > When would it ever make sense for multiple tabs to directly access each other's runtime state? For Web compatibility.
      - jude- 12y ago
        I'm not sure that your example prevents the implementation of per-tab javascript VMs. Wouldn't the browser be designed such that its kernel mediated all tab-to-tab runtime state queries? Then, tabs wouldn't directly access each other's state, and the kernel would interpose security policies (such as same-origin-only requests) between tabs regardless of a tab's behavior. To keep this arrangement transparent to programmers, the tab's javascript VM would map access to shared state (like a window's opener) onto the appropriate call to the kernel, obviating the need for direct inter-tab memory access while preserving compatibility.
        12y ago