4 ms·
Preface: I don’t know how sandboxing works on iOS beyond broad concepts, and there’s going to be implementation details I’m unaware of. As a result, please read
by liamwire 5y ago
Preface: I don’t know how sandboxing works on iOS beyond broad concepts, and there’s going to be implementation details I’m unaware of. As a result, please read this as curious speculation, rather than anything approximating an authoritative statement.
My understanding is that WebKit is the only rendering engine permitted on iOS as a security precaution, ostensibly taking Apple at face value and in good faith.
Numerous zero-days on iOS have targeted WebKit in the past, and to a large extent this makes sense to me. Browsers have become one of the most common malware vectors in the modern era, which isn’t surprising given their entire purpose is to access and execute/render external code.
Given that fact, and the significant attack surface area that opens up, Apple’s stance, in my nebulous interpretation, is that having any other rendering engine permitted to run in iOS presents an unmanageable number of potential vectors for more widespread malware on the platform. (Arguments about their resources aside, we know adding engineers to a problem space doesn’t scale in linear fashion towards solving those problems.)
Apple’s vocal focus on privacy and safety constitutes a significant aspect of their product marketing, and it makes sense they’d want to walk-the-walk, so to speak, to ensure their product lives up to the claims they make.
Now, given that Apple already have trouble keeping up with WebKit vulnerabilities, it’s believable that they’re being entirely genuine* in arguing against the addition of additional browser engines that they’d need to keep up with, on the grounds that doing so presents a real risk to their product’s core value proposition, and by extension, their users.
*However, it’s also important not to over-ascribe anthropomorphic traits to a corporation, and it’s completely valid to argue that Apple benefit heavily from this narrative. Indeed, both can be true.
- AnthonyMouse 5y ago> Apple’s vocal focus on privacy and safety constitutes a significant aspect of their product marketing, and it makes sense they’d want to walk-the-walk, so to speak, to ensure their product lives up to the claims they make. The solution for anyone who wants this is to not use any browser other than Apple's. It's no excuse for not giving the customer a choice. They can still choose the existing thing if they want it; just don't install anyone else's browser.
- liamwire 5y agoI suspect an argument could made that, through either existing mindshare or further marketing, unwitting consumers would ultimately install alternative browsers (in significant enough numbers), and with that, open themselves up to these security concerns. I’m not making a claim either way, however, to be clear.
- shmerl 5y agoI don't believe it to be in good faith given Apple's anti-competitive behavior all over. Not convinced in the least. Especially when it "accidentally" gives them a huge leverage over the adoption of Web technologies according to how they want it. Either way, intent shouldn't matter here. What matters more is their actual damage to competition which is apparent.
- chj 5y ago> My understanding is that WebKit is the only rendering engine permitted on iOS as a security precaution, ostensibly taking Apple at face value and in good faith. Look at mac. Do we have a problem with firefox on mac? Both mac and iOS share the same OS kernel. Using security as an excuse is laughable. I once read on twitter from a mozilla dev saying they were even willing to build a browser engine without JIT just to satisfy the security requirement. But eventually they went with webkit to build Firefox for iOS.
- zimpenfish 5y ago> Do we have a problem with firefox on mac? Uh, yes? There's 18 here (just for January 2022, mind) of which only 4 don't affect the Mac version. https://www.mozilla.org/en-US/security/advisories/mfsa2022-01/ https://www.mozilla.org/en-US/security/advisories/mfsa2022-0... December 2021 has 13, only 1 doesn't affect the Mac. https://www.mozilla.org/en-US/security/advisories/mfsa2021-52/ https://www.mozilla.org/en-US/security/advisories/mfsa2021-5... etc. etc.
- concinds 5y agoA similar look at Safari vs Chrome on Mac would reveal that Safari is much less secure than Chrome; given that many iOS exploits rely on WebKit, the average iPhone user is strictly less secure because of Apple's ban on fair browser engine competition.
- zimpenfish 5y agoSafari: https://www.cvedetails.com/product/2935/Apple-Safari.html?vendor_id=49 https://www.cvedetails.com/product/2935/Apple-Safari.html?ve... Chrome: https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 https://www.cvedetails.com/product/15031/Google-Chrome.html?... 2019: Safari: 166, Chrome: 312 2020: Safari: 76, Chrome: 228 2021: Safari: 33, Chrome: 309 > Safari is much less secure than Chrome Not by CVE metrics? Which metric are we talking about here?
- chj 5y agoBy your standard, then every non trivial app should be banned on mac, including safari.
- jsnell 5y ago"We have a difficulty keeping Safari secure, so we shouldn't let anyone else build a browser since it might be even less secure" does not seem like a convincing argument. It is the opposite: people whose incentives are to make good browsers would clearly make a better job of this than the company that has been working to cripple the web for a decade.
- GeekyBear 5y agoThe ability to load and execute code from random places is dangerous. From today: >A fake two-factor-authentication app that has been downloaded some 10,000 times from Google Play surreptitiously installed a known banking-fraud trojan that scoured infected phones for financial data and other personal information, security firm Pradeo said. https://arstechnica.com/information-technology/2022/01/2fa-app-with-10000-google-play-downloads-loaded-well-known-banking-trojan/ https://arstechnica.com/information-technology/2022/01/2fa-a...