The part about reference counting in the DOM is poorly researched BS.
First, none of the P0 reported exploits attacked the DOM. The WebKit bugs were all JSC and none of them had anything to do with reference counting. One of them was a garbage collection bug.
Second, WebKit’s DOM has a powerful use-after-free protection called isoheaps. Isoheaps mean that virtual memory is never reused between types, which neutralizes the UaF->typeconfusion vector. This is a better protection for the DOM than a garbage collector since garbage collectors are more likely to have bugs than isoheaps.
I think that comparing browser security so hard. Maybe too hard for this Andy Greenberg person.
While this post raises legitimate points, I don't think Apple disallows other browser engines or default apps for fear that they maybe more insecure.
Speaking from a business perspective, it makes sense for Apple (if not for users) to force Safari and Mail.app. Otherwise, Chrome and Gmail will just overtake the phone.
This will be bad for Apple from a strategic and PR perspective. Gmail and Chrome would have no incentive to improve battery life (indeed Chrome did not improve battery performance till 2017 on Macbooks and Chrome 76 has again destroyed battery life on my macbook) and Apple's privacy-as-a-selling-feature would go out of the window because - media, people and their willful ignorance of nuance and context. Not to mention, how your product roadmap would be influenced by another company simply because it has a much larger user base.
On the security aspect, I am not a fan of how media has been posturing this as - "iphones are complete security nightmares." Any person who has followed security will astutely note that iOS garners the same attention which Windows did a decade ago. At that time, it did not mean that macOS or Linux were inherently safer, just that they did not have the attention that Windows commanded. Black market prices of exploits are not a good proxy for how secure is a system. It just indicates which operating system has the most attention of hackers. It will not be a surprise to me if 2-3 years later Android finds itself in a similar position as iOS is in now. Not to say, that the exploit surface on Android can be way more bigger because of the number of parties involved - OEM and the carrier.
I think one huge reason for not allowing other browser engines is because to get performant javascript, a JIT javascript engine is necessary, which in turn requires access to mark memory pages executable after being writable, which is a code entitlement that Apple will never ever hand out to third party developers (because it allows bypassing app store review and is also a huge liability security-wise).
If third party apps had access to map dynamic memory as executable, we would see thousands of third party "appstores" or "emulator/piracy launchers" that could simply download random unvetted executables from the internet, perhaps hidden in inconspicuous decoy "flashlight apps".
If they allowed third party browser engines without JIT, everyone would install Chrome and then complain that iOS benchmarks incredibly bad compared to Android.
The only responsible thing for Apple to do here is remove all networking functionality from the iPhone. If the iPhone 11 has a cellular modem, they blew it.
> Apple requires that all iOS web browsers—Chrome, Firefox, Brave, or any other—be built on the same WebKit engine that Safari uses. "Basically it’s just like running Safari with a different user interface,"
> As a result, Apple has insisted that only its own WebKit engine be allowed to handle that unsigned code. "They trust their own stuff more," Henze says. "And if they make an exception for Chrome, they have to make an exception for everyone."
> iMessage has innate privileges in iOS that other messaging apps are denied. In fact, non-Apple apps are cordoned off from the rest of the operating system by rigorous sandboxes.
Badly written article, Chrome certainly might have fewer security issues than Safari but unless Apple would exclusively use Chrome's engine instead of their own (which is highly unlikely), by fully allowing Chrome (or any other browsers) in addition to their own, they would automatically increase the surface of attack, irrespective of the quality of third parties browsers/engines.
Nevertheless fundamental critics of Webkit stand imo, I'm usually not for rewriting components from scratch but given the ressources of Apple and the importance of web engines in 2019, it would be a good investment to pull off something akin of what Mozilla is doing with Servo, or even better, teaming with Mozilla - dreaming -, this is the future.
First, none of the P0 reported exploits attacked the DOM. The WebKit bugs were all JSC and none of them had anything to do with reference counting. One of them was a garbage collection bug.
Second, WebKit’s DOM has a powerful use-after-free protection called isoheaps. Isoheaps mean that virtual memory is never reused between types, which neutralizes the UaF->typeconfusion vector. This is a better protection for the DOM than a garbage collector since garbage collectors are more likely to have bugs than isoheaps.
I think that comparing browser security so hard. Maybe too hard for this Andy Greenberg person.