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.
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.