That doesn't explain why it fails to update Safari via AppStore.

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.

> That doesn't explain why it fails to update Safari via AppStore.

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's extra work to decouple the browser with the OS.

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

> Besides, MacOS has been receiving Safari updates separately.

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.

> Another reason is that it's extra work to decouple the browser with the OS.

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)

There is a bit of nuance here. IE today still isn’t decoupled from Windows. MS has been shoving it into an ever smaller corner of Windows but IE is the OS provided webview for a lot of old crusty applications that needed to render HTML.

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.

Microsoft was in a far different market position than Apple.

Doesn't the Swift Playgrounds app let you download, compile, and run Swift code?

It does, and it has special entitlements to let it do so.

>Another reason is that it's extra work to decouple the browser with the OS.

MS made the exact same argument 15 years ago.

And it’s still true 15 years later. They still haven’t been able to decouple IE for all the random crap that uses it. They’ve shoved the user facing interface into a dark corner hoping everyone forgets about it but it’s still there.

Do you mean the ability to dynamically allocate executable memory? That's not necessary for shipping a browser engine (though performance would suffer, as that's how all modern JS VMs work, via jitting JS to machine code).

Yes. It's not necessary for a browser engine to do this, of course, but AFAIK the best interpreters can only approach or barely match simple templating JITs so you're probably not going to be able to write a competitive browser without this.

Can you explain why allowing apps to ship with a JIT compiler be a security issue?

A common attack method is to overwrite the stack or some buffer and then somehow make the CPU run the bytes written as code (https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation, https://en.wikipedia.org/wiki/Buffer_overflow#Heap-based_exp...)

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.

FWIW, switching memory from RW- to R-X (which is still W^X) is also not allowed unless you have certain, easier to get entitlements.

Think about what a JIT compiler means: it's allocating memory, writing to it, and then executing it. That's also what malware does so if you give third parties access to that functionality you have the immediate problem that the number of people who can make a mistake which gives native code execution goes up dramatically and that any attempts to restrict it in the future will risk breaking previously-working apps — think about how many years Adobe was able to slack because nobody wanted to break Flash even though it was a huge source of security bugs affecting most people on the Internet.

Apple's security model for iOS, as far as I can tell, is to be able to analyze all executable code in applications at review time. Being able to dynamically generate code does not work with this policy.

Apple libraries use private APIs but developers must not use them directly. If you allow developers to execute arbitrary bytes, they can submit app which does not call private API but will be able to call them later after approve. JavaScript is safe, because it can't call C API, but arbitrary JIT engine is not.

Sandboxing a JIT compiler is impossible to do perfectly, so there will always be the possibility of a sandbox escape, allowing the device to be jailbroken; but alsio for bad actors to take control of the device.

They could limit this functionality to only their apps. No problem.

That wouldn't work for third-party browsers.