5 ms·

fwiw: the App Store also prohibits JITed code or in general code pulled in after app publishing. I guess the idea is that (at least in theory) that Apple sees a

by xrisk 4y ago

fwiw: the App Store also prohibits JITed code or in general code pulled in after app publishing. I guess the idea is that (at least in theory) that Apple sees all code that an app runs.

brundolf 4y ago
Not all code pulled in after app publishing; it's very common to push at least JS code to an app after the user's installed it, without going through the App Store But I think they draw the line at native (read: unsafe) code, which, is not totally unreasonable
- JamesSwift 4y ago
  Its always been a sort of wink-wink agreement, never allowing exceptions as far as I'm aware. Its much more common to do post-release updates of JS than native, but I think every native dev has done some form of dynamic code at some point. In one app we did, we ended up disabling the dynamic update but still ran a handrolled VM with dynamically interpreted code files which we baked into the app. Its all manually reviewed in the end, so no guarantees they would even catch it anyways.
  - brundolf 4y ago
    Interesting. I'll admit I don't have much first-hand knowledge of the process > but I think every native dev has done some form of dynamic code at some point This is a little ambiguous; theoretically a VM - even a custom one - would still be above-board because the native code is static. My understanding was that the main problem with third-party browsers is third-party JS engines, but only because any modern JS engine has to JIT in order to perform the way people expect; the app developer takes responsibility for generating unsafe native code, which has the potential to wreak all kinds of havoc on the user's system in a way that dynamically-updated JS code for example can't It would be interesting to try and submit a fully-custom browser with a non-JIT JS interpreter to the App Store. I bet they'd allow it; just, nobody would use it because it would be slow as mud
    - JamesSwift 4y ago
      We should be clear here that "JIT"/VM vs sandboxed code are two different considerations. Regardless of how your code is interpreted/compiled/run, you still are operating within the app sandbox. So most arguments about safety etc are fairly useless. The only "valid" line of argument is more in the UX space. Apple isn't able to vet the userflows in the same way if you do a post-release update. And to be clear when I say a handrolled VM, I mean that the VM knows how to interpret dynamic things into native things. This is a lot more powerful in Objective-C since it uses message passing anyways so you could theoretically build a full app in some JSON payload. So sure your native code is static, but thats because its just 1 function called 'eval'. This is still possible in Swift but requires more explicitness since it doesn't have the same dynamicism built in. It doesn't have to be entire apps that are custom though. Most app devs use it for things like customer-editable content. Think of things like the ability to update home screen layouts, or tab layouts/behavior. Depending on how much baked-in customization you build this can be extremely robust.
      - avianlyric 4y ago
        Preventing the execution of locally generated native code is a significant part of the iOS sandbox. It allows Apple to statically analysis binaries uploaded to the App Store and potential detect and prevent malicious instructions. Then they just need to harden the OS APIs, safe in the knowledge that you an app can’t execute arbitrary CPU instructions, and potentially escape kernel control. Allowing a JITed web browser on iOS means handing over the right mark arbitrary lumps of memory as executable, which substantially increases the available attack surface. Having said that, I strongly suspect concerns around arbitrary code escaping kernel control only applies to older iPhone running substantially less sophisticated SoC than you find in a modern iPhone. Certainly any Apple SoC during the M1 era, and a good few generations before, have all the modern accoutrements needed to allow arbitrary code execution, while ensuring the kernel can always intercede and halt execution or block dangerous calls. If they didn’t have these abilities, then there’s no way an M1 Mac could efficiently run a VM, or be considered a secure platform by modern standards.
criddell 4y ago
There are development environments that run on the device. For example, Pyto[1] is for developing and running Python code. [1]: https://apps.apple.com/us/app/pyto-python-3/id1436650069 https://apps.apple.com/us/app/pyto-python-3/id1436650069
- MBCook 4y ago
  But that’s probably a regular interpreter, not a JIT.
- judge2020 4y ago
  That doesn't use JIT. In theory a browser like Chrome doesn't have to either, but then Apple might be lambasted since presumably JIT is required to be competitive against Safari in terms of performance.
mtomweb 4y ago
They allow Wechat and Alipay to pull in code after publishing (See Mini-Apps). Regardless there's no evidence that Safari would do a better job at protecting user's security than Firefox or Chrome/Edge.
- judge2020 4y ago
  Based on this video[0], it looks like "mini-apps" are just webviews, as everything is either .js, .css, or .wxml (html). Thus, anything that integrates with WeChat or system APIs is going through some API within the wechat binary itself which allows Apple's static analysis to inspect the API usage during App Store review. 0: https://youtu.be/cOm9XKga7l0 https://youtu.be/cOm9XKga7l0
  - mtomweb 4y ago
    Ish. There's bridges to native functions and there are a lot of functions. For example you can write a mini-app that connects to bluetooth. It's essentially loading dynamic code that bridges to native code.
    - paulmd 4y ago
      So your point is... that bluetooth is accessible via browser api? Yes, that's true, Bluefy is a whole browser built around that API, for example. https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo... https://apps.apple.com/us/app/bluefy-web-ble-browser/id1492822055 https://apps.apple.com/us/app/bluefy-web-ble-browser/id14928... So what? Apple has never required review of every web page you load with safari, regardless of which browser APIs they use... the browser is the browser. That is the farthest Apple goes on "dynamic content" but yes, it is potentially a pretty wide net given the various APIs and extensions. But from Apple's perspective it is also a defined boundary.
      - mtomweb 4y ago
        Expressly forbidden: - install, or execute code which introduces or changes features or functionality of the app The only exception they've crafted is for educational purposes. 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
bogwog 4y ago
I suspect that has more to do with preventing an App Store competitor than security. Apps are completely sandboxed on iOS, and there's no way in hell Apple is auditing every app on the store in any meaningful way.
- judge2020 4y ago
  > A testing tool called Mercury runs through static and dynamic analysis processes, with the tool allowing Apple to see inside apps to check for hidden code or abuse, and there are other review tools that Apple has nicknamed "Magellan" and "Columbus." After automated testing, apps receive human oversight. > Dynamic testing includes everything from battery usage to file system access and privacy requests to access device hardware like the camera and microphone, while static analysis checks app size, entitlements, in-app purchases, keywords, descriptions, and more. > In 2015, Apple discussed acquiring SourceDNA, a company that made a tool to allow companies to see the code inside apps. Apple did end up purchasing the company and using its engineers to design a new tool for app oversight. https://forums.macrumors.com/threads/apple-rejected-approximately-35-of-apps-submitted-to-app-store-between-2017-and-2019.2295252/ https://forums.macrumors.com/threads/apple-rejected-approxim...
usrn 4y ago
Apple doesn't see any of the code. They pay someone to poke at the GUI for ~15 minutes with an HTTP proxy running. That's it. If you want an app store where people see code use f-droid.
- the_gipsy 4y ago
  Maybe there are random deep inspections, but yea usually it's just some poor soul poking the UI and scanning some superficial analysis.
- avianlyric 4y ago
  They don’t need to. They’re perfectly capable to statically analysing an app binary and looking for calls to APIs app aren’t allowed to use, or containing CPU instructions that are potentially dangerous. We know this because when dev submit apps that call private APIs they get very quick rejection. But hiding private API call behind obfuscated blobs of dynamic code can get you through app review, provided you don’t expose the functionality in your UI. Additionally the modern App Store deployment process involves uploading you app in an intermediate format, only partially compiled, so apple can dynamically recompile your app to target new CPUs, and optimism your app to use new hardware without intervention by the dev.
the_gipsy 4y ago
In practice this is complete bullshit, most apps pull some code in some way or another.

by xrisk 4y ago

fwiw: the App Store also prohibits JITed code or in general code pulled in after app publishing. I guess the idea is that (at least in theory) that Apple sees all code that an app runs.

brundolf 4y ago

Not all code pulled in after app publishing; it's very common to push at least JS code to an app after the user's installed it, without going through the App Store But I think they draw the line at native (read: unsafe) code, which, is not totally unreasonable

JamesSwift 4y ago
Its always been a sort of wink-wink agreement, never allowing exceptions as far as I'm aware. Its much more common to do post-release updates of JS than native, but I think every native dev has done some form of dynamic code at some point. In one app we did, we ended up disabling the dynamic update but still ran a handrolled VM with dynamically interpreted code files which we baked into the app. Its all manually reviewed in the end, so no guarantees they would even catch it anyways.
- brundolf 4y ago
  Interesting. I'll admit I don't have much first-hand knowledge of the process > but I think every native dev has done some form of dynamic code at some point This is a little ambiguous; theoretically a VM - even a custom one - would still be above-board because the native code is static. My understanding was that the main problem with third-party browsers is third-party JS engines, but only because any modern JS engine has to JIT in order to perform the way people expect; the app developer takes responsibility for generating unsafe native code, which has the potential to wreak all kinds of havoc on the user's system in a way that dynamically-updated JS code for example can't It would be interesting to try and submit a fully-custom browser with a non-JIT JS interpreter to the App Store. I bet they'd allow it; just, nobody would use it because it would be slow as mud
  - JamesSwift 4y ago
    We should be clear here that "JIT"/VM vs sandboxed code are two different considerations. Regardless of how your code is interpreted/compiled/run, you still are operating within the app sandbox. So most arguments about safety etc are fairly useless. The only "valid" line of argument is more in the UX space. Apple isn't able to vet the userflows in the same way if you do a post-release update. And to be clear when I say a handrolled VM, I mean that the VM knows how to interpret dynamic things into native things. This is a lot more powerful in Objective-C since it uses message passing anyways so you could theoretically build a full app in some JSON payload. So sure your native code is static, but thats because its just 1 function called 'eval'. This is still possible in Swift but requires more explicitness since it doesn't have the same dynamicism built in. It doesn't have to be entire apps that are custom though. Most app devs use it for things like customer-editable content. Think of things like the ability to update home screen layouts, or tab layouts/behavior. Depending on how much baked-in customization you build this can be extremely robust.
    - avianlyric 4y ago
      Preventing the execution of locally generated native code is a significant part of the iOS sandbox. It allows Apple to statically analysis binaries uploaded to the App Store and potential detect and prevent malicious instructions. Then they just need to harden the OS APIs, safe in the knowledge that you an app can’t execute arbitrary CPU instructions, and potentially escape kernel control. Allowing a JITed web browser on iOS means handing over the right mark arbitrary lumps of memory as executable, which substantially increases the available attack surface. Having said that, I strongly suspect concerns around arbitrary code escaping kernel control only applies to older iPhone running substantially less sophisticated SoC than you find in a modern iPhone. Certainly any Apple SoC during the M1 era, and a good few generations before, have all the modern accoutrements needed to allow arbitrary code execution, while ensuring the kernel can always intercede and halt execution or block dangerous calls. If they didn’t have these abilities, then there’s no way an M1 Mac could efficiently run a VM, or be considered a secure platform by modern standards.

criddell 4y ago

There are development environments that run on the device. For example, Pyto[1] is for developing and running Python code. [1]: https://apps.apple.com/us/app/pyto-python-3/id1436650069 https://apps.apple.com/us/app/pyto-python-3/id1436650069

MBCook 4y ago
But that’s probably a regular interpreter, not a JIT.
judge2020 4y ago
That doesn't use JIT. In theory a browser like Chrome doesn't have to either, but then Apple might be lambasted since presumably JIT is required to be competitive against Safari in terms of performance.

mtomweb 4y ago

They allow Wechat and Alipay to pull in code after publishing (See Mini-Apps). Regardless there's no evidence that Safari would do a better job at protecting user's security than Firefox or Chrome/Edge.

judge2020 4y ago
Based on this video[0], it looks like "mini-apps" are just webviews, as everything is either .js, .css, or .wxml (html). Thus, anything that integrates with WeChat or system APIs is going through some API within the wechat binary itself which allows Apple's static analysis to inspect the API usage during App Store review. 0: https://youtu.be/cOm9XKga7l0 https://youtu.be/cOm9XKga7l0
- mtomweb 4y ago
  Ish. There's bridges to native functions and there are a lot of functions. For example you can write a mini-app that connects to bluetooth. It's essentially loading dynamic code that bridges to native code.
  - paulmd 4y ago
    So your point is... that bluetooth is accessible via browser api? Yes, that's true, Bluefy is a whole browser built around that API, for example. https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo... https://apps.apple.com/us/app/bluefy-web-ble-browser/id1492822055 https://apps.apple.com/us/app/bluefy-web-ble-browser/id14928... So what? Apple has never required review of every web page you load with safari, regardless of which browser APIs they use... the browser is the browser. That is the farthest Apple goes on "dynamic content" but yes, it is potentially a pretty wide net given the various APIs and extensions. But from Apple's perspective it is also a defined boundary.
    - mtomweb 4y ago
      Expressly forbidden: - install, or execute code which introduces or changes features or functionality of the app The only exception they've crafted is for educational purposes. 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.

bogwog 4y ago

I suspect that has more to do with preventing an App Store competitor than security. Apps are completely sandboxed on iOS, and there's no way in hell Apple is auditing every app on the store in any meaningful way.

judge2020 4y ago
> A testing tool called Mercury runs through static and dynamic analysis processes, with the tool allowing Apple to see inside apps to check for hidden code or abuse, and there are other review tools that Apple has nicknamed "Magellan" and "Columbus." After automated testing, apps receive human oversight. > Dynamic testing includes everything from battery usage to file system access and privacy requests to access device hardware like the camera and microphone, while static analysis checks app size, entitlements, in-app purchases, keywords, descriptions, and more. > In 2015, Apple discussed acquiring SourceDNA, a company that made a tool to allow companies to see the code inside apps. Apple did end up purchasing the company and using its engineers to design a new tool for app oversight. https://forums.macrumors.com/threads/apple-rejected-approximately-35-of-apps-submitted-to-app-store-between-2017-and-2019.2295252/ https://forums.macrumors.com/threads/apple-rejected-approxim...

usrn 4y ago

Apple doesn't see any of the code. They pay someone to poke at the GUI for ~15 minutes with an HTTP proxy running. That's it. If you want an app store where people see code use f-droid.

the_gipsy 4y ago
Maybe there are random deep inspections, but yea usually it's just some poor soul poking the UI and scanning some superficial analysis.
avianlyric 4y ago
They don’t need to. They’re perfectly capable to statically analysing an app binary and looking for calls to APIs app aren’t allowed to use, or containing CPU instructions that are potentially dangerous. We know this because when dev submit apps that call private APIs they get very quick rejection. But hiding private API call behind obfuscated blobs of dynamic code can get you through app review, provided you don’t expose the functionality in your UI. Additionally the modern App Store deployment process involves uploading you app in an intermediate format, only partially compiled, so apple can dynamically recompile your app to target new CPUs, and optimism your app to use new hardware without intervention by the dev.

the_gipsy 4y ago

In practice this is complete bullshit, most apps pull some code in some way or another.