3 ms·

Rather than just downvote you for stating incorrect things with such conviction, I'll refer you to Apple's own website :) https://support.apple.com/en-eg/guide

Rather than just downvote you for stating incorrect things with such conviction, I'll refer you to Apple's own website :) https://support.apple.com/en-eg/guide/security/sec15bfe098e/web https://support.apple.com/en-eg/guide/security/sec15bfe098e/... > Memory pages marked as both writable and executable can be used only by apps under tightly controlled conditions: The kernel checks for the presence of the Apple-only dynamic code-signing entitlement. Even then, only a single mmap call can be made to request an executable and writable page, which is given a randomized address. Safari uses this functionality for its JavaScript Just-in-Time (JIT) compiler. In other words, Apple only allows Apple to do Javascript JIT on iOS.

btown 3y ago
While this is technically true, WKWebView (which I believe is used by all non-Apple browsers on iOS) does allow Javascript JIT, because the renderer runs in a subprocess with these permissions. See: https://news.ycombinator.com/item?id=19379739 https://news.ycombinator.com/item?id=19379739 . But there are many other reasons besides JIT to want to have non-Apple-Webkit-based rendering engines (including wanting different JS engines with their own JIT) - and so IMO it's very much a restriction that regulators should force Apple to relax. The security considerations should be no different than those on a desktop platform.
- gameoverhumans 3y ago
  Interesting, thanks. Didn't realise there was ways to embed WebKit views that also got JIT (escaped the walled garden a while ago!) Still, my original point still stands. As you note, you can't have Spidermonkey running on iOS doing JIT. But you also couldn't have Gecko doing rendering and using WebKit JIT, either. ... Right? > The security considerations should be no different than those on a desktop platform. Completely agree. The "it's for your own security" angle is just usual Apple FUD to make their anti-competitive stance seem pro-consumer.
  - saagarjha 3y ago
    Your control over the web process is very limited, correct.

btown 3y ago

While this is technically true, WKWebView (which I believe is used by all non-Apple browsers on iOS) does allow Javascript JIT, because the renderer runs in a subprocess with these permissions. See: https://news.ycombinator.com/item?id=19379739 https://news.ycombinator.com/item?id=19379739 . But there are many other reasons besides JIT to want to have non-Apple-Webkit-based rendering engines (including wanting different JS engines with their own JIT) - and so IMO it's very much a restriction that regulators should force Apple to relax. The security considerations should be no different than those on a desktop platform.

gameoverhumans 3y ago
Interesting, thanks. Didn't realise there was ways to embed WebKit views that also got JIT (escaped the walled garden a while ago!) Still, my original point still stands. As you note, you can't have Spidermonkey running on iOS doing JIT. But you also couldn't have Gecko doing rendering and using WebKit JIT, either. ... Right? > The security considerations should be no different than those on a desktop platform. Completely agree. The "it's for your own security" angle is just usual Apple FUD to make their anti-competitive stance seem pro-consumer.
- saagarjha 3y ago
  Your control over the web process is very limited, correct.