Over the last two years, Safari has had half the vulnerabilities  as Chrome  or Firefox . Security updates are frequent .
As to code being a mess... perhaps there's a particularly offensive part of the WebKit code style guidelines  that make them less secure than Blink code style guidelines?
As an aside, the number of people who are qualified to speak about the "messiness" of rendering engine architecture is incredibly low.
64 Code Execution
61 Memory Corruption
5 Code Execution
9 Memory Corruption
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.
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.
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.
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.
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?
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)
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.
2. I have no answers for this one, other than to say that I haven't experienced it.
Every major/minor system update (IE 10.10.x, 10.11) will require these tweaks be reapplied as well.
Lets not call using ruby to run curl to install homebrew secure either.
Just because homebrew doesn't need sudo doesn't mean it's inherently secure, and the dependency tree of some of the software the guide recommends you install come with their own set of security issues which need to be manually maintained outside of OSX update procedures.
I'm typing this from an OSX machine with a few of these tweaks applied already, and I love using it for my desktop OS -- but if you really need to be this paranoid about security, you shouldn't be using OSX.
There are several security-or-paranoia oriented linux distros you can run.
 - https://support.apple.com/en-us/HT205031
 - https://support.apple.com/en-us/HT204942
 - https://support.apple.com/en-us/HT204659
 - https://trmm.net/Thunderstrike & https://trmm.net/Thunderstrike_2
It might have been nice for the author to state explicitly which steps are aimed at security and which for privacy.
If you're not sure of the nuances (or the pros/cons of using a "secure" Mac OSX install vs a secure Linux distro), you should research each of the services you're disabling to at least appreciate the attack surface each surface adds to your machine.
Take into consideration that unless you're running SELinux in full-enforcing mode (NOT targeted-enforcing, the default!), you still have a HUGE attack surface on your machine if you're using a web browser alone.
This presentation also goes into some detail about an overall layered security approach and touches on workstation security.
If you really-really-really need security, you could consider something like QubesOS to segregate your applications.
It "just works" if the package you're installing has a corresponding SELinux profile. If it doesn't, you're in for a world of "fun" trying to come up with a correct profile.
(I've played with both SELinux and Grsecurity MAC systems in the past. I know that it's not impossible to create these profiles. I also know that it's not infrequently an enormous pain in the ass, and a thing that even experts sometimes get wrong.)
But for a normal desktop user, it does just work.
I wonder if grsec's MAC system has grown an equivalent feature in the past four or five years. (If I overlooked the existence of such a thing in grsec, I'm gonna be so embarrassed.)
OSX is not an OS one should be running if one cares about security (but then neither is unhardened Linux). Guides such as these are meaningless at best and can give people the illusion of security or worse, you can't build a fortress on top of shifting foundations.
In addition, installing Chrome created a situation where every few minutes something is connecting to Google's servers. I disabled updates, uninstalled Chrome, and removed everything Google, followed instructions for removing the updater - and something is still pinging Google every few minutes.
If there is a way to shut these off, then the author should detail this, as much as he has detailed how to fix Apple's phone-home behaviour.
I believe you're referring to DNS prefetching , which is mentioned in the guide. I'm curious to know how you're determining that something is "pinging Google every few minutes". Maybe you could open a Github issue and I'll investigate it for the guide. It's definitely good to enumerate Chrome's behavior w.r.t. privacy.
The amount of bad faith people ascribe to basic usability functions utterly astounds me.
I think most of it comes from how Google (and the industry in general) has evolved. There was a day when things were labeled clearly and the default behavior wasn't to vacuum up as much data about users in the name of basic usability functions.
The amount of trust people have in companies to keep their private information safe from prying eyes is what's truly astounding.
I'm sure some company will turn evil and abuse the trust that their users have given them. (I assume it will be Facebook.) But I also, maybe naively, assume this will not impact my life in a significant way.
You're putting too much faith in them.
If you want to test that, temporarily disable the little snitch rule and keep an eye on the top right hamburger menu - it'll turn green or orange if updates are pending.
It sounds like you've decided to treat Chrome as a hostile app and are going to evaluate everything it does negatively in that light. If that's the case, why not just uninstall it?
It has a better version of Flash, that's the only reason I keep it around.
You really don't know why anyone would turn of automatic updates? Really?
Chrome happily installs from an OS X standard account, it does not need to be installed by an administrator. As such, it probably isn't able to put stuff "everywhere".
BTW, maybe it's just me, but I have installed Chrome as its own user. That makes it more difficult for it to spy on my day-to-day activity.
~/Library/Google/Google Chrome Brand.plist
2) Frankly, Google is far more trustworthy than almost any randomly selected software company. (Don't forget that there are far more software companies out there than either of us are aware of.)
3) Unless you've taken the time to configure a MAC system, software that runs as you can access any data and transport mechanism that you can access. That's a fact of life. Anything you run on your computers can also act as a little snitch.
2) I sort of agree with this. Google certainly don't want to sell my keystrokes on the black market. However, they do want to store them and learn more about me and my personal autonomy and privacy mean that I don't want them to have all my data.
3) Which is exactly why one should be careful what software one installs!
But the appeal to IETF standards that brackets that argument, with it's "period, no exceptions" language, is a bit galling. Who cares? The IETF has made all manner of silly rules in its history. Why isn't this simply one of them?
For one thing, the standard was built for an extremely different internet than the one we have today.
(I've used to work at ISP. ICMP echoes towards the customer's machine is a first step in diagnosing what could be wrong - and sometimes it really helps to get an image of what's going on. Sadly, a lot of machines do not respond to those.)
Attempts to reduce surface area that fail to actually achieve their goal and impede the proper functioning of networks the affected system connects to should be avoided whenever possible, no?
* It's best to build the image using a full installer of the latest version of OS X downloaded from the App Store (currently 10.10.5 14F27). Do not build a 10.10 14A389 image and apply the combo update to it as updates are meant to be installed on live systems and occasionally causes headaches.
* Avoid including extra packages on the image, it'll only make it a pain to maintain and update. Also many packages are badly written and don't install correctly (see https://github.com/MagerValp/AutoDMG/wiki/Packages-Suitable-...).
* Rather than installing packages into the image you can include them but install them on first boot, e.g. with Outset: https://github.com/chilcote/outset
* Even better, it's easy to set up Munki for software management, this way you can keep your machines updated too: https://github.com/munki/munki
* If you build your image with AutoDMG a recovery partition should be included in the image and created automatically when you restore with asr. If for some reason it's missing you can create a package that will create it for you (again using the latest OS X installer): https://github.com/MagerValp/Create-Recovery-Partition-Insta...
Now on to reading the rest of the guide... :)
Alternatively you can code review the script before executing it, which is a plus.
HN doesn't seem to like Apple/Microsoft as trust brokers, and absent a trusted CA I don't see how this makes the problem any better.
The option you're thinking of is -k — -f simply tells curl to fail silently on errors, not ignore them:
OK, so why even include it then?
That being said, I don't think Ubuntu is any more or less secure than OS X.
This is just a personal opinion.
After that, you could look at browser exploits as the most common attack vector. They tend to go back and forth, but all of them get pretty quickly rooted in competitions like Pwn2Own.