4 ms·

"WebKit does have a Linux sandbox, but it’s not any good, so it’s (rightly) disabled by default." I'd love to know more about why, that seems mad in 2016.

creshal 11y ago
Disabling a broken feature, or not fixing it? The latter is easily explained: Webkit (especially on Linux) is woefully short of manpower now that Google et. al. have pulled out of it. I'll call myself lucky if WebkitGTK doesn't crash on any of the Alexa top 100 any more.
- josteink 11y ago
  Just in time for Emacs, XWidget support and Webkit embedded in Emacs then. And here I thought we'd finally get a quality browser-engine for our OS. Seems we'll have to wait some more :)
  - creshal 11y ago
    Chromium Embedded Framework (used by e.g. Qt, Android, and browsers like Vivaldi) is okay, and Servo (Mozilla's new rendering engine in Rust) is aiming to be API compatible to it. Seems it's where we're headed for now.
madeofpalk 11y ago
My (very brief and shallow) understanding of one thing that may contribute to the problem was a disagreement of where the sandboxing took place. Chrome devs believed it should happen in the engine (Webkit), whereas Safari devs believed it should happen in the end browser (Safari). So IIRC, Webkit doesn't really have first class support for sandboxing as Apple has 'their own' sandboxing built into Safari. Of course, I'm likely to be completely wrong. I remember this being brought up back when the Webkit/Blink fork happen, and in my recent brief search I haven't been able to find any sources again.
- pcwalton 11y ago
  > 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.

creshal 11y ago

Disabling a broken feature, or not fixing it? The latter is easily explained: Webkit (especially on Linux) is woefully short of manpower now that Google et. al. have pulled out of it. I'll call myself lucky if WebkitGTK doesn't crash on any of the Alexa top 100 any more.

josteink 11y ago
Just in time for Emacs, XWidget support and Webkit embedded in Emacs then. And here I thought we'd finally get a quality browser-engine for our OS. Seems we'll have to wait some more :)
- creshal 11y ago
  Chromium Embedded Framework (used by e.g. Qt, Android, and browsers like Vivaldi) is okay, and Servo (Mozilla's new rendering engine in Rust) is aiming to be API compatible to it. Seems it's where we're headed for now.

madeofpalk 11y ago

My (very brief and shallow) understanding of one thing that may contribute to the problem was a disagreement of where the sandboxing took place. Chrome devs believed it should happen in the engine (Webkit), whereas Safari devs believed it should happen in the end browser (Safari). So IIRC, Webkit doesn't really have first class support for sandboxing as Apple has 'their own' sandboxing built into Safari. Of course, I'm likely to be completely wrong. I remember this being brought up back when the Webkit/Blink fork happen, and in my recent brief search I haven't been able to find any sources again.

pcwalton 11y ago
> 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.