Talk:Safari (web browser)

Inclusion of details about releases only available under NDA
The article currently contains details about pre-release "seed" builds of Safari. It links to connect.apple.com as a source for information about this build. The page containing this information states: Warning: Pre–release software is Apple confidential information. Your unauthorized distribution of pre–release software or disclosure of information relating to pre–release software (including the posting of screen shots) may subject you to both civil and criminal liability and result in immediate termination of your ADC Membership.

Providing information about each pre-release build is also of highly questionable valuable. — Preceding unsigned comment added by 38.119.251.140 (talk) 5 March 2008 06:12 UTC (UTC)

Failure to adopt modern standards
The "Failure to adopt modern standards" section has 2 sources. One is now out of date and includes a correction in one place. The other source deals with Apple's policy of forcing browser on iOS to use webkit, the rendering engine Apples develops for Safari. This section should either include more recent evidence of Apple's poor support of standards, possibly plus some text indicating specific standards that they either implemented late or have not implemented. Or if the issue is mainly about refusing to allow another web rendering engine on iOS, then it should be titled differently, and perhaps expand upon why it's valuable to allow competing engines.Rjjiii (talk) 02:41, 2 September 2022 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for deletion
The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion: Participate in the deletion discussion at the. —Community Tech bot (talk) 11:10, 1 November 2022 (UTC)
 * IEMac icon.png

Good article
This article is quite flawed, and IMO worse than Google Chrome, which is C-class. Hopefully editors can help fix this, otherwise I doubt it'll last very long (though I've complained before about the ever-stricter interpretation of GA and FA criteria, so I don't have the heart to nominate it for GA review). The writing quality and sourcing just aren't on par. Seemingly random articles were added as citations, that have nothing to do with the material they're supposed to verify. DFlhb (talk) 05:46, 23 December 2022 (UTC)


 * @DFlhb Hi, thanks for your contributions to the article! I was the GA reviewer before. I agree it wasn't perfectly reviewed (first time I did a GA review), letting another editor do a a 2nd review would be fine. Or maybe just delist as it is now.


 * Though, I disagree about your removal of the security exploits being indiscriminate information. It was based on good sources by Ars Technica, which is not routine coverage. It would be fine to not add the entire paragraph back as it was, but at small section discussing the Pwn2Own stuff would be good in my view, since the researchers like Charlie Miller are notable. The Google Chrome article you list also has a section dedicated to vulnerabilities, next to its security architecture (this article should also have such a section imo). PhotographyEdits (talk) 12:27, 23 December 2022 (UTC)
 * Here's why I think security exploits are routine, and it misleads readers to emphasise them:
 * Throughout Safari's existence, there have been 91 (WebKit) + 1,122 (Safari itself) = 1,213 security exploits that are as severe, or more severe, than the one Charlie Miller found (CVSS score >4). Chrome had 2,361. Windows 10 had 2,314. Android had 3,721. macOS had 641. iOS had 2,446.
 * Individual exploits are routine. But even then, these numbers can't tell us which OS or browser is more, or less, secure. If a platform (or app) has more users, intelligence agencies and hackers pay higher prices for exploits, so researchers focus on finding exploits in those platforms. Zerodium pays $1m for Windows exploits, 500k for Chrome exploits, $100k for Safari exploits, and $50k for macOS or Linux exploits. So smaller platforms don't get the same scrutiny. Zerodium (and many others) buy these exploits, and re-sell them to governments and rival corporations, which use the exploits and keep them secret, so none of them are included in the numbers above (until found by a white hat hacker and disclosed publicly rather than sold).
 * There are likely hundreds of major exploits in every app you use, they're just hard to discover, and those professionals whose job it is to discover them can make more money selling them to hackers than disclosing them to Apple/Google to fix. I doubt it could be more routine (and I'd remove it from the Chrome article too). DFlhb (talk) 13:33, 23 December 2022 (UTC)
 * @DFlhb Fair, good arguments! I agree then, but it would still make sense to at least put the total number of disclosed vulnerabilities in the article, I think that CVE details is a good enough source for a single number. This should then also be listed in the other browser articles, so readers could compare them. PhotographyEdits (talk) 13:46, 23 December 2022 (UTC)
 * Folks, bear in mind that reliable sources inform what is WP:DUE for inclusion. If Ars Technica made a mountain out of a molehill, that would be unfortunate, but I'm not sure whether that means we can ignore the coverage? Robby.is.on (talk) 13:53, 23 December 2022 (UTC)
 * @Robby.is.on Yes, that's basically what I was arguing for, but I also think we can put that same information in a broader context by putting the total amount of vulnerabilities in it. How about we first list the total amount and then highlight that a single was found during a competition by a well known researcher? PhotographyEdits (talk) 14:01, 23 December 2022 (UTC)
 * Sure, per WP:VNOT, and WP:NOTNEWS. It also fails the WP:10YT: that exploit was breaking news, and then no one continued to talk about it. It was fleeting.
 * And @PhotographyEdits, the problem with listing the total amount is that again, it would misinform readers. The only thing they could conclude from that number, is that it's correlated with how secure or insecure something is, but the number can't tell you that at all; it has no informational value. Besides, it would be a primary source. No reliable secondary source covers the total number, because they know it's irrelevant. If we can find browser developers (even competitors) who claim Safari is less secure, or who have evaluated its security measures, that would be due, because it wouldn't be routine coverage. DFlhb (talk) 14:09, 23 December 2022 (UTC)
 * @DFlhb That's not true, check this book from 2016 here. PhotographyEdits (talk) 14:13, 23 December 2022 (UTC)
 * @DFlhb I found quite a nice source here, which even has a graph in it. I would argue that it is acceptable per Wikipedia policy to use this books as a source in combination with a primary source to update that number to 2022. PhotographyEdits (talk) 14:56, 23 December 2022 (UTC)
 * Nice! That's a good source, because it's high-level (instead of focusing on one vulnerability) and contains expert analysis. We should cover it. I'll try to find more security experts that analyse the subject in depth, and that don't just talk about one incident. DFlhb (talk) 15:06, 23 December 2022 (UTC)
 * I just found this. He's a security researcher, so it's usable as a source despite being primary (as long as we attribute it), but unfortunately most of the article is about Firefox. But there's a paragraph about Safari, with two links we could use.
 * I also found this, about Safari. WebKit has a Just-in-time compiler, so it seems that it has write xor execute permissions for memory, which makes it more secure. But that's WP:OR, since the article doesn't say it outright; it's about macOS. I'll try to find a better source. DFlhb (talk) 15:34, 23 December 2022 (UTC)
 * A primary source from a researcher can only be used if they are a subject matter expert and their research in the relevant field has been published by WP:RS. Those articles look nice, would be great if we can use them. PhotographyEdits (talk) 15:39, 23 December 2022 (UTC)
 * Also: if we cannot use it as a reliable source, it could be included in a "further reading" section. They don't have the same strict requirements. PhotographyEdits (talk) 15:41, 23 December 2022 (UTC)
 * Good work, you two! :-) Robby.is.on (talk) 15:20, 23 December 2022 (UTC)
 * 😀 Thanks! DFlhb (talk) 15:35, 23 December 2022 (UTC)