2 ms·
> ... 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
by 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 agoSure, 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 agoI'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.
- pcwalton 12y agoThat would break the Web, because you would introduce data races into JavaScript. (Think about the granularity of synchronization on the objects you would need.)
- justinschuh 12y agoLayout and compositing need to be cross-origin; the Web implicitly allows cross-origin resource loads; and (as was raised above by pcwalton) browsing contexts like windows and frames need to function as if they're running on the same thread and can potentially be shared. All of that is to say that all of the potentially shared state makes it extremely difficult to bind a web origin to a process for security purposes. It's a hard enough problem that a team of Chrome engineers has been working on it for a few years, and are only now approaching an alpha implementation.* And that's many years after Chrome was entirely multi-process with sandboxed web renderer processes. * http://www.chromium.org/developers/design-documents/site-isolation http://www.chromium.org/developers/design-documents/site-iso...