3 ms·

I’m not sure what the big deal with the url handler is, but I can’t imagine it causing remote code execution or other actual malicious behaviour. At this point

I’m not sure what the big deal with the url handler is, but I can’t imagine it causing remote code execution or other actual malicious behaviour. At this point Apple seems to be using simple substring matches, so if there is any exploit vector the malware authors can circumvent the check using "itms" + "-services" or something more sophisticated like ROT13.

gjsman-1000 2y ago
Which is also just why… the App Store review process claiming this is a problem doesn’t seem to make any sense. Imagine your app embeds a WebView at myapp.com/terms. It’s your Terms of Service, you show it to everyone when they sign up. Everyone clicks OK. After it’s on the App Store, you modify your WebView to include `itms-services` for some reason. You’ve just completely bypassed App Store review and gotten that URL handler into your app. The sandbox should stop you - but clearly the review processes don’t consider this possibility and are enforcing it before you publish. Why? My point is that the scanning for this handler, if Apple doesn’t want to allow it, seems misplaced if they wanted the ban to actually be effective.
- threeseed 2y ago
  The review process is about Apple giving you a clear direction about what is acceptable. There are many ways to get around their restrictions. But doing so will get you banned.
  - thfuran 2y ago
    I haven't heard anything to suggest that Apple intends the review process to give clear direction.
  - RobotToaster 2y ago
    They refused to tell him why it was rejected, hardly "clear direction"
    - threeseed 2y ago
      > The app installed or launched executable code. Specifically, the app uses the itms-services URL scheme to install an app. Seems like pretty clear direction to me: https://github.com/python/cpython/issues/120522 https://github.com/python/cpython/issues/120522
      - josephcsible 2y ago
        The app in question doesn't actually do any such thing, though.
        threeseed 2y ago
        The wording could be better. But it has been known for over a decade now that Apple searches binaries for strings. They've never done runtime execution checks which would pick up you actually making such an HTTP call.
        Ukv 2y ago
        My baseline would be similar to that which you get from modern compilers and automated tests. Something like: Lib/urllib/parse.py contains disallowed string "itms-services" at line 62 column 25 Reason: Apps may not install or launch executable code, such as through the itms-services URI schema. To get credit for "giving you a clear direction", I'd want them to make available and suggest a fix. In general that could be "if this is a false positive, click to request a human reviewer make an exemption" but ideally monitoring for this kind of issue in the first place (sudden increase in identical rejections) and fixing the broken check. Instead, Apple seem to omit the information on the first line that they likely already get from their internal tool, and not only don't suggest a fix but make the proper fix so unavailable that it's easier to get the language itself changed than a check in their review framework. > But it has been known for over a decade now that Apple searches binaries for strings. They've never done runtime execution checks which would pick up you actually making such an HTTP call. It's true that someone with folk knowledge about the way Apple does checks, gleaned about the process by other frustrated users, could likely infer the way in which Apple's test is broken and so eventually deduce the first line from the second line. That's not Apple giving a clear direction - that's developers managing to work around an inscrutable system.
  - ClassyJacket 2y ago
    It does the exact opposite of clear direction. It's an arbitrary black box

gjsman-1000 2y ago

Which is also just why… the App Store review process claiming this is a problem doesn’t seem to make any sense. Imagine your app embeds a WebView at myapp.com/terms. It’s your Terms of Service, you show it to everyone when they sign up. Everyone clicks OK. After it’s on the App Store, you modify your WebView to include `itms-services` for some reason. You’ve just completely bypassed App Store review and gotten that URL handler into your app. The sandbox should stop you - but clearly the review processes don’t consider this possibility and are enforcing it before you publish. Why? My point is that the scanning for this handler, if Apple doesn’t want to allow it, seems misplaced if they wanted the ban to actually be effective.

threeseed 2y ago
The review process is about Apple giving you a clear direction about what is acceptable. There are many ways to get around their restrictions. But doing so will get you banned.
- thfuran 2y ago
  I haven't heard anything to suggest that Apple intends the review process to give clear direction.
- RobotToaster 2y ago
  They refused to tell him why it was rejected, hardly "clear direction"
  - threeseed 2y ago
    > The app installed or launched executable code. Specifically, the app uses the itms-services URL scheme to install an app. Seems like pretty clear direction to me: https://github.com/python/cpython/issues/120522 https://github.com/python/cpython/issues/120522
    - josephcsible 2y ago
      The app in question doesn't actually do any such thing, though.
      - threeseed 2y ago
        The wording could be better. But it has been known for over a decade now that Apple searches binaries for strings. They've never done runtime execution checks which would pick up you actually making such an HTTP call.
        Ukv 2y ago
        My baseline would be similar to that which you get from modern compilers and automated tests. Something like: Lib/urllib/parse.py contains disallowed string "itms-services" at line 62 column 25 Reason: Apps may not install or launch executable code, such as through the itms-services URI schema. To get credit for "giving you a clear direction", I'd want them to make available and suggest a fix. In general that could be "if this is a false positive, click to request a human reviewer make an exemption" but ideally monitoring for this kind of issue in the first place (sudden increase in identical rejections) and fixing the broken check. Instead, Apple seem to omit the information on the first line that they likely already get from their internal tool, and not only don't suggest a fix but make the proper fix so unavailable that it's easier to get the language itself changed than a check in their review framework. > But it has been known for over a decade now that Apple searches binaries for strings. They've never done runtime execution checks which would pick up you actually making such an HTTP call. It's true that someone with folk knowledge about the way Apple does checks, gleaned about the process by other frustrated users, could likely infer the way in which Apple's test is broken and so eventually deduce the first line from the second line. That's not Apple giving a clear direction - that's developers managing to work around an inscrutable system.
- ClassyJacket 2y ago
  It does the exact opposite of clear direction. It's an arbitrary black box