[HN Gopher] Python grapples with Apple App Store rejections
___________________________________________________________________
Python grapples with Apple App Store rejections
Author : leephillips
Score : 115 points
Date : 2024-06-27 21:09 UTC (1 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| gjsman-1000 wrote:
| Why 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?
| PaulHoule wrote:
| Python just has to rot13 the scheme and hash the encrypted
| schemes.
| gjsman-1000 wrote:
| 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.
| favorited wrote:
| 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.
| gjsman-1000 wrote:
| 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.
| praseodym wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I haven't heard anything to suggest that Apple intends
| the review process to give clear direction.
| RobotToaster wrote:
| They refused to tell him why it was rejected, hardly
| "clear direction"
| ClassyJacket wrote:
| It does the exact opposite of clear direction. It's an
| arbitrary black box
| lilyball wrote:
| The URL is likely used from within Apple frameworks for various
| purposes, and therefore it's possible for an app process to
| open the URL even without the app itself knowing about the URL.
| TillE wrote:
| Obfuscation 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.
| veeti wrote:
| They are opaquely rejecting apps for just literally containing
| the string "itms-services" in the binary and you still give
| them credit for a more sophisticated analysis? Lol.
| nozzlegear wrote:
| We can assume that a simple string search is one of the basic
| checks they do before moving onto more advanced checks.
| malfist wrote:
| Why can we assume that?
| heavyset_go wrote:
| It'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.
| josephcsible wrote:
| It's not just Python apps. It's anything by small-time
| developers without expensive certificates. I once used MSVC to
| compile a C program that was little more than a "Hello, World",
| and Defender called it the Win32/Wacatac Trojan.
| heavyset_go wrote:
| > _It 's not just Python apps. It's anything by small-time
| developers without expensive certificates._
|
| This is definitely the case and has been my experience, as
| well.
|
| We live in some dark times when it comes to building and
| sharing anything as small developers, especially if the
| things you're building are free.
|
| I stopped updating my open-source Mac apps because I can't
| justify the cost of jumping over artificial hurdles Apple
| puts in place that ensure users can't run the apps they want
| to use. I have other hobbies where spending money actually
| gives me tangible goods and benefits versus paying an
| arbitrary yearly tax for the privilege to build stuff that
| ultimately benefits Apple.
| OsrsNeedsf2P wrote:
| This was the case for our open source app as well. The only
| reason we're on Apple is one of our users likes the app so
| much, they handle the certificates.
|
| Which is deeply ironic, if you think about it.
| Brian_K_White wrote:
| It is super interesting that someone who is not you can
| take care of proving to Apple that you are really you so
| that Apple can assert to all other users that they have
| verified that you are really you because they made you
| prove it.
|
| This world is just awesome. :)
| exe34 wrote:
| > stopped updating my open-source Mac apps because I can't
| justify the cost of jumping over artificial hurdles Apple
| puts in place that ensure users can't run the apps they
| want to use.
|
| hah, that's the exact reason I stopped using os x and went
| full Linux on my old Mac book air about 8 years ago.
| ronsor wrote:
| Defender calls anything Wacatac.
|
| Ironically I've seen tons of actual malware that doesn't even
| give the slightest warning.
| lagniappe wrote:
| I made a single for loop in Go at work to show a coworker,
| that binary got flagged as malware.
| lilyball wrote:
| Why does urllib have this URL scheme anyway? If Python libraries
| are hard-coding knowledge about Apple proprietary stuff, then it
| should be no surprise that Apple may take issue with that.
| amelius wrote:
| Can we have Separation of Powers on our digital platforms?
|
| It is pretty shitty that the one who sells phones also determines
| what goes on them.
___________________________________________________________________
(page generated 2024-06-27 23:00 UTC)