Third party browsers entitled with dynamic codesigning poke a huge hole in Apple's security model for iOS devices.
Also Apple has been allowing coding apps for years now which can download and run executable code, so it is hard to buy the argument.
Another reason is that it's extra work to decouple the browser with the OS.
> Also Apple has been allowing coding apps for years now which can download and run executable code, so it is hard to buy the argument.
Not native code.
It is expected of a company which boasts about security and privacy of its users as a premium selling point, although it is questionable now[1]. Besides, MacOS has been receiving Safari updates separately.
Also android has been decoupling several system services with every iteration now, soon crucial system services would be updated from PlayStore and so even if the manufacturer doesn't ship OS updates, important services would stay updated.
[1]: https://arstechnica.com/information-technology/2019/09/apple...
Sure, but the company is doing extra work to provide this. It might be a worthwhile decision to make but it’s certainly not a free gain.
I thought that argument was rejected already in 2001[0].
[0]: https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor....
---
(edited to fix link formatting)
What they’re talking about is IE the OS component didn’t mean that IE the user-facing general-purpose browser had to be the default.
MS made the exact same argument 15 years ago.
A common mitigation to that is “write xor execute” (https://en.wikipedia.org/wiki/W%5EX)
From that page: ”Without such protection, a program can write (as data) CPU instructions in an area of memory intended for data and then arrange to run (as executable) those instructions. This can be dangerous if the writer of the memory is malicious.”
JIT compilers are collateral damage to that mitigation; they have to write bytes to memory and then make the CPU run those bytes as code, and W^X doesn’t allow that.
Apple released iOS 10.3.4 on July 22, 2019 for iPhone 5 and iPad 4g.[1] So it's not completely unheard of for Apple to release iOS updates after officially dropping iOS support for old devices. From the Apple website:[2]
> iOS 10.3.4 addresses an issue that could impact GPS location performance and could cause system date and time to be incorrect. This update is recommended for all users.
I wonder if this update quietly fixed these exploit changes.
[1]: https://support.apple.com/en-us/HT201222 [2]: https://support.apple.com/en-us/HT208011#1034
Also, Google Project Zero article(link in parent comment) gives the clear timeline of the attacks and that the exploits were updated to mitigate patches with every new OS updates; so even if 10.3.4 had security patches older devices still might be vulnerable to later attacks.
In fact, I have a Nexus 7 (2013) nearby, so I know that firsthand.
If Windows desktops have shown us anything, it's that (given NAT) few vulnerabilities are easier and more profitable to attack than a browser.
> In any case, I don't think there can be any opposing arguments on the side of security for Apple not updating Safari via AppStore
I don't really follow. It's not about just updating it via the AppStore, it would also require making all future changes to Safari compatible with old hardware and old versions of iOS. They have a pretty impressive track record lately of supporting devices up to 5 or 6 years old, but they can't support everything forever. The security argument for it is that almost nobody is using these devices anymore, so their resources are better spent securing systems that have more users.
If I can oversimplify, 3rd party browsers on iOS are just like a theme for Safari.
Apple’s security model is that Apple has to be able to inspect and review all the code you’re app is going to run. There is a special exception for JS provided that you run it though Apple’s interpreter.
Browsers are caught in the crossfire of a much broader rule that applications can not run code that Apple can’t see. They don’t sign anything that allows for arbitrary or semi-arbitrary code to be downloaded externally and run in principle. Apps get around this by using JS but you aren’t, as a rule, supposed to expose native API’s to your JS code.
So, it doesn't make any sense for Apple to not allow 3rd party browsers apart from its intention for a walled garden even if it means compromising security for its users.
In the developer agreement, the second paragraph of section 3.3.2 gives special permission to programming environments, but that’s for executable code, which won’t work on iOS anyway.
Python, for example, typically gets compiled to bytecode, but the bytecode is interpreted.
Case in point : Google Project Zero's latest iOS Exploit chains on webkit shows how easy it was(*is?) for an iOS user to fall victim to browser vulnerabilities by just visiting a website.[1]
The exploits covered targeted only 64-bit, so technically devices < iPhone5S which were not part of the update cycle wasn't mentioned in the GPZ research. But many of the exploit chains did use public jailbreak exploits and Semi-unthethered jailbreaks exist for 32-bit iOS devices running up to iOS 10.3.3.
I don't know whether complete exploit chain as detailed in the project zero wasn't possible for 32-bit devices or the attackers just didn't care about those devices. It is safe to assume, they are vulnerable.
Where as a 7 year old android device can still download Firefox for Android with latest security updates.
In any case, I don't think there can be any opposing arguments on the side of security for Apple not updating Safari via AppStore or now allowing proper 3rd party browsers.
[1]: https://googleprojectzero.blogspot.com/2019/08/a-very-deep-d...