> It's far from just the render engine that's being constrained.
It is unclear whether this would still even be the case.
My understanding is that it's a _policy_ limitation preventing third party browsers on iOS. But there's also iOS security policies preventing JIT to have a fast browser.
I cannot imagine Apple opening up JIT-capabilities to all developers on the app store. I wouldn't be surprised if they didn't relax this at all. Perhaps they will they grant entitlements for JIT to a select few.
I agree that whether or not they'll allow JIT is an orthogonal issue based on security policies, but I don't think it's out of the question.
The security argument to not allow a JIT is that mapping code segments as executable+writeable opens up a lot of interesting attack vectors, and therefore allowing JIT weakens security. This is true of course, but the argument is a bit dubious for a few reasons. The first of which is that the OS is supposed to have sandboxing mechanisms that don't allow escape from the sandbox even if something goes wrong, and therefore prohibiting a JIT shouldn't be required in the first place. Furthermore WebKit itself has a JIT (whatever Apple calls their JS implementation), so iOS is already vulnerable to these kinds of issues in some sense. Finally, in general you can write and link in arbitrary code into your program (in read-only sections of memory), so attackers can already write exploits in C/C++/asm/whatever.
Obviously Apple needs special consideration for WebKit itself since the WebKit rendering engine is linked into a ton of applications, so a security issue in WebKit is a major problem because it affects many programs on the phone, including a lot of first party applications. But this wouldn't be the case with a third-party iOS browser, since even if Apple allows you to install a third party browser, they're not going to allow you to replace the system webview implementation with a third party one. Therefore a bug or security problem in Firefox/Chrome/whatever should be limited to just that app, and wouldn't have the same scope as a WebKit vulnerability.
Apple is notoriously restrictive so maybe they won't change their policies. On the other hand I think the current technical argument for not allowing third party programs to have JIT code is pretty weak, so I could definitely see a different decision being made at some point in time, especially if there was pressure from the legal team (e.g. due to things like EU anti-trust regulations).
This is a pretty big claim. It's not that the browser can't be secure. It's that Apple might not have total control & oversight over what is executing. And that Apple won't pursue further to find out: they just make their job easy for themselves by arbitrarily saying all code that runs must be reviewable in the app store. That's not a mark on other people's JIT engines: it's a mark on Apple's willingness to understand/pursue/investigate. At great cost to the consumer, in this case.
I don't want to be slanted in only one direction, so let me share the other side of the coin: in the new Web Extensions spec that Google has built from the ground-up by fiat (mv3), they too ban dynamic code of any kind: all code must be built in to the extension. And the extension can't be any kind of virtual machine, can't execute any kind of programmatic system within itself. Because Google too is a murderous shitty coward that hates the world, that hates potential, that wants to limit freedom, that curbs what is possible, under exactly the same premises of being for our security, but which also obstructs massive classes of very basic very simple very generic software that poses a threat to these sizable corporations ability to stay in absolute control. Generally I'm pretty ok with Google's behavior, but this particular vicious turn of events deeply deeply against the web & possibility makes me lower them to the same low dog piece-of-shit fuckwad coward shitsmear con-man that I have long seen as a fairly distinclty Apple low lying cowardice. For your protection is a vicious piece of shit lie, and end of basic liberty. Shame, you vicious piece of shit fucks, shame!! You call it security, but you are just not willing to actually do the work to understand or look at & investigate: you make an easy fiat rule that excludes countless valid & good uses, because it makes your life easy & benefits your systems of control, lowers user-agency. It's directly agains the end-user, and yet they say it's for our benefit: this is the worst kind of lie.
It is unclear whether this would still even be the case.
My understanding is that it's a _policy_ limitation preventing third party browsers on iOS. But there's also iOS security policies preventing JIT to have a fast browser.
I cannot imagine Apple opening up JIT-capabilities to all developers on the app store. I wouldn't be surprised if they didn't relax this at all. Perhaps they will they grant entitlements for JIT to a select few.