Remove negative wording about Safari Browser

[Or3stis]

In the browser recommendation, it is stated that

Safari is not recommended. The code is a mess and security vulnerabilities are frequent,

The sentence portrays Safari in a very negative light and the links that are backing that claim are quite old. Safari is based on Webkit engine, which is one of the oldest open source and most widely used web engines. Saying that the code is a mess is insulting to the people that contributed to it over the years 😞 .

Moreover, Blink, Chrome's web engine is a fork of Webkit and both projects are being audited by Google's Project Zero. Webkit is used by many other applications besides Safari, such as Mail, iTunes, iBooks and all iOS web browsers (Apple doesn't allow the use of other web engines besides Webkit in iOS)

In terms of security for the average user, Safari is a browser with a security model very similar to Chrome's.

Chrome, Firefox, and Safari offer excellent security for the average user. Though there are cases that each browser has its merits. Web Extensions and bad browsing habits introduce more vulnerabilities than using Safari.

There are other parts of the browser recommendation that I disagree with. I would like to start a discussion on making some changes. Should that be part of another issue?

[aes512]

The code is a mess (as are a good portion of the people that contributed to webkit) - so what's the problem?

[gurre]

You could have a small comparison on the metric Time To Patch?

[Or3stis]

@gurre, that leads us to another issue I wanted to raise.

security vulnerabilities are frequent

The assumption one can make by reading it is

1. A vulnerability was publicly reported.
2. The vulnerability was documented in a vulnerability database such as the CVE database
3. An exploit was developed
4. The exploit was made available through Metasploit or BeEF
5. No one did anything to mitigate the vulnerability

This is rarely the case in case of web browsers, where the policy in Apple, Google and Firefox is to address reported vulnerabilities in 45 to 90 days. An actual chain of events is similar to this

1. A vulnerability is privately reported to browser vendor
2. browser vendor develops a patch
3. patch is distributed as a security update to browser
4. vulnerability is publicly reported
5. vulnerability is documented in a vulnerability database such as the CVE database
6. security researcher collects bounty prize

While Safari has a slow update release cycle, security updates are distributed independently to the regular releases.

My point is that is difficult to add metrics, given that certain aspects of vulnerability reporting are kept private to ensure the security of users until a solution is made public.

[gurre]

Well, good point. Someone should invent some type of normalized scoring for calculating security improvements over time with regard to disclosed reporting, time of vulnerable, time to patch and patch penetration. There might be some other interesting metrics as well.

[drduh]

Hi @Or3stis,

Thanks for raising the issue. I agree the alarmist language could be toned down, though I make no apology for saying Safari is a mere subordinate in the hierarchy of modern Web browsers, at least from a security and privacy perspectives. I am glad to explain my reasoning in reaching this conclusion and welcome others to challenge it:

• Safari is not open source; neither is Chrome, but Firefox and Chromium are. Of course, so is Webkit, although the majority of Safari exploits are Webkit related. Maybe this is not a good metric to use?
• At the time of writing, Apple did not have a functional bug bounty program to reward security findings in their products, including Safari. Some opine their new program is not great, but hackers absolutely love the Chrome VRP.
• Chrome and Firefox have a larger share of users; thus are more subject to attention of security researchers. I don't have a good way to measure this (just counting exploits seems pointless), but it certainly feels right. What do others think?
• Chrome and Firefox updates are available much sooner than Safari updates, which sometimes take days or weeks to appear in incremental system updates. The former are less intrusive and don't require a system restart, which a lot of users like to put off.
• Some vulnerabilities in Safari have been absolutely catastrophic (e.g., "goto fail") and such massive failures should not have happened in the correct development environment and culture. I am being very subjective here, but don't think my categorization is entirely arbitrary. In short, my experience leads me to believe the severity and priority of Safari bugs are significantly greater than Chrome/Firefox. Again, I'm glad if someone analyzes this with a significant methodology that we can write about.
• From a privacy perspective, using a browser not native to the OS is probably better, because fewer bits are integrated into other programs/systems (e.g., iCloud).
• I admit I do not use Safari, so I'm not familiar with its extension policy and how those work; I can't speak to their quality and safety. Same for Safari's use of Flash/Java/Silverlight plugins. Please comment if you're familiar with this.

Nevertheless, I concede just saying "the code is a mess" is a gross oversimplification and will be changing that soon. Safari has been slowly closing the gap in feature parity and security/privacy improvements over the course of this guide's existence. Still, Google and Mozilla have been working on these problems longer, and deserve the credit due.

It is also worthwhile to point out that while a macOS user may prefer Chrome/Firefox, the WebKit framework is ubiquitous throughout the operating system; so frequent system patches, disabling extra parts (like the captive portal) and additional mitigations are still required, even if one doesn't use Safari.

Please file additional issues for recommendations in other parts of the guide, or better yet, send a pull request with the suggested improvements.

Thank you!

[Or3stis]

Thank you for your reply @drduh.

I will start working on a pull request during coming days, so we can continue our discussion there.

Feel free to close this issue.

[drduh]

Fixed in #243.