5 ms·

What design choices mean third party Android browsers can do JIT but third party iPhone ones can't?

• saagarjha 8y ago
  Android doesn't do codesigning, at least in the way that iOS does: on iOS, all code that executes must be signed and approved by Apple before it is allowed to be loaded by the OS into memory (with some exceptions e.g. Safari). JIT gets around this because applications can now generate and execute arbitrary code, which is obviously something that Apple doesn't want. So this basically means that you are not allowed to put apps like this on the App Store.
  • lern_too_spel 8y ago
    It is a result of Apple's broken security model. On Android, generated code has no more provoleges than the code that generated it, just like interpreted code.
    • saagarjha 8y ago
      > On Android, generated code has no more provoleges than the code that generated it, just like interpreted code. This is true on iOS as well, just it is on almost every other operating system: you don't get to expand your privileges by being able to generate code because said code still runs in your process. There's no "broken security model" here; in a sense iOS has a much stronger security model than Android does because all code that gets executed can be statically verified beforehand.
      • lern_too_spel 8y ago
        > in a sense iOS has a much stronger security model than Android does because all code that gets executed can be statically verified beforehand. The code generator can be statically analyzed in the same way that an interpreter can. The security model is broken in the sense that it applies a wholly unnecessary restriction on apps, which means not only can you not have your own fast JavaScript engine on iOS but you can't have fast emulators or run other languages fast on the device either.
        • saagarjha 8y ago
          > The code generator can be statically analyzed in the same way that an interpreter can. Unless the state of static analysis has somehow changed significantly without me realizing it, no, this does not help at all. While I can (to some extent) verify the code in the code generator itself, I cannot verify that the code generator will not generate arbitrary code unless it lists out all the code it can possibly generate, in which case it's, well, an interpreter. The task of verifying program behavior is now shifted from static analysis on a compiled binary to dynamic instrumentation of a running program, which is much harder to do.
          • lern_too_spel 8y ago
            It is trivial to prove that anything that a code generator can emit can be translated into something that an interpreter can interpret. Run the generated code through an interpreter. QED.
            • saagarjha 8y ago
              > It is trivial to prove that anything that a code generator can emit can be translated into something that an interpreter can interpret. That's not what we are trying to prove, though; we're trying to show that the generated code does not perform certain undesirable operations. this is much harder to do with dynamically generated code than static code.
              • deleted 8y ago
                [deleted]