3 ms·

> Apple has legitimate technical reasons for not allowing other browser engines (well specifically the JS part). Intent matters. Oh please... source?

pls2halp 9y ago
1) JavaScript allows for arbitrary code execution 2) Apple’s App Store policies disallow the user from executing arbitrary code I think you can figure this out yourself.
- toxican 9y ago
  These are excuses, not valid technical reasons.
threeseed 9y ago
Remote execution of code is a very popular attack vector. Apple can negate this almost entirely by controlling JavascriptCore and WebKit and ensuring that their security models e.g. sandbox are tight and well tested. Leaving that up to third parties who may not be so vigilant compromises the security of the entire device.
0x0 9y ago
Efficient javascript needs to be JIT'ed, but that means your app needs to be granted API access to map writeable memory as executable, which is a security risk they are not willing to grant third party developers. So a third party browser/js engine will likely be quite slow. I guess this would give users of a bad impression of iOS perfomance as a whole then, if other browser engines were allowed and became popular?
- jononor 9y ago
  If other browser engines became very popular it says something about how bad/limited the default offering is. It usually takes a lot of work before people switch away from defaults. People continued to use IE for years for example
  - millstone 9y ago
    Chrome as the sole advertisement on the most valuable piece of web real estate in the universe might have been a factor too.
- kbenson 9y ago
  Restricting the JS engine but allowing other browser engines to tie into it so you could leverage different browser's rendering and CSS features would be a step up and would sidestep much of the problem.
- devit 9y ago
  It's not a security risk (assuming a properly engineered OS).
  - 0x0 9y ago
    All OSes have bugs, and the XNU kernel certainly has had its share, so removing the ability to execute arbitrary code definitively makes exploitation of buffer overflows etc in 3rd party apps much harder.

pls2halp 9y ago

1) JavaScript allows for arbitrary code execution 2) Apple’s App Store policies disallow the user from executing arbitrary code I think you can figure this out yourself.

toxican 9y ago
These are excuses, not valid technical reasons.

threeseed 9y ago

Remote execution of code is a very popular attack vector. Apple can negate this almost entirely by controlling JavascriptCore and WebKit and ensuring that their security models e.g. sandbox are tight and well tested. Leaving that up to third parties who may not be so vigilant compromises the security of the entire device.

0x0 9y ago

Efficient javascript needs to be JIT'ed, but that means your app needs to be granted API access to map writeable memory as executable, which is a security risk they are not willing to grant third party developers. So a third party browser/js engine will likely be quite slow. I guess this would give users of a bad impression of iOS perfomance as a whole then, if other browser engines were allowed and became popular?

jononor 9y ago
If other browser engines became very popular it says something about how bad/limited the default offering is. It usually takes a lot of work before people switch away from defaults. People continued to use IE for years for example
- millstone 9y ago
  Chrome as the sole advertisement on the most valuable piece of web real estate in the universe might have been a factor too.
kbenson 9y ago
Restricting the JS engine but allowing other browser engines to tie into it so you could leverage different browser's rendering and CSS features would be a step up and would sidestep much of the problem.
devit 9y ago
It's not a security risk (assuming a properly engineered OS).
- 0x0 9y ago
  All OSes have bugs, and the XNU kernel certainly has had its share, so removing the ability to execute arbitrary code definitively makes exploitation of buffer overflows etc in 3rd party apps much harder.