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.
The network stack has been out of the content process for a super long time, it is not a new thing. (Ironically, Chrome engineers argued strenuously against doing it when we first started).
You're right that separate GPU process is a huge advantage for Chrome. Kudos on that, and we'll likely have to move in the same direction sooner or later.
Audio/video capture is temporary and not in currently shipping Safari. It was just the simplest path to getting WebRTC up and running. We plan to fix it before we ship. I agree with you that it's risky attack surface.
Also agree with you that we expose more mach services and for lots of them it would be better not to expose them. A tradeoff here is that Chrome (as I understand it) provides most of those facilities via brokers that are often not sandboxed themselves. It used to be many of those things were just done by the application process.
I suspect over time we'll see our respective sandbox models become more similar over time, especially on macOS.
> The network stack has been out of the content process for a super long time, it is not a new thing.
FWIW, Chrome's network stack doesn't live in the content process either. It's not currently sandboxed, but it's in a process that has no scripting runtime or other dynamic content, so it's still pretty high bar for exploit. The exact reasons for the current situation have to do with some legacy Windows support that has since been removed, which is why the sandboxing work is now moving forward. So, I definitely appreciate your situation with adding some sandbox exceptions for WebRTC.
> I suspect over time we'll see our respective sandbox models become more similar over time, especially on macOS.
Fair. But I will say that Chrome being cross-platform tends to naturally push us in the direction of eliminating sandbox attack surface. Our supported platforms just differ so much that it's easiest to lock down the OS as much as possible and implement narrower, origin-bound capability brokers inside Chrome. If I were more tightly bound to a given OS implementation, I expect I'd have a lot more fights about sandboxing, because it's easier for devs to just standardize on what the OS gives you.
It does seem like being cross-platform makes it more natural for Chrome to lock down the content process very tightly, and provides a strong incentive to do so. On the other hand, it may make it more difficult or less natural to lock down some of the other processes.
On our end, it's natural to sandbox every new process we introduce, but also easy to fudge what is allowed in sandbox profiles. Sometimes we have a choice of accessing a service through a separate process, or working to make sure that service itself is more secure (sandboxed itself, offers thinner and properly validated IPC interface, etc). In many cases, the real right choice may be to do both. As well as fuzzing the heck out of every IPC boundary.
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.