3 ms·

...and flagging pages of memory as executable to get JIT (or suffer slow JS speed), which is currently blocked by iOS sandboxing.

easton 4y ago
Current browser research suggests you don’t need JIT, as evidenced by the ability to disable it on iOS. Wonder how close you could get to “great” performance with a Firefox port without JIT.
- varenc 4y ago
  In my experience, disabling the JIT on iOS (via Lockdown mode) results in slow performance and greatly increased battery drain on JS heavy websites and web views. The battery drain being the worst part. But of course with a site like HN there’s no noticeable difference.
- MBCook 4y ago
  If Google were allowed to publish Chrome, not based on Safari, but without a JIT tomorrow I think they’d get review bombed by normal users complaining about how it suddenly got slower than the current WebKit implementation. It’s mostly developers who care about the engine, end users are going to care far more about the performance.
varenc 4y ago
This is the big one that I think people don’t fully appreciate! Without using JIT (just-in-time compilation), your browser’s JavaScript will be terribly slow. But allowing JIT compilation (allowing an app to mark memory pages as executable, i.e. turn data into machine code) will also allow an app to introduce arbitrary new behavior after the app review and make it much easier for it to break out of the iOS sandbox. Stuff like calling private iOS APIs or security sensitivity APIs using machine code downloaded from an external source that an app reviewer will have no way of foreseeing. This isn’t possible otherwise. Even if the app/browser with JIT permissions isn’t malicious, it still opens up way more attack surface area. (Of course Safari already has the same risk) That said, I of course really want more genuine browser options on iOS. But there are real security reasons for Apple’s reluctance, though I’m sure this can solved. But alternative browsers come with different security concerns that don’t apply to just allowing app side-loading (since even now side-loaded apps can’t implement JIT compilation)
- MBCook 4y ago
  > Of course Safari already has the same risk Which is the reason the JIT runs in its own sandbox connected through IPC IIRC. Breaking the JIT isn’t supposed to even get you access to the parent process (Safari), let alone anything more, assuming you don’t have a kernel exploit too.
- scarface74 4y ago
  > Of course Safari already has the same risk Apple is perfectly well aware of this and in “lockdown mode”, Apple disabled JIT for Safari.
  - varenc 4y ago
    Agreed! I didn't mean for my comment to imply otherwise. (even Apple's refusal to allow other browsers, which would require JIT to be performant, illustrates Apple is aware the risk)
- madeofpalk 4y ago
  And there's ways forward - iOS already has a "web-browser" entitlement. Apple could use it, or a similar one, to give approved applications access to JIT. I think it would be fine for just a select few developers (Firefox, Chrome) to get ability to JIT. https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_web-browser https://developer.apple.com/documentation/bundleresources/en...

easton 4y ago

Current browser research suggests you don’t need JIT, as evidenced by the ability to disable it on iOS. Wonder how close you could get to “great” performance with a Firefox port without JIT.

varenc 4y ago
In my experience, disabling the JIT on iOS (via Lockdown mode) results in slow performance and greatly increased battery drain on JS heavy websites and web views. The battery drain being the worst part. But of course with a site like HN there’s no noticeable difference.
MBCook 4y ago
If Google were allowed to publish Chrome, not based on Safari, but without a JIT tomorrow I think they’d get review bombed by normal users complaining about how it suddenly got slower than the current WebKit implementation. It’s mostly developers who care about the engine, end users are going to care far more about the performance.

varenc 4y ago

This is the big one that I think people don’t fully appreciate! Without using JIT (just-in-time compilation), your browser’s JavaScript will be terribly slow. But allowing JIT compilation (allowing an app to mark memory pages as executable, i.e. turn data into machine code) will also allow an app to introduce arbitrary new behavior after the app review and make it much easier for it to break out of the iOS sandbox. Stuff like calling private iOS APIs or security sensitivity APIs using machine code downloaded from an external source that an app reviewer will have no way of foreseeing. This isn’t possible otherwise. Even if the app/browser with JIT permissions isn’t malicious, it still opens up way more attack surface area. (Of course Safari already has the same risk) That said, I of course really want more genuine browser options on iOS. But there are real security reasons for Apple’s reluctance, though I’m sure this can solved. But alternative browsers come with different security concerns that don’t apply to just allowing app side-loading (since even now side-loaded apps can’t implement JIT compilation)

MBCook 4y ago
> Of course Safari already has the same risk Which is the reason the JIT runs in its own sandbox connected through IPC IIRC. Breaking the JIT isn’t supposed to even get you access to the parent process (Safari), let alone anything more, assuming you don’t have a kernel exploit too.
scarface74 4y ago
> Of course Safari already has the same risk Apple is perfectly well aware of this and in “lockdown mode”, Apple disabled JIT for Safari.
- varenc 4y ago
  Agreed! I didn't mean for my comment to imply otherwise. (even Apple's refusal to allow other browsers, which would require JIT to be performant, illustrates Apple is aware the risk)
madeofpalk 4y ago
And there's ways forward - iOS already has a "web-browser" entitlement. Apple could use it, or a similar one, to give approved applications access to JIT. I think it would be fine for just a select few developers (Firefox, Chrome) to get ability to JIT. https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_web-browser https://developer.apple.com/documentation/bundleresources/en...