Python grapples with Apple App Store rejections
1–10 of 118 posts
Re: Python grapples with Apple App Store rejections
#2Why can’t Apple just add “itms-services” as a forbidden URL scheme on a sandbox level? I don’t see why the App Sandbox can’t block (and isn’t already blocking) certain protocols.
Heck, what if I have a malicious web frame inside my app that tries to invoke “itms-services”, similar to this Polyfill.io debacle?
Re: Python grapples with Apple App Store rejections
#3Why can’t Apple just add “itms-services” as a forbidden URL scheme on a sandbox level? I don’t see why the App Sandbox can’t block (and isn’t already blocking) certain protocols. Heck, what if I have a malicious web frame inside my app that tries to invoke “itms-services”, similar to this Polyfill.io debacle?
Python just has to rot13 the scheme and hash the encrypted schemes.
Re: Python grapples with Apple App Store rejections
#4Why can’t Apple just add “itms-services” as a forbidden URL scheme on a sandbox level? I don’t see why the App Sandbox can’t block (and isn’t already blocking) certain protocols. Heck, what if I have a malicious web frame inside my app that tries to invoke “itms-services”, similar to this Polyfill.io debacle?
Python just has to rot13 the scheme and hash the encrypted schemes.
That came up in the original post with whether an obfuscation could be an acceptable workaround; but it came up that Apple really doesn’t like obfuscation techniques. The workaround for now is a compiler flag that excludes problematic code from iOS builds.
I’m still asking though why, if Apple doesn’t like apps which use this protocol, the sandbox is not intervening; as surely an approved app could have a malicious web view.
Re: Python grapples with Apple App Store rejections
#5Why can’t Apple just add “itms-services” as a forbidden URL scheme on a sandbox level? I don’t see why the App Sandbox can’t block (and isn’t already blocking) certain protocols. Heck, what if I have a malicious web frame inside my app that tries to invoke “itms-services”, similar to this Polyfill.io debacle?
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.
Re: Python grapples with Apple App Store rejections
#6Earlier quoted context omitted.
Python just has to rot13 the scheme and hash the encrypted schemes.
That came up in the original post with whether an obfuscation could be an acceptable workaround; but it came up that Apple really doesn’t like obfuscation techniques. The workaround for now is a compiler flag that excludes problematic code from iOS builds. I’m still asking though why, if Apple doesn’t like apps which use this protocol, the sandbox is not intervening; as surely an approved app could have a malicious w…
Sandboxed apps are allowed to use itms-services:// links, it's just not allowed in the App Store - iOS enterprise apps using in-house deployments can use it for installs and updates, and sandboxed Mac apps deployed outside of the App Store can use it as well.
However, App Review Guidelines forbid App Store apps from installing other apps, so that scheme gets scanned during review.
Re: Python grapples with Apple App Store rejections
#7Why can’t Apple just add “itms-services” as a forbidden URL scheme on a sandbox level? I don’t see why the App Sandbox can’t block (and isn’t already blocking) certain protocols. Heck, what if I have a malicious web frame inside my app that tries to invoke “itms-services”, similar to this Polyfill.io debacle?
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.
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.
Re: Python grapples with Apple App Store rejections
#8Earlier quoted context omitted.
That came up in the original post with whether an obfuscation could be an acceptable workaround; but it came up that Apple really doesn’t like obfuscation techniques. The workaround for now is a compiler flag that excludes problematic code from iOS builds. I’m still asking though why, if Apple doesn’t like apps which use this protocol, the sandbox is not intervening; as surely an approved app could have a malicious w…
Sandboxed apps are allowed to use itms-services:// links, it's just not allowed in the App Store - iOS enterprise apps using in-house deployments can use it for installs and updates, and sandboxed Mac apps deployed outside of the App Store can use it as well. However, App Review Guidelines forbid App Store apps from installing other apps, so that scheme gets scanned during review.
That makes some sense, but then I have a new question: Why doesn’t Apple have different certificate schemes for in-house versus App Store (if they don’t already)? In which case, the iOS Sandbox should be smart enough, and probably does already delineate, allowed functionality based on whether an app comes via App Store or via a private deployment.
Re: Python grapples with Apple App Store rejections
#9Obfuscation seems like a great way to get your developer account suspended. I suspect Apple is doing a lot more than just basic static analysis of the binary on disk.
Glad they went with a config option instead.
Re: Python grapples with Apple App Store rejections
#10It's not just Apple that pulls shenanigans like this.
Try building a Python app with PyInstaller while you have Windows Defender live scanning on, which is the default setting. You won't even be able to compile a binary without Defender preventing you from doing so.
Similarly, try running the binary produced by PyInstaller with Windows Defender on. Defender will say it's malicious and won't run it.
It's a bit dystopian that both major OS platforms go out of their way to prevent you from distributing and running your Python apps.