Python grapples with Apple App Store rejections

By Joe Brockmeier
June 27, 2024

An upgrade from Python 3.11 to 3.12 has led to the rejection of some Python apps by Apple's app stores. That led to Eric Froemling submitting a bug report against CPython. That, in turn, led to an interesting discussion among Python developers about how far the project was willing to go to accommodate app store review processes. Developers reached a quick consensus, and a solution that may arrive as soon as Python 3.13.

The problem at hand is that Apple's macOS App Store is automatically rejecting apps that contain the string "itms-services". That is the URL scheme for apps that want to ask Apple's iTunes Store to install another app. Software distributed via Apple's macOS store is sandboxed, and sandboxed apps are prohibited from using URLs with the itms-services scheme. That string is in the urllib parser in Python's standard library, though an application may never actually use the itms-services handler.

Of course, Apple did not do anything so straightforward as to explain this to Froemling. Once he filed an appeal with Apple about the rejection, Apple finally told him that parse.py and parse.pyc were the offending files. After that, he said, it was not hard to track down the problem:

Now in retrospect I'm frustrated I didn't think to run a full text search for itms-services over Python itself earlier or stumble across one of the other cases of folks hitting this.

Russell Keith-Magee started the discussion in the Python Core Development discussion forum on June 17. He wanted to know whether "acceptable to app stores" should be a design goal for CPython, or if that compliance should be a problem left to the tools that generate application bundles for app stores.

Paranoid and inscrutable

Keith-Magee noted in his initial question that Apple's review processes were the most "paranoid and inscrutable" of app-store-review processes, but that other app stores also had "validation and acceptance processes that are entirely opaque". One solution might be to obfuscate the offending string to pass review, but that might "lead to an obfuscation arms race" and there were no guarantees this would be the last time the project had to resolve app-validation problems. The other option, he said, was to consider this to be a distribution problem and leave it to tools like Briefcase, py2app, and buildozer to solve. Traditionally, they have had to patch CPython anyway, he said, because it did not support Android or iOS "out of the box". But that will change with Python 3.13 when no patching should be required for those platforms.

Alex Gaynor suggested that the project try an approach that Keith-Magee had not put forward inspired by Gaynor's experience with the cryptography library. The project often receives complaints that the library refuses to parse a certificate that is technically invalid, but was in wide use. He said that the policy was to accept pull requests that work around those issues "provided they are small, localized, and generally aren't too awful". But, he added, these patches should only be accepted on the condition that someone complains to the third party (in this case Apple), and extracts some kind of commitment that they would do something about it. He suggested that the workaround be time-limited, to give users a decent experience "while also not letting large firms simply externalize their bizarre issues onto OSS projects".

Brandt Bucher wondered whether obfuscation was even allowed, or if it would be seen as circumventing the review process. That was a question no one seemed to have an answer to; and Keith-Magee responded with an 8-Ball emoji and the phrase "ask again later." He added that Gaynor's approach sounded appealing, but it would be like screaming into the void. Apple, he said, barely has an appeals process and there is no channel available to the Python project "to raise a complaint that we could reasonably believe would result in a change of policy".

Another approach, suggested by Alyssa Coghlan, would be to use a JSON configuration file that urllib would read to set up its module level attributes "rather than hardcoding its knowledge of all the relevant schemes". That could allow app generators to drop "itms-services" from the configuration file rather than patching urllib.py directly. Keith-Magee said that could work, but "it strikes me as a bit of overkill for an edge case" that could be handled by obfuscation or distribution-level patching.

On June 20, Keith-Magee wrote that he had thought of another approach: adding a build-time option called "--with-app-store-patch" that removes code that is known to be problematic. He said it would be enabled by default for the iOS platform, and disabled elsewhere. It could be used when building an application for macOS, if the developer intended to distribute that application via the macOS App Store. He suggested that the option could also accept a path to a file with a patch, to allow distributors to provide an updated patch if an app store changes its rules after the maintenance window for a Python release has closed.

Let's paint the bikeshed

Coghlan asked if it was now time to "paint a config option bikeshed". She said that the proposed option name was both too broad and too narrow. The "app-store" component of the name was too broad, because it could encompass any app store, not only Apple app stores. The "patch" component was too narrow, because patch specifies the method of complying with policies rather than intent. There may be other methods required to comply with app-store-compliance checks. Keith-Magee liked the suggestion about dropping "patch" from the option name, and suggested painting the bikeshed a nice shade of "--with-app-store-compliance" that would interact with platform identification to sort out what is required.

On June 25, Keith-Magee thanked participants in the discussion for their input, and pointed to a pull request that would implement the --with-app-store-compliance configuration option. In the request, he noted that it would be possible to use the option with platforms other than iOS or macOS, but there were no use cases for that at present. If all goes well, it should be available in Python 3.13.

It is frustrating that free-software projects like Python have to waste time finding ways around opaque review processes just so developers can write software for non-free platforms. However, the approach taken by Keith-Magee and other CPython developers seems to be the least-bad option that offers the best experience for Python application developers. It will almost certainly not be the last time that a project runs into this problem.

Alternatively

Posted Jun 27, 2024 14:06 UTC (Thu) by dskoll (subscriber, #1630) [Link] (8 responses)

I understand the desire of free software advocates to have our software run everywhere, but at some point maybe we shouldn't continue enabling these kinds of shenanigans?

Every piece of application software that runs on Apple's ecosystem makes it a bit more valuable. How about if we stop playing Apple's games and not support their platform until they become reasonable and transparent? Every software project that did that would make Apple's ecosystem a bit less valuable and eventually this would be noticed.

Alternatively

Posted Jun 27, 2024 14:45 UTC (Thu) by shironeko (subscriber, #159952) [Link] (1 responses)

What ends up happens is that people start shipping slightly different workarounds in downstream. The amount of apple software would not decrease, it just gets more frustrating to use free software on it.

Alternatively

Posted Jun 28, 2024 13:15 UTC (Fri) by dskoll (subscriber, #1630) [Link]

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.

Alternatively

Posted Jun 27, 2024 14:55 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

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.

Alternatively

Posted Jun 27, 2024 15:45 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

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

Posted Jun 27, 2024 16:28 UTC (Thu) by notriddle (subscriber, #130608) [Link]

> 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.

Alternatively

Posted Jun 27, 2024 16:40 UTC (Thu) by elw (subscriber, #86388) [Link] (1 responses)

> 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.

Alternatively

Posted Jun 27, 2024 23:43 UTC (Thu) by Heretic_Blacksheep (guest, #169992) [Link]

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.

Alternatively

Posted Jul 4, 2024 10:52 UTC (Thu) by norphonic (guest, #93563) [Link]

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.

Strip the functionality altogether.

Posted Jun 27, 2024 14:45 UTC (Thu) by pavon (guest, #142617) [Link] (3 responses)

I'd question whether something like itms-services scheme support really belongs in a standard library to begin with. That is a pretty niche functionality for a single operating system. Most python software running on macOS will never use it, just things like installers. There isn't equivalent support for the dozens of Windows-specific schemes that Microsoft uses.

Obviously, you'd need to give time to deprecate it, so another work-around would be needed for the short-term, but in the long-run if Apple wants to make it hard to integrate with their platform, then stop supporting those integrations and let application developers use a third-party library.

Costs vs Benefits

Posted Jun 27, 2024 16:35 UTC (Thu) by nickodell (subscriber, #125165) [Link] (1 responses)

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.

Costs vs Benefits

Posted Jun 27, 2024 20:26 UTC (Thu) by pavon (guest, #142617) [Link]

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.

Strip the functionality altogether.

Posted Jun 28, 2024 15:21 UTC (Fri) by smurf (subscriber, #17840) [Link]

> 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.

Alex's approach

Posted Jun 27, 2024 16:06 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (9 responses)

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.

Alex's approach

Posted Jun 27, 2024 16:20 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (8 responses)

> 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

Posted Jun 27, 2024 18:14 UTC (Thu) by mb (subscriber, #50428) [Link] (7 responses)

>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.

Alex's approach

Posted Jun 27, 2024 18:59 UTC (Thu) by pizza (subscriber, #46) [Link] (6 responses)

> 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

Posted Jun 27, 2024 19:04 UTC (Thu) by mb (subscriber, #50428) [Link] (5 responses)

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

Posted Jun 27, 2024 19:55 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (4 responses)

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

Posted Jun 27, 2024 20:15 UTC (Thu) by mb (subscriber, #50428) [Link] (3 responses)

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

Posted Jun 28, 2024 9:04 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (2 responses)

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.

Alex's approach

Posted Jun 28, 2024 15:43 UTC (Fri) by mb (subscriber, #50428) [Link] (1 responses)

>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?

Alex's approach

Posted Jun 28, 2024 18:53 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

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.

Apple broke it

Posted Jun 27, 2024 17:38 UTC (Thu) by mb (subscriber, #50428) [Link]

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

Regulatory solution

Posted Jun 27, 2024 23:59 UTC (Thu) by skissane (subscriber, #38675) [Link] (12 responses)

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.

Regulatory solution

Posted Jun 28, 2024 2:20 UTC (Fri) by dskoll (subscriber, #1630) [Link]

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

Posted Jun 28, 2024 5:43 UTC (Fri) by donald.buczek (subscriber, #112892) [Link] (10 responses)

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

Posted Jun 28, 2024 9:22 UTC (Fri) by khim (subscriber, #9252) [Link] (9 responses)

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.

Regulatory solution

Posted Jun 28, 2024 9:40 UTC (Fri) by donald.buczek (subscriber, #112892) [Link] (8 responses)

> 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

Posted Jun 28, 2024 12:15 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

> 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.

Regulatory solution

Posted Jun 28, 2024 12:50 UTC (Fri) by donald.buczek (subscriber, #112892) [Link] (6 responses)

You're right, that's disgusting.

Regulatory solution

Posted Jun 28, 2024 13:24 UTC (Fri) by Wol (subscriber, #4433) [Link] (5 responses)

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

Regulatory solution

Posted Jun 28, 2024 13:56 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

> 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

Posted Jun 28, 2024 17:01 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> 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

Regulatory solution

Posted Jun 28, 2024 17:26 UTC (Fri) by khim (subscriber, #9252) [Link]

> 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

Posted Jun 28, 2024 17:34 UTC (Fri) by zdzichu (subscriber, #17118) [Link]

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

Time to stop

Posted Jun 28, 2024 18:39 UTC (Fri) by jzb (editor, #7867) [Link]

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.

Good temporary solution

Posted Jun 28, 2024 6:10 UTC (Fri) by sunshinerag (guest, #172199) [Link] (5 responses)

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.

Good temporary solution

Posted Jun 28, 2024 9:48 UTC (Fri) by taladar (subscriber, #68407) [Link]

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.

Good temporary solution

Posted Jun 28, 2024 15:17 UTC (Fri) by smurf (subscriber, #17840) [Link] (3 responses)

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.

Good temporary solution

Posted Jun 29, 2024 1:13 UTC (Sat) by edeloget (subscriber, #88392) [Link] (2 responses)

> 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.

Good temporary solution

Posted Jul 4, 2024 14:36 UTC (Thu) by hkario (subscriber, #94864) [Link] (1 responses)

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.

Good temporary solution

Posted Jul 4, 2024 19:59 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> 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.