Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: