4 ms·

> Don't use Safari. The code is a mess and security vulnerabilities are frequent, but slow to patch. Over the last two years, Safari has had half the vulnerabi

by gok 11y ago

> Don't use Safari. The code is a mess and security vulnerabilities are frequent, but slow to patch. Over the last two years, Safari has had half the vulnerabilities [1] as Chrome [2] or Firefox [3]. Security updates are frequent [4]. As to code being a mess... perhaps there's a particularly offensive part of the WebKit code style guidelines [5] that make them less secure than Blink code style guidelines[6]? [1] http://www.cvedetails.com/product/2935/Apple-Safari.html?vendor_id=49 http://www.cvedetails.com/product/2935/Apple-Safari.html?ven... [2] http://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 http://www.cvedetails.com/product/15031/Google-Chrome.html?v... [3] http://www.cvedetails.com/product/3264/Mozilla-Firefox.html?vendor_id=452 http://www.cvedetails.com/product/3264/Mozilla-Firefox.html?... [4] https://support.apple.com/en-us/HT201222 https://support.apple.com/en-us/HT201222 [5] http://www.webkit.org/coding/coding-style.html http://www.webkit.org/coding/coding-style.html [6] https://www.chromium.org/blink/coding-style https://www.chromium.org/blink/coding-style

rsy96 11y ago
Chrome is subject to analysis by much more people than Safari by virtue of its larger market share and cross-platform nature. In addition, Google pays a great deal for security researchers to actively find bugs in Chrome. I would take the higher number of CVEs of Chrome as a positive sign for its security, in that they are preemptively searching and fixing security vulnerabilities.
- axx 11y ago
  right! Just because there are less known security issues doesn't mean there aren't any.
pcwalton 11y ago
Yeah, I find the claim that Safari "is a mess" compared to Chrome extremely unfair (if not just plain insulting to the WebKit contributors), given that Blink and WebKit are so close to each other. The overall architectures of the two engines are incredibly similar, despite having diverged somewhat over time. As an aside, the number of people who are qualified to speak about the "messiness" of rendering engine architecture is incredibly low.
kriro 11y ago
At the danger of oversimplifying sings severely. While WebKit is open, the rest of Safari is closed source. In this day and age it should be the most common heuristic that you should always prefer more open software over less open (aka closed) software if you have a choice and security matters to you. Sometimes it's not practical (otherwise the advice could simply be "just don't use OSX") but for browsers you do have a pretty decent choice. I haven't exactly measured is but Apple patches for Safari also seem fairly slow compared to Mozilla or Chrome so I agree with that (same argument posted on the github)
- JupiterMoon 11y ago
  But Chrome is also closed source.
  - greggman 11y ago
    Not in any effective way. I'm pretty sure you can take Chromium, replace the logo and branding, compile in mp4 support and drop in the 2 plugins (ppapi flash, and ppapi pdf viewer) and you'll end up with Chrome. No difference
    - JupiterMoon 11y ago
      How do you know? Do you take this upon faith or does google provide reproducible builds?
zurn 11y ago
Do we know that Apple announces (and gets CVEs for) vulnerabilities that they find and fix internally? If not, the comparison is not meaningful.
WA 11y ago
I don't use Safari, not because of privacy concerns, but because 1. I hate the address bar how it partially hides the URL 2. It adjusts colors. Not only for images with an embedded color profile, but many colors defined in CSS are brighter in Safari than in Firefox or Chrome. This messes up my web development.
- wrboyce 11y ago
  For the record, I'm currently using Safari (8.0.8) and the only part of the URL being hidden is the protocol.
- dombili 11y ago
  1. I agree that this can be annoying at times, but you can disable this. Settings > Advanced > Show full website address 2. I have no answers for this one, other than to say that I haven't experienced it.
- deleted 11y ago
  [deleted]
greggman 11y ago
Take a closer look. Let's pick 2014 since it's a full year's data but any year will do Safari: 61 DOS 64 Code Execution 52 Overflow 61 Memory Corruption Chrome 86 DOS 5 Code Execution 28 Overflow 9 Memory Corruption Of those only Code Execution matters AFAICT. That the one where someone owned your machine or at least read everything in ~/.ssh and ~/Application Support. On that Safari is ~13 times worse than Chrome. PS: The numbers don't add up to the total because a single vulnerability can be tagged as causing more than 1 of the issues.
- pcwalton 11y ago
  > That the one where someone owned your machine or at least read everything in ~/.ssh and ~/Application Support. Not if they didn't combine it with a sandbox escape, and Safari is sandboxed too. (The profile is less restrictive than that of Chrome, but both would disallow reading your SSH keys.) Also, counting vulnerabilities like this is pointless, given that the two browsers share a very similar rendering engine and there's a not-insignificant chance that vulnerabilities in one engine apply to the other.
  - greggman 11y ago
    Maybe you should look at how they are architected. There's a HUGE difference in how they operate. In Chrome the code the pages run in themselves can't do anything. Not true in Safari. The two are night and day different. I'm a contributor to both Chromium and WebKit. Sure at some level they share some code. Chrome tho pretty much implements an entire virtual and secured OS in which it then executes Blink. Safari does no such thing for WebKit.
    - pcwalton 11y ago
      > In Chrome the code the pages run in themselves can't do anything. Not true in Safari. The two are night and day different. By "the code the pages run in themselves can't do anything" do you mean that Chrome is sandboxed and Safari isn't? That's not true. WebKit rendering happens in a "WebProcess" which uses the Mac Seatbelt framework for sandboxing. The sandbox file is WebKit2.framework/A/Resources/com.apple.WebProcess.sb. Sure, Chromium's sandbox is more restrictive. It proxies more things out through the broker process. But the difference is a matter of degree, not a fundamental architectural difference.

by gok 11y ago

rsy96 11y ago

Chrome is subject to analysis by much more people than Safari by virtue of its larger market share and cross-platform nature. In addition, Google pays a great deal for security researchers to actively find bugs in Chrome. I would take the higher number of CVEs of Chrome as a positive sign for its security, in that they are preemptively searching and fixing security vulnerabilities.

axx 11y ago
right! Just because there are less known security issues doesn't mean there aren't any.

pcwalton 11y ago

Yeah, I find the claim that Safari "is a mess" compared to Chrome extremely unfair (if not just plain insulting to the WebKit contributors), given that Blink and WebKit are so close to each other. The overall architectures of the two engines are incredibly similar, despite having diverged somewhat over time. As an aside, the number of people who are qualified to speak about the "messiness" of rendering engine architecture is incredibly low.

kriro 11y ago

At the danger of oversimplifying sings severely. While WebKit is open, the rest of Safari is closed source. In this day and age it should be the most common heuristic that you should always prefer more open software over less open (aka closed) software if you have a choice and security matters to you. Sometimes it's not practical (otherwise the advice could simply be "just don't use OSX") but for browsers you do have a pretty decent choice. I haven't exactly measured is but Apple patches for Safari also seem fairly slow compared to Mozilla or Chrome so I agree with that (same argument posted on the github)

JupiterMoon 11y ago
But Chrome is also closed source.
- greggman 11y ago
  Not in any effective way. I'm pretty sure you can take Chromium, replace the logo and branding, compile in mp4 support and drop in the 2 plugins (ppapi flash, and ppapi pdf viewer) and you'll end up with Chrome. No difference
  - JupiterMoon 11y ago
    How do you know? Do you take this upon faith or does google provide reproducible builds?

zurn 11y ago

Do we know that Apple announces (and gets CVEs for) vulnerabilities that they find and fix internally? If not, the comparison is not meaningful.

WA 11y ago

I don't use Safari, not because of privacy concerns, but because 1. I hate the address bar how it partially hides the URL 2. It adjusts colors. Not only for images with an embedded color profile, but many colors defined in CSS are brighter in Safari than in Firefox or Chrome. This messes up my web development.

wrboyce 11y ago
For the record, I'm currently using Safari (8.0.8) and the only part of the URL being hidden is the protocol.
dombili 11y ago
1. I agree that this can be annoying at times, but you can disable this. Settings > Advanced > Show full website address 2. I have no answers for this one, other than to say that I haven't experienced it.
deleted 11y ago
[deleted]

greggman 11y ago

Take a closer look. Let's pick 2014 since it's a full year's data but any year will do Safari: 61 DOS 64 Code Execution 52 Overflow 61 Memory Corruption Chrome 86 DOS 5 Code Execution 28 Overflow 9 Memory Corruption Of those only Code Execution matters AFAICT. That the one where someone owned your machine or at least read everything in ~/.ssh and ~/Application Support. On that Safari is ~13 times worse than Chrome. PS: The numbers don't add up to the total because a single vulnerability can be tagged as causing more than 1 of the issues.

pcwalton 11y ago
> That the one where someone owned your machine or at least read everything in ~/.ssh and ~/Application Support. Not if they didn't combine it with a sandbox escape, and Safari is sandboxed too. (The profile is less restrictive than that of Chrome, but both would disallow reading your SSH keys.) Also, counting vulnerabilities like this is pointless, given that the two browsers share a very similar rendering engine and there's a not-insignificant chance that vulnerabilities in one engine apply to the other.
- greggman 11y ago
  Maybe you should look at how they are architected. There's a HUGE difference in how they operate. In Chrome the code the pages run in themselves can't do anything. Not true in Safari. The two are night and day different. I'm a contributor to both Chromium and WebKit. Sure at some level they share some code. Chrome tho pretty much implements an entire virtual and secured OS in which it then executes Blink. Safari does no such thing for WebKit.
  - pcwalton 11y ago
    > In Chrome the code the pages run in themselves can't do anything. Not true in Safari. The two are night and day different. By "the code the pages run in themselves can't do anything" do you mean that Chrome is sandboxed and Safari isn't? That's not true. WebKit rendering happens in a "WebProcess" which uses the Mac Seatbelt framework for sandboxing. The sandbox file is WebKit2.framework/A/Resources/com.apple.WebProcess.sb. Sure, Chromium's sandbox is more restrictive. It proxies more things out through the broker process. But the difference is a matter of degree, not a fundamental architectural difference.