3 ms·

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

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.
  - vonklaus 11y ago
    Does it matter that Safari typically runs on Mac hardware? I would suspect having a sandboxed solution as well as teh ability to control the hardware, software and OS would be very secure, but it must be quite good that they have end to end control over the hardware and software and can integrate it. Chrome runs as more of an application "anywhere that google can go TM". So they have to provide better sandboxing as they likely don't control the hardware/must make it easier to ship? On Mac hardware, what do you think is "safer" ceterus paribus, Safari or Chrome?
    - greggman 11y ago
      It's clear from the CVEs which is safer. Assume all bugs in Chrome on happen on OSX. There's 13 to 1 more code execution bugs in Safari.

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.
- vonklaus 11y ago
  Does it matter that Safari typically runs on Mac hardware? I would suspect having a sandboxed solution as well as teh ability to control the hardware, software and OS would be very secure, but it must be quite good that they have end to end control over the hardware and software and can integrate it. Chrome runs as more of an application "anywhere that google can go TM". So they have to provide better sandboxing as they likely don't control the hardware/must make it easier to ship? On Mac hardware, what do you think is "safer" ceterus paribus, Safari or Chrome?
  - greggman 11y ago
    It's clear from the CVEs which is safer. Assume all bugs in Chrome on happen on OSX. There's 13 to 1 more code execution bugs in Safari.