[om2]

Safari's sandbox is weaker in some ways and stronger in others. Saying which is overall stronger would be a judgment call. I wouldn't make a claim like that without spelling out at least some of the details.

This subthread is about the sandbox so I'm not sure why you threw in "and anti-exploit features". I'd probably say without qualification that Chrome has better memory corruption mitigations.

I hoped you might have concrete feedback on what aspects of our sandbox we should shore up. We have our own ideas but of course an informed outside view would be valuable.

[tptacek]

In what ways would you say the Safari sandbox is stronger than Chrome's, on macOS?

How would you compare Safari's anti-exploit technology (allocator hardening, Javascript engine hardening, &c) to that of Chrome? Do you think you do anything better than Chrome does on that front?

[om2]

Your original post here made a bold claim with no qualification and no supporting details. You're not providing any backing to your claim but at the same time you're asking me to give details. Plus you've repeatedly thrown in anti-exploit tech which wasn't the original point of contention.

It would be easy to get the impression that you're trying to shift the burden of proof and move the goal posts. Despite this, I will try to assume good faith.

I think you original post gave the impression that Safari either has no sandbox, or has a wildly ineffective sandbox. You didn't directly state it, but at least some users understandably took away that implication. I think this is inaccurate and unfair.

One piece of evidence we have is grey market prices for end-to-end Safari exploits (with full sandbox escape). By this metric, breaking out of our sandbox on Mac or iOS is not trivial, and is at least comparable in difficulty to Chrome or Edge on Mac, Windows or Android. On the flip side, it seems to be significantly easier to get inside-the-sandbox remote code execution in Safari if you go by market prices, hacking contests, etc. That's something we're working on. Chrome and Edge definitely have materially better mitigations here (as I said in my earlier post).

And finally, to answer your question: One small way Safari has better sandboxing is the we sandbox our network process (something that Chrome is still working on).

[tptacek]

My contention was that Safari is less safe than Chrome, not that Safari's sandbox was in particular worse than Chrome's. Nevertheless, on balance, Safari's sandbox is significantly worse than Chrome's. I think --- but you'd know better than I would --- that this is because browser security is a platform problem for Apple, and an application problem at Google. Apple's platform-level mitigations are very powerful on iOS, but substantially less powerful on general-purpose operating systems. Chrome's sandboxing is specific to Chrome itself, and thus finer grained and more powerful.

I think if you create a breakdown of all the facets of browser security, it will look something like this:

Isolation: Chrome > Edge | Safari > Firefox

Anti-Exploit: Edge > Chrome > Firefox > Safari

UX: Chrome > Firefox > Safari > Edge (U2F, password manager)

TLS: Chrome > Firefox > Safari | Edge

Library Security: Chrome > Edge > Firefox > Safari

If you want to add privacy controls here, you'll get an easy win for Safari, but privacy isn't security.

You're close to this stuff though, so if you disagree with any of these informal rankings, or think I've got the rankings wrong, please correct me.

[om2]

You actually did make a claim that Safari's sandbox was in particular worse than Chrome's, in the post I directly replied to. That is what got my dander up. Elsewhere you implied that the Safari sandbox comparable to the Java sandbox. I hope you will now agree that the Safari sandbox is closer to Chrome's than to Java's.

I don't know enough about the full spectrum of security technologies in all the browsers to have an informed opinion on your rating scorecard, but some thoughts:

Your assumption is that browser security is (only) a platform problem for Apple is wrong. If that was true, we wouldn't have dedicated sandbox profiles for the WebKit content process and its various helpers, which are much tighter than the system default app sandbox on both macOS and iOS. All, macOS has significant system-level defenses, though obviously not as strong as iOS.

Safari and Chrome both use the same underlying OS facilities on macOS to implement their respective sandboxes, so I don't think it's right that "Chrome's sandboxing is specific to Chrome itself" to any greater than Safari's (or really, WebKit's). It's also not more fine-grained. My understanding of the Chrome sandbox model is that their ideal is to deny everything, based on designing around the very coarse grained mechanisms in Windows. The macOS/iOS sandbox model is intrinsically built around fine-grained permissions, and Safari grants more of them to our content process. So if anything Safari's sandbox is more fine-grained (but I am not sure this is an advantage).

On the scorecard itself:

- It's really hard to compare sandboxing technologies across platforms. My vague impression is that Safari's is stronger than Edge's and macOS Chrome has perhaps a small overall edge over macOS Safari in terms of effectiveness. I'm also not totally sure you can even do a linear ranking. For instance, only Edge puts their JIT outside the content process, but I am not sure this means they have the strongest sandbox overall.

- Anti-exploit: agree with the top two, not sure I'd put Firefox over Safari.

- UX: I'm not totally sure how you are grading, but you should be aware that Safari has a really good built-in password manager. Passwords are securely stored in Keychain and we offer to generate random per-site passwords at account creation or password change time. I don't even know the vast majority of my website passwords. With iOS 11 this will be expanded to sharing website passwords with corresponding native apps for those sites, removing the main remaining reason to have a simple password.

- TLS: Not knowledgable enough here but note that we're moving to boingssl in the upcoming OSes and have cert pinning and HSTS and all that good stuff.

- Library security: not entirely sure what you mean by that.

I broadly agree with Justin Schuch's point in the post you linked that isolation technologies are more important on a philosophical level. Also I would give kudos to Chrome and Edge for having excellent overall security.

[tptacek]

Sorry for the delayed response. Also: I have to be terse about some of these things for work reasons.

First, regarding isolation: using the same OS facility to block system calls is a superficial similarity between Chromium and Safari. Chromium and Safari are divided into process components differently, and block different system calls. Chromium exposes much less to its renderer process than Safari does to WebProcess. Not only that, but Chromium has finer-grained components; the GPU isn't exposed to Chromium renderers the way it is to Safari WebProcesses. This isn't a theoretical difference, as you know (but readers here don't): IOKit has been a source of WebProcess sandbox escapes for Safari. Safari isolates the network process and Chrome doesn't, but the network process is a low-priority attack surface. The highest priority attack surface is the one reachable directly from content-controlled Javascript. You say Chromium's edge over Safari is "small overall". We agree that the edge exists, but I strongly disagree that the delta is small.

We agree on anti-exploitation. In fact, if Safari got better here, I'd be less nervous about people running Safari. What are the plans here? The combination of (1) general purpose operating system, (2) rich attack surface exposed to WebProcess, and (3) lack of serious runtime hardening is most of my argument against using Safari. The rest of this list is "nice to have" stuff.

Regarding UX: Chromium has a well-regarded security UX team. Does Apple staff a dedicated security UX team for Safari? Chromium supports U2F natively. When will Safari? I think Chromium, Safari, and Firefox are closer together here than the browsers are on other facets of this list; I don't think Safari does a bad job here, just not as good of a job as Chromium.

Regarding TLS: Adopting Google's BoringSSL library is a fine start and I know Apple has strong crypto people on the Secure Transport team. But does Safari support HPKP? (If so, when did that happen?) Why is it virtually always Google's TLS team detecting and punishing rogue CAs? What CA BR violations were detected by the Safari team, or any other team at Apple? Has Safari done anything like the Google PQ handshake experiment? It feels a little unfair holding Apple to the standard of what is basically the most sophisticated Web PKI team on the planet, but that's a real part of browser security.

Regarding "Library Security": I don't know what to call this item and so I'm not surprised that you're confused, but: how does Apple's work fuzzing and doing vulnerability research in the underlying libraries that the browser depends on compare to Google's work doing the same thing? I think we both know the answer: nothing Apple is doing is close to what Google's in-house offensive researchers are doing. Apple benefits from the work Google does here and so can draft off Google's team here, but Google prioritizes their in-house offensive work to help Chromium.

I could make a similar scorecard for iOS versus Android and I think you'd see the reverse on these rankings, with Apple in the lead on basically everything. But browser security isn't hardware security, and on macOS, I don't think Safari and Chrome are close. I think Chrome is significantly more secure.

[euyyn]

> note that we're moving to boringssl in the upcoming OSes

Could you give more details on these plans?

[9935c101ab17a66]

I know your replies here are probably somewhat aggravating and definitely time-consuming, but I appreciate your level head and the detail and information you provide. I don't have a complex understanding of any of these technical details and you explain things in a clear and concise way.

[nthuser]

Why don't you first answer the question that was asked?.