> Chrome devs believed it should happen in the engine (Webkit), whereas Safari devs believed it should happen in the end browser (Safari).
No, that's actually pretty much backwards. Chromium believed the sandboxing should happen at the browser level, with WebKit communicating to the trusted chrome process via the "WebKit port" named "chromium", which is basically just a set of IPC hooks that expect to be talking to Chromium on the other side. WebKit2 was designed to bring both the trusted and untrusted parts of the project under the WebKit umbrella, and as a result it had tighter integration.
The Blink fork has made this less of an issue, since now chrome and content code are under single repositories (Chromium and WebKit) in both projects. However, you still see evidence of this all over the place. For example, Blink's content code largely follows WebKit coding style as opposed to the chrome code which follows Google's corporate style, while WebKit's coding style is unified for both chrome and content.
No, that's actually pretty much backwards. Chromium believed the sandboxing should happen at the browser level, with WebKit communicating to the trusted chrome process via the "WebKit port" named "chromium", which is basically just a set of IPC hooks that expect to be talking to Chromium on the other side. WebKit2 was designed to bring both the trusted and untrusted parts of the project under the WebKit umbrella, and as a result it had tighter integration.
The Blink fork has made this less of an issue, since now chrome and content code are under single repositories (Chromium and WebKit) in both projects. However, you still see evidence of this all over the place. For example, Blink's content code largely follows WebKit coding style as opposed to the chrome code which follows Google's corporate style, while WebKit's coding style is unified for both chrome and content.