[justinschuh]

Just to add some context, on macOS you can look at the seat-belt policy as a rough analog of for basic sandboxing guarantees, where the fewer exceptions you have the stronger your sandbox is. From that perspective, Chrome's policy has around 1/10th the exceptions of Safari.

* Safari SB policy: https://trac.webkit.org/browser/webkit/trunk/Source/WebKit2/...

* Chrome SB policy: https://cs.chromium.org/chromium/src/content/renderer/render...

And of course, that's before we get into more complex forms of isolation that Chrome implements, such as the sandboxed GPU process, or ongoing work into things like network sandboxing, the macOS bootstrap sandbox, and site isolation (origin-bound renderer sandboxing).

[tptacek]

For anyone following, this is Justin Schuh of the Chrome security team (and co-author of TAOSSA, probably still the best book in all of software security).

Another thing Chrome does out of the box that Safari doesn't is U2F.

Still another is Chrome's industry-leading TLS management, including the pioneering of HPKP and the Chrome/Firefox pin list, and the aggressive policing of the WebPKI CAs.

I've been pretty aggressively terse in this thread, because I didn't even realize this was a live argument anymore. Safari is simply not as secure as Chrome, and it's less secure in ways that are meaningful to normal users.

Again: iOS, different story.

[om2]

The question is a bit complex than a simple reading of these files. Mac OS sandboxing allows dynamic extension of the sandbox, which would not be reflected in the profile (I'd bet Safari does more of this than Blink though). Also, as you mentioned, it's relevant to look at what's factored into separate processes, and how those processes are sandboxed. Safari's Network process has been networked since 2013, so I don't think you can count Chrome's ongoing work to do so as a Chrome advantage.

If you add these things up, the difference in practical effectiveness is not as wide as one might think.

[justinschuh]

I don't keep up too much on Safari these days, so congrats on moving the network stack out of the content process. But looking at the current WebProcess seat-belt policy and what gets initialized, it looks like there's still far too much attack surface relative to Chrome. Things like audio/video capture and other permissioned Web APIs appear to be permitted directly inside the sandbox. And the GPU attack surface alone is a giant vector for escape--plus all the other potential escape vectors posed by that very long list of mach services.

So yeah, the seat belt policies alone aren't determinative, which is why I called them "a rough analog". And it's hard to say what gets pulled in through warmup (which is why we'll be eliminating it with our v2 bootstrap sandbox). Accepting that, it's pretty clear that there's just dramatically less attack surface exposed from inside Chrome's sandbox versus Safari's.

[gok]

(Your links are switched)

edit: they're fixed now

[justinschuh]

Indeed. Fixed now, and thanks for letting me know.