End the Apple Browser Ban
twitter.com
twitter.com
(There are some security details of how JSC's JIT is hardened in this talk by the head of Apple's security engineering team: https://www.blackhat.com/docs/us-16/materials/us-16-Krstic.p...)
WebKit on iOS also uses its tight OS integration to achieve high performance while using an out-of-process architecture for security. Every app that uses WebKit gets this security architecture for free, which is a major benefit to users. This architecture could theoretically be adopted by other browsers, but only with a lot of engineering effort from both sides.
A separate browser app for Chrome that uses Blink, perhaps modified to use JavaScriptCore, doesn't seem that bad, if they could achieve the same level of isolation between tabs.
OP points out that other browsers such as Chrome can push software fixes faster than Apple. Well, not necessarily on iOS, where they will have to go through App Review.
And what about when 3rd party apps start bundling Chromium.framework (as we have with Electron apps on the desktop today) because they want to use <new API> now? Who is going to make sure all those app developers are keeping their embedded Chromium patched and up-to-date?
(Will you complain when your users can’t visit a site because the browser embedded in Facebook doesn’t support <even newer API> some day? Or will you tell every iOS visitor that “this site looks best in the standalone browser app”?)
The WebKit mandate on iOS almost entirely comes down to protecting users against web exploits, and on the other side the argument mostly boils down to "Apple is slow at implementing <feature>."
1. Bugs Safari is the the most buggy browser with application breaking bugs crossing into every aspect of development, whether your using WebRTC, Audio, Scroll/UI, LocalStorage/IDB... Safari is the most buggy browser.
Examples: * LocalStorage / IDB has broken many times over the last 10 years, including breaking for months in production. Normally gets fixed in webkit pretty quick, but takes a month to actually make it to an iOS release.
* Viewport/Scroll/UI/Zoom Bugs - As a collection of issues also related to hiding the header on body scroll, zoom etc.. To fix we had reimplement ALL of user scroll including momentum scrolling, bounce etc in userland js. A mammoth 210 hours of hardcore engineering just to get around bugs that have existed for 5 years.
* bugs.webkit.org is useless as a bug tracking tool, stuff just doesn't get triaged properly, or is hidden away in radar or whatever Apple is using internally and worst of all it just does not get fixed.
Why? It's not the Safari's teams fault, their engineers are all super smart, work hard, care about the web, and some have been building it from the days when Safari was the best browser by far... but you can't build an A class browser with a team that small.
The reason they are so underfunded is Apple simply doesn't care about the web, in fact they see it as competition to the AppStore. Funding and Staffing decisions don't happen within the team. Underfund the team for 10 years and this is what happens. Even Eddy Cue as far back as 2013 knew Safari was slipping and said so in internal emails.
2. Critical Functionality never gets built
The AppStore and its 70b of revenue built on extracting money from a tiny % of addicted mobile gaming whales (70% of all AppStore revenue comes from free to play games), is a rapidly growing core part of Apple's business.
The web competes with that and Apple knows it. Native Apps got notifications in 2009, 13 years later, thousands upon thousands of requests from developers and Apple has deliberately avoided implementing it on iOS. Why? because it's critical to lots of Apps and if they had it, they wouldn't need to distribute to the AppStore. Install Prompts, Background Sync, proper integration with settings, bluetooth, the list goes on. The combination of not wanting to build the features and underfunding means that Safari lags the competition by years.
3. Privacy
Apple likes to blame not developing features on privacy (specifically fingerprinting) but never outlines their specific narrow scope privacy concern so that we can reply in a meaningful way to offer potential mitigations. They like to push the image that privacy is their foremost concern but are quite happy to hand over raw access to 10's of millions of icloud accounts including the encryption keybags when they are concerned it will affect them financially. You combine that with the hopeless protection the AppStore review process offers (nobody is reading every line of code, AppStore is full of scam, data theft apps) and extensive data access native apps are provide compared with private by default web apps, the entire privacy angle starts to seem like a trick.
3. Security Safari has had 7 0-days (possibly 8 as of writing) this year, with the largest patch gap because Safari releases are tied to the OS. Safari makes heavy use of OS functions for everything, so currently it is not possible to have separate installs of Safari. This also rules out running canary/beta/alpha along side a the current version meaning you need separate devices on different versions of iOS for testing.
This in turn makes Apple have a larger patch gap than the other browsers, since the other browsers can just silently update whereas Safari requires a full system update. This arguably makes it less secure than the other browsers as users are exposed for a longer period. Now this is speculation and very hard to demonstrate as there are a lot of factors in play, iOS is likely a bigger target for researchers/hackers and there are no solid statistics on how many devices get exploited with the browsers being the primary cause.
I'm suggest reading: https://infrequently.org/2021/08/webkit-ios-deep-dive/#apple...
4. Security and Other Vendors
Given the amount of resources that Microsoft/Google/Samsung/Intel invest into chromium based browsers, it's unlikely that they would be less secure than Safari. However obviously Apple would not be able to open the door to ALL third browsers and offer low level access for JITs. There are workable solutions to this which involve Apple introducing additional security protections at the OS layer and having requirements to be able to gain these special privileges.
In terms of a "App Review" process, we all know it's joke and that anyone could slip code past "reviewers", Apple has the ability to "prioritize" App review for designated browsers or skip it all-together, so any delay in rolling out emergency fixes could be blamed on Apple.
5. In-App-Browsers / Embedded browsers are mostly terrible for users regardless. I wouldn't recommend giving them special privileges.
6. Use "XYZ" Browser Instead
Here are some realistic messages: "We recommend "XYZ" browser because Safari has broken all localstorage for the 8th time"
"Want basic tools like being able to print via bluetooth and notifications? Use XYZ browser"
"Want to have a PWA that actually works? use XYZ browser"
It's developers that tend to use Chrome.
I personally use Safari on macOS, because I prefer how its privacy protections, and how little battery power it uses. I just can't get used to Chrome and it doesn't integrate with Keychain so I can't re-use my existing password store.