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.
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.
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.
> 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.
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.