LWN: Comments on "Python grapples with Apple App Store rejections"

Good temporary solution

Cyberax — Thu, 04 Jul 2024 19:59:35 +0000

> you must use iOS provided services for TLS

That's not quite true. You can use your own TLS implementation, although you might have to apply for an exemption from the ATS requirements.

Good temporary solution

hkario — Thu, 04 Jul 2024 14:36:03 +0000

The OS in iDevices already can snoop on all things the applications do, you must use iOS provided services for TLS, that means it's the OS that encrypts the data, not the application.

Alternatively

norphonic — Thu, 04 Jul 2024 10:52:42 +0000

While I would normally be supportive for such arguments this case is hard to rally behind. App Store had blocked it precisely because of App Store related feature that shouldn't be there and if anything it just highlights how much bloat and weirdware is lurking in the depth of Python standard library.

Good temporary solution

edeloget — Sat, 29 Jun 2024 01:13:02 +0000

> Sorry but that's nonsense. If Apple wants to block apps from opening "itms-services:" URLs then they should teach the OS to not open them in the first place.

Does that mean that the OS should be able to snoop on all application communication? I'm not sure it's a good idea :)

Anyway, checking for an itms-services string is dumb. There are so many ways to not have said string in the binary and yet have a way to rebuild it that ("itms" + "-" + "services" ? rot13 ? base64 ? xor with a simple pattern ?...) that finding the string istelf should be a sign that the developper is not trying to game the verification.

It's not that Apple broke python, or that CPython is broken. It's just plain stupid to even try to match the pattern itself.

Alex's approach

NYKevin — Fri, 28 Jun 2024 18:53:34 +0000

The question is not why Python should care about iDevices. The question is why Python should care about the Apple ecosystem at all. itms-services is not a standard protocol. It appears in no RFC (that I've ever heard of). It is purely an Apple thing. And now it is causing problems, that were also created by Apple.

Why should Python even waste time thinking about any of this? Just yeet the whole thing out of urllib, and Apple developers who want to use this protocol for whatever reason can take a PyPI dependency.

But you don't even need a PyPI dependency, because urllib already DTRT on protocols it does not understand:

>>> urllib.parse.urlsplit('nonsense://www.example.com:80/foo/bar')
SplitResult(scheme='nonsense', netloc='www.example.com:80', path='/foo/bar', query='', fragment='')

The string itms-services only appears in a list that tells the parser that it "uses netloc" (i.e. it should have a netloc part after the scheme, unlike say file://). As you can see above, it will happily parse nonsense schemes with netloc even if they are absent from said list. So at most, this might get you stricter checking in a few corners of the API, but it is probably not a showstopper.

Time to stop

jzb — Fri, 28 Jun 2024 18:39:18 +0000

Speculating on the collapse of the EU is well beyond the topic and not useful. It's not going to lead anywhere good, so let's stop here.

Regulatory solution

zdzichu — Fri, 28 Jun 2024 17:34:52 +0000

What about this fantasy of EU collapse? Someone has been feeding of russian propaganda?

Regulatory solution

khim — Fri, 28 Jun 2024 17:26:07 +0000

> If Apple is perceived as gaming the rules, then the rules will change. In a lot less than 10 years.

How do you know? Apple is gaming the rules the whole existence of Apple. It's, essentially, what makes Apple Apple.

Gaming the system is in Apple's DNA. Remember how Jobs swindled Wozniak before Apple even existed and paid $375 instead of $5000? That's how Apple operated it's whole life.

> And in a way that is likely to be - shall we say - painful ... depending on how seriously the regulators are pissed off.

I've heard these talks for decades, sorry. Nothing happens in a lot less than 10 years in European courts and Apple knows that.

And now, almost half-century after it was founded, you say that it would be punished for something it successfully did for half-century? Count me unimpressed. Sure, it would be punished, but so what? That's part of the business-plan and it works.

Just as one example: how long did it took for EU to make it use normal USB connector for it's phone?

Regulatory solution

Wol — Fri, 28 Jun 2024 17:01:34 +0000

> Now, if you assume a different scenario, where EU doesn't collapse in 10 years and continue to bring billions for 100 years then sure, “playing fair” would be better, but how do you know EU would survive, let alone thrive, for 100 years?

No. I'm assuming a different scenario where that doesn't matter. If Apple is perceived as gaming the rules, then the rules will change. In a lot less than 10 years. And in a way that is likely to be - shall we say - painful ... depending on how seriously the regulators are pissed off.

Cheers,
Wol

Alex's approach

mb — Fri, 28 Jun 2024 15:43:34 +0000

>Google it, discover the problem, write and carry their own patch

That's Ok. They decided to play by the rules of Apple. So they should carry the workaround for Apple's stupid decisions.

Why should Python care?

>Apple doesn't want it there? Fine

Yes. It's fine. It's their decision and their problem.

>Fine, it's gone. Good riddance.

Do you realize that this is not a fix of the actual problem?
Apple will append something else to the list of forbidden words tomorrow.

Why should we let Apple indirectly make stupid decisions for an independent Open Source project?

Strip the functionality altogether.

smurf — Fri, 28 Jun 2024 15:21:31 +0000

> I'd question whether something like itms-services scheme support really belongs in a standard library to begin with.

Well, this one's easy.

Some URL schemes contain a network location ("netloc"). Some do not.

People tend to expect the URL parser to reply with a struct that breaks out the netloc for URLs that contain them.

As urllib.parse contains a whitelist of URLs with netlocs (sensibly IMHO) it needs to contain this string.

Good temporary solution

smurf — Fri, 28 Jun 2024 15:17:40 +0000

Sorry but that's nonsense. If Apple wants to block apps from opening "itms-services:" URLs then they should teach the OS to not open them in the first place.

Parsing an app for the string doesn't help. Malicious apps will just obscure the string while people who legitimately ship an URL parser (in Python, itms-services is in the "uses_netloc" list so that the parser returns the result the caller expects) need to add brain-dead patches or other workarounds.

Regulatory solution

khim — Fri, 28 Jun 2024 13:56:54 +0000

> You play fair by the regulators, they play fair with you.
You try to game the rules, the regulators will do the same.

Sure, but why would that mean that Apple does the wrong thing? Apple Store brings around $100 billions per year to Apple, significant percent of that from EU, which means it would bring $1 trillion or so before collapse of EU in 10, after which EU would stop bringing billions to Apple, one way or another.

And if instead of fighting for these $100 billion (and spending maybe $10 billion on courts and fines) Apple would “play fair” before collapse of EU the it would get $0.5 trillion which is much less than $1 trillion.

Now, if you assume a different scenario, where EU doesn't collapse in 10 years and continue to bring billions for 100 years then sure, “playing fair” would be better, but how do you know EU would survive, let alone thrive, for 100 years?

Regulatory solution

Wol — Fri, 28 Jun 2024 13:24:48 +0000

If the regulators agree with you, Apple are likely to find things get worse next time round the loop ...

You play fair by the regulators, they play fair with you.

You try to game the rules, the regulators will do the same.

Cheers,
Wol

Alternatively

dskoll — Fri, 28 Jun 2024 13:15:55 +0000

If you play Apple's app store game, you have lost. That's an incontrovertible fact.

The only way not to lose is not to play the game. Free Software devs should not spend the energy required to tapdance as Apple fires bullets at their feet.

Regulatory solution

donald.buczek — Fri, 28 Jun 2024 12:50:40 +0000

You're right, that's disgusting.

Regulatory solution

khim — Fri, 28 Jun 2024 12:15:06 +0000

> This is not the case?

Judge for yourself. Just look on the picture and read the story.

EU told Apple that everyone should be able to download app from third-party web site. And Apple delivered! App really comes from third-party web site. Specifically signed copy that Apple signed and gave you permission to install on 1 (one) device.

And they charge 0.5$ for the privilege. Only if you are big and successful, of course. But if you are not then you have to provide Apple a stand-by letter of credit in the amount of €1,000,000 from a financial institution that’s at least A-rated or equivalent by S&P, Fitch, or Moody’s, and maintain that standby letter of credit as long as your alternative app marketplace is in operation. It wouldn't be used, don't worry, it's only there “just in case”, you see.

And since Apple only gives you right to instal 1 (one) copy of app on 1 (one) device and you pay $0.5 for the privilege any update requires the end user to start the download process to save you money! Perfect, isn't?

> I just assumed "other app store" would mean independent things like F-Droid.

Well. There were two goal Apple wanted to achieve:

Independent App Store should look and act like an independent app store
Apple should control everything, earn money from each install and be able to reject request for installation for any reason.

They achieved that.

Whether to call that “an independent app store” is open question. Many say that this is not an independent app store, but this would require another court process, of course, and the end result would be equally silly.

Ultimately the only fair treatment of Apple is two-fold:

Decide how fast Apple needs to be outlawed in your country and there would be law that would forbid to buy and sell Apple devices (everyone accepts that such things take time not to cause immediate riots).
Ensure that you are moving law toward that goal steadily and consistently.

Anything else is absolute foolishness, none of independent countries should accept things like that. Well, maybe US is an exception since Apple can be controlled by various security agencies using internally planted people. But for everyone else it's either allowing Apple iOS devices or staying independent country, these things couldn't exist simultaneously. MacOS is moving in the same direction, BTW, it's a just a tiny bit behind.

Good temporary solution

taladar — Fri, 28 Jun 2024 09:48:27 +0000

This is a typical security theater check. All the options such as obfuscation and configuration exist for the nefarious apps as well so checking for the string does nothing useful.

Regulatory solution

donald.buczek — Fri, 28 Jun 2024 09:40:52 +0000

> Are you even sure that something that lets you download apps from Apple and then without the ability to automatically upgrade them deserves the name third-party app store?

No, I have no idea how this is implemented. I've just remembered the news that Apple should be forced to allow other app stores and then searched and found this announcement. I just assumed "other app store" would mean independent things like F-Droid. This is not the case?

Regulatory solution

khim — Fri, 28 Jun 2024 09:22:50 +0000

Are you even sure that something that lets you download apps from Apple and then without the ability to automatically upgrade them deserves the name third-party app store?

I don't think anything but what China or Russia do would work. The goal should be not an attempt to make Apple adjust it's policy, this would just lead to endless cat-and-mouse games, the goal is to ensure it's not used by anyone who works for government, it's not allowed to be sold officially, etc.

The fact that it was even allowed to exist in it's current form is clear failure of government regulators to catch the problem on time, but it's not too late to fix it.

Alex's approach

NYKevin — Fri, 28 Jun 2024 09:04:30 +0000

That is not what will realistically happen. What will happen is that everyone who wants to run Python on iOS will get a rejection the first time, Google it, discover the problem, write and carry their own patch, and submit a modified application without this string.

Or CPython can fix it once and we can all move on with our lives. IMHO the easiest solution is to just drop the string from urllib altogether - it's there to support Apple devices in the first place. Apple doesn't want it there? Fine, it's gone. Good riddance.

Good temporary solution

sunshinerag — Fri, 28 Jun 2024 06:10:30 +0000

I don't see anything nefarious in Apple's rejection here. The motive is simply to prevent apps launching other apps which can be abused by apps.
Apple periodically adds constraints like these to App Store submissions based on app behaviour and user frustrations. The gates are there for a reason. It is a little crude to check for a string in the binary to enforce this but the alternative would be to test the app behaviour in all possible permutations to see if it does something like that.

Also itms-services is a very apple specific scheme and as the discussion indicates it's a good question of why it is hardcoded in a generic library. The current solution looks temporary which is fine, the long term option would be to make the schemes available configurable which is also discussed.

Regulatory solution

donald.buczek — Fri, 28 Jun 2024 05:43:38 +0000

Looks like EU delivered.

https://www.engadget.com/ios-174-is-here-enabling-third-p...

"Apple has rolled out its latest major iOS update, and there are some enormous changes for those in the European Union. With the arrival of iOS 17.4, the company is adhering to strict new rules in the bloc when it comes to the App Store. Apple now officially supports third-party app stores on iPhones in the EU, while developers can offer third-party payment options. Web browser makers no longer need to base their apps on Apple's WebKit, while Apple is opening up the NFC chip to wireless payments that have nothing to do with Apple Pay."

Regulatory solution

dskoll — Fri, 28 Jun 2024 02:20:23 +0000

This is a great idea. I'd also like to see a mandate that the initial review process has to be completely transparent and any rejected app must come with a complete list of rules it broke as well as how the app can be remediated.

Regulatory solution

skissane — Thu, 27 Jun 2024 23:59:54 +0000

I really hope that some regulator in some country mandates an independent third party appellate process for app store decisions. That way Apple can be forced to defend this kind of nonsense publicly, and get ordered by the appeal to stop it. If some minor county did it, Apple might just try to pull out of that country; if a major economy such as the EU did it, they’d have no real choice but to comply. For the EU, it could be a complementary move to their mandating support for third party app stores under the DMA, taking into account the reality that having to install a third party app store is likely too much friction for many users.

Alternatively

Heretic_Blacksheep — Thu, 27 Jun 2024 23:43:03 +0000

I don't really see this as a problem. iOS is locked down and people know it. They also know that Apple's application of its policies are... arbitrary. Their policies are designed to protect their bottom line, not their customers. Appealing to the security of their customers is the PR smoke screen designed to mask their anti-competitive policies and practices. They use targeted advertising just like everyone else. People get up in arms about these practices with Microsoft, Google, etc, but hardly a peep when Apple does the same thing behind the mask of respectability. It's because Apple is really really good about smoke and mirrors while ignoring everyone that points out the Emperor has no clothes -- and their customers reward them for it.

Refusing to put up with App Store policies won't reduce Python in the Apple space. Most people that use Python are going to be using it on Macs, not iDevices. It's trivial to install Python on Macs without the App Store.

I'm a Mac and iDevice user. I'm not throwing stones without knowing something about the ecosystem from the end user's point of view. I know and understand the limitations of using Apple devices. Should such a point come where Macs are as locked down as iOS where I can't install and run code I want to run, it'll be the end of me using both. I'm saying that sometimes people need to say "Enough is enough!" Even to a trillion dollar company that may not care.

Costs vs Benefits

pavon — Thu, 27 Jun 2024 20:26:40 +0000

The cost was negligible, until Apple decided to make it more expensive by requiring different behavior and thus different builds depending on how the user installed the app.

Alex's approach

mb — Thu, 27 Jun 2024 20:15:30 +0000

Sure. Many Projects tend to put workarounds everywhere instead of really fixing things.
Happy whack a mole.

Users must complain to Apple. They broke Python.

Alex's approach

pbonzini — Thu, 27 Jun 2024 19:55:32 +0000

Reality is that it's Python's users' problem, and projects have a tendency to listen to their users' problems, and do something about them.

Alex's approach

mb — Thu, 27 Jun 2024 19:04:08 +0000

It's their decision. No (apps with) Python for Apple users then. I don't see why this is Python's problem.

Alex's approach

pizza — Thu, 27 Jun 2024 18:59:44 +0000

> Apple *clearly* caused the breakage. That's why they should care.

Why would Apple care about squishing an ant as they walk?

Alex's approach

mb — Thu, 27 Jun 2024 18:14:31 +0000

>The question is, why would Apple have any incentive to fix it?

I don't know.
Apple *clearly* caused the breakage. That's why they should care.

If they now decide to *voluntarily* drop Python support from the App store, it is their decision and we should respect that.

If they care about Python on their platform, they can add an exception to their obviously completely broken checker.

>So the odds are completely stacked against the app developers

That's the case anyway.

The Apple platform is fully proprietary and Apple decides everything anyway.
And developers and users already agree to that. That's the deal.

Apple broke it

mb — Thu, 27 Jun 2024 17:38:00 +0000

Apple broke it, Apple ought to fix it.
It's that simple.

Alternatively

elw — Thu, 27 Jun 2024 16:40:46 +0000

> How about if we stop playing Apple's games and not support their platform until they become reasonable and transparent?

The problem I see with that position is that Python is not the only easy to use language for app development. The only thing that would be accomplished by standing firm and refusing to play their game would be a reduction in usage in the platform. Unless there is some Killer App ™️, written in Python, that would cause tangible damage to the overall Apple ecosystem, Apple holds all the cards and they know it.

Costs vs Benefits

nickodell — Thu, 27 Jun 2024 16:35:30 +0000

I think that when asking whether to remove it, we should ask what the cost of the feature is. If you look at the PR which adds this support, excluding tests, it is added in one line of code. (https://github.com/python/cpython/pull/104312) This seems like pretty minimal maintenance burden.

Alternatively

notriddle — Thu, 27 Jun 2024 16:28:25 +0000

> This is a general purpose URL parser.

Other general-purpose URL parsers don't special-case this scheme. Both URL specs have support for schemes that are unknown to the parser, and neither https://url.spec.whatwg.org/#special-scheme nor https://datatracker.ietf.org/doc/html/rfc1738#section-3 includes itms-services in their lists.

Alex's approach

pbonzini — Thu, 27 Jun 2024 16:20:48 +0000

> Without making it clear that this stops working in (say) 12 months, there is *no* incentive for Apple to fix it, for Apple's developers to care that it's a problem, for anybody to do anything except dump on the Python maintainers whatever they can't be bothered to fix. They're making their own lives worse.

The question is, why would Apple have any incentive to fix it? In the middlebox case, the makers get money and have support contracts with whoever buys their products. In Apple case, app developers have no alternatives than Apple if they want their app to run on iPhone/iPad, and Apple gets money from users, not from app developers.

So the odds are completely stacked against the app developers, and if Python tried to put any deadline on the workarounds, the only effect would be to place them between the hammer (Python) and the anvil (Apple).

Alex's approach

tialaramex — Thu, 27 Jun 2024 16:06:02 +0000

The choice to time-limit workarounds allows you to properly frame the problem when it inevitably arises.

For example TLS 1.3 as designed has Downgrade prevention, if you try to *pretend* by meddling with the TCP data that somebody else's server doesn't know TLS 1.3, then either you tip off the server that you're interfering or you tip off the client, or both. There is no way to get to a scenario where the client thought it asked "Do you speak TLS 1.3?" but the server thought the client asked only "Do you speak TLS 1.2?" without the session being torn down.

But, of course idiot middleboxes broke this. Because they don't implement TLS properly, they'd hide the client's real question about TLS 1.3 from the server, but they'd pass through its answer to the question they did ask, thus exactly performing a downgrade, which sets off the downgrade prevention, your browser just closes the session. This was discovered after TLS 1.3 shipped, because Downgrade prevention obviously can't be enabled pre-standard, that's a DOS against yourself in the standards development process.

So, Google shipped builds of Chrome with a hack, _if_ you turned on the hack and _if_ the server says "I'm a TLS 1.3 server but you claimed not to know TLS 1.3 so that's fine, unless you were downgraded" this Chrome ignores the problem. Temporarily. This damages your security, but you're using a middle box, you already don't have any security, that's what you paid money for, to destroy your security.

Google told the affected vendors that their customers could enable this hack (in their installed Chrome builds) and *crucially* it told them that in a fixed period of time this hack would just be summarily deleted from Chrome. They were not going to reify this nonsense as part of the protocol design, it was a temporary hack to get some people working while these companies fixed their shit.

And they did it. Years ago now Chrome just deleted the hack. If your middle box vendor didn't fix their bug in a reasonable timeframe, or you couldn't be bothered to install their fix - now Chrome doesn't work, too bad. Everybody gets reliable TLS 1.3

Without making it clear that this stops working in (say) 12 months, there is *no* incentive for Apple to fix it, for Apple's developers to care that it's a problem, for anybody to do anything except dump on the Python maintainers whatever they can't be bothered to fix. They're making their own lives worse.

If they set a specific deadline and stick to it, it's clear what the problem is, that doesn't mean Apple will care, but too bad, you offload the problem onto exactly the people who wanted it, Apple developers, people who are used to and have accepted that they have an unhealthy masochistic relationship to an unfeeling corporation. There is no reason why anybody involved in Python who doesn't share that weird relationship should be inconvenienced.

Alternatively

flussence — Thu, 27 Jun 2024 15:45:19 +0000

This is a general purpose URL parser. Saying it should not recognise an URL pattern used by a malevolent actor is like saying tzdata should delete timezones only used in "bad" countries.

Anyway there's a really simple workaround for this. Simply ship the source file in EBCDIC. The type of whiteboard-interview weenies who come up with and enforce these restrictions will not be smart enough to figure that one out.

Alternatively

khim — Thu, 27 Jun 2024 14:55:34 +0000

While pretty interesting, I think that's the question for another time.

There are absolutely no need to have string itms-services in your app if you don't support said services.

And both “we want to support Apple” and “we don't support Apple” stances lead to the same outcome: removal of these from the standard library.

Now, if you want to both support non-developers who want to use these proprietary services and also developers who get rejection notices because of them then you are in bind, but I think simple and straightforward removal is the best outcome: remove the support, leave these for guys who actually want to use these services from Python to resolve, somehow. They decided to deal with unreasonable company, they can deal with the fallout.

If would be time to decide when Apple would bad something because it supports some other free service.