[tptacek]

This is great, but unfortunately, until Apple ups its browser security game, Safari is a non-starter. On macOS, switching from any other browser to Chrome is in the top 3 things you can do to materially improve your security in ways that actually matter in the real world.

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

[om2]

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.

[justinschuh]

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

[om2]

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.

[gok]

(Your links are switched)

edit: they're fixed now

[justinschuh]

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

[yladiz]

Can you give specific examples why Chrome is significantly better than other browsers, including Firefox, Opera? Chrome is a non starter for me because of its resource usage and battery hunger.

One specific area where Safari is better than Chrome is in private browsing mode. In Safari, each tab is completely separate, and the cookies aren't shared (as far as I can tell) whereas in Chrome, it's only separate as a whole "private browsing session." They each have their pros/cons but I prefer Safari's model.

[M4v3R]

Me too, I only use chrome for its built-in Flash support when a site requires it.

[moogleii]

Even then, I use Safari. The single-use permission request is handy. I pretty much only use Chrome as a development tool.

[dfischer]

How is Chrome more secure than Safari on macOS?

[tptacek]

If you're interested in a detailed answer, read this:

https://medium.com/@justin.schuh/securing-browsers-through-i...

Then try to work back either Edge's or Chrome's approach to security to specific Safari features and design.

The Chrome security team is probably the most sophisticated software security team in the industry (lest you think I'm in the tank for Google, I'd say the iOS platform security team is a close 2nd --- and, to be clear: Safari is a different story on iOS).

[AlexandrB]

> The Chrome security team is probably the most sophisticated software security team in the industry

Unfortunately the Chrome security team can't provide the kind of security I care about - security from Google's tracking.

[tptacek]

If you don't have the kind of security Chrome provides, then in reality everyone can track you, because all they have to do to own up your machine is get you to look at a web page.

[AlexandrB]

So you're saying that privacy is impossible?

If that's true, then I'd rather go down fighting (no matter how futile that is) than willingly give up any more private information to Google. I think the time for pragmatism when it comes to privacy is long over.

[tptacek]

I'm saying what I said: if your browser isn't adequately secure, all the anti-tracking features don't much matter, because the people you really need to worry about will be able to own up your entire machine and quietly persist themselves into it.

[kartickv]

Unless Google can track you better when you use Chrome, that's not an argument against using Chrome.

[om2]

Google can indeed track you better when you use Chrome, since Chrome doesn't have Safari's default-on tracking protections.

[om2]

This post has lots of info about Chrome and Edge RCE defenses. Super informative on this front. But is surprising light on detail about what makes their sandbox more robust than Edge's. (I don't know near enough about the Edge sandbox to assess this claim for myself.)

[cylo]

I am curious to know why you say this considering Safari is just as sandboxed as Chrome?

[tptacek]

No, it isn't.

[om2]

Safari sandbox isn't identical to Chrome's but it's pretty effective. I don't think your statement is a fair one without qualification.

ETA: we'd appreciate info about specific info wrong with Safari's sandboxing. We are definitely looking to improve it.

[tptacek]

You work on the Apple Safari team. Are you really saying you feel like Safari's sandbox and anti-exploit features are comparable to those of Chrome? That would be a newsworthy claim.

[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?

[dkonofalski]

Oh ok.

[moogleii]

http://news.softpedia.com/news/Safari-5-1-Protects-Users-wit...

[tptacek]

Just because both features are named "sandbox" doesn't make them equivalent; the exact same argument says you should also be happy to run hostile Java applets, which, after all, are sandboxed.

[moogleii]

Oh, now you use your words?

[9935c101ab17a66]

You make this claim over and over again and then double down on it when pressed (you literally call Chrome and macOS Safari "incomparable"), but you fail to provide any reason or evidence to support your claim and instead always insist on counter-evidence. When pressed (further down in this comment thread), the only thing you share is this vague idea that Apple isn't incentivized to make Safari secure on macOS. You also compare Safari/Chrome sandboxes several times after declaring them incomparable.

You then, unprompted, create a comparison of all the major browsers again with no citations or supportive reasoning.

It's all very strange.

[ocdtrekkie]

While I'm not sure how effective they are on OS X, I have a hard time agreeing with any suggestion that Chrome is anything but the worst possible option for browser security right now. Chrome's official extension store is full of malware which collect not just your browsing data, but the contents of every page you view, and Google has shown almost zero interest in policing it. And a large percentage of malicious websites are designed to get users to install these malicious extensions.

Chrome may be relatively decent at preventing a webpage from compromising your OS, but in the modern era, a compromised browser is as bad or worse anyways, since that's where most of your sensitive activity goes.

While many HN readers will know to avoid the perils of this crud, I don't feel Chrome can be recommended over IE6 to the wider Internet while this remains so commonplace. Safe use of Chrome requires constant vigilance.

In light of Chrome's issues, I feel like a claim that switching to Chrome is important for security to require an exceptional evidence of vulnerability in the other browser.

[euroclydon]

So battery life or security, take your pick?

[tptacek]

I'm not saying it doesn't suck. But it's going to keep sucking as long as people are willing to pretend that Safari already has comparable security to Chrome.

[MBCook]

Then why not fix the horrendous browser performance of Chrome? It's not like people's complaints about how much energy it uses relative to Safari are new. People have been complaining for YEARS.

According to another comment you work on the Chrome team. So unlike most everyone here, you're actually in a position to fix one of the two options.

[tptacek]

(a) I do not work for Google or on Chrome.

(b) I do not disagree about Chrome's energy usage. It sucks.

[MBCook]

Well that's what I get for trusting random commenters.

[dmix]

Do they even try to break Safari at those pwn2own events?

Or is it just assumed to be an easy target/too niche/no money from Apple?

[om2]

They do. Breaking out of the sandbox is not trivial though over time people have found ways to do it.

[JumpCrisscross]

What are the other two (for macOS)?

[QuinnyPig]

"Use a password manager, enable MFA" unless I miss my guess.

[wolf550e]

I guess password manager and U2F yubikey.

[tptacek]

I'd combine those two, and then my #3 would probably be making sure that you can't easily click on things in emails that open documents in local applications, and my #4 would be some combination of FDE and encrypted DMGs for projects and sensitive files.

[tobr]

I didn't know that. What are the specific security problems with Safari?

[draw_down]

Fair enough, it's not exactly a security play though.