> The issue is that, now, third-party companies can force you install their store to download their app

And they will have a vastly reduced set of people willing to use their software as a result. Other than a few key things, that's probably more trouble than it's worth for a lot of people, and the requisite "Warning: This app store is handled by someone else to make absolutely sure you trust the company running it" will scare a bunch more off, if it's something new.

If, on the other hand, it's Steam, or Epic, or some other super well known steward of content that has a well known name and reputation, then maybe if users are also lured by lower prices, they might consider it.

You know, exactly the same way you might feel a lot more comfortable buying that watch or toy you really want if it's from your local target and not some random guy with a table on the street.

If Epic/Tencent forces iOS users to use their app store to play Fortnite, there will be no luring of users based on lower prices.

They will just (effectively) all move over and (effectively) none of them will read any warning text.

God only knows what companies like 100% Tencent owned Riot Games will have running on millions of Americans' phones once they get the elevated access an app store requires.

All of this is a failing of the OS layer which should manage permissions not stores.

Exactly. There shouldn't be a private API to get your phone number. There should be a public API, and calling it should request permission from the user.

Of course, the app can refuse to function if you deny it...

But I wouldn’t want the settings app for example to pop up a bunch of dialogs asking for permission to enable various private APIs.

Exactly. Come in HN. You’re smart. If you give the average user numerous pop up boxes to click they’re going to be conditioned to click allow no matter what the permission is to get where they need to go. It is not an answer and counter productive.

Sure, there's a fine line between users actually reading the prompt and making a real choice vs. just tapping "allow" to get it to go away.

I feel like "do you want to give this app your phone number?" falls under the former, though. Right there along with "do you want to give this app your location?", which is of course already something users have to allow.

When you rely on a gatekeeper for security, it results in problems like the Play Store being the main vector for malware distribution on Android[1], and Apple's App Store distributing 500 million copies of Xcodeghost to users' devices[2].

[1] https://www.zdnet.com/article/play-store-identified-as-main-...

[2] https://www.vice.com/en/article/n7bbmz/the-fortnite-trial-is...

Xcodeghost was just another analytics API to Apple, so they didn't care until they were alerted that it was added to apps without the consent of these developers. It was not 'malware' in the sense of enrolling users in a botnet or utilizing private APIs to record the screen without permission.

Lookout Security describes it as malware[2] and as malicious, as does Palo Alto Networks[3], Ars[4], Reuters[5] and The NY Times[6].

From here[1]:

> Remote control security risks

> XcodeGhost can be remotely controlled via commands sent by an attacker from a Command and control server through HTTP. This data is encrypted using the DES algorithm in ECB mode. Not only is this encryption mode known to be weak, the encryption keys can also be found using reverse engineering. An attacker could perform a man in the middle attack and transmit fake HTTP traffic to the device (to open a dialog box or open specific app for example).

> Read and write from clipboard

> XcodeGhost is also able, each time an infected app is launched, to store the data written in the iOS clipboard. The malware is also able to modify this data. This can be particularly dangerous if the user uses a password management app.

> Hijack opening specific URLs

> XcodeGhost is also able to open specific URLs when the infected app is launched. Since Apple iOS and OS X work with Inter-App Communication URL mechanism (e.g. 'whatsapp://', 'Facebook://', 'iTunes://'), the attacker can open any apps installed on the compromised phone or computer, in the case of an infected macOS application. Such mechanism could be harmful with password management apps or even on phishing websites.

> Stealing user device information

> When the infected app is launched, either by using an iPhone or the simulator inside Xcode, XcodeGhost will automatically collect device information.*

> Then the malware will encrypt those data and send it to a command and control server. The server differs from version to version of XcodeGhost; Palo Alto Networks was able to find three server URLs:

> http://init.crash-analytics.com, http://init.icloud-diagnostics.com, http://init.icloud-analysis.com

> The last domain was also used in the iOS malware KeyRaider.

[1] https://en.wikipedia.org/wiki/XcodeGhost#Behavior_on_infecte...

[2] https://blog.lookout.com/blog/2015/09/20/xcodeghost

[3] http://researchcenter.paloaltonetworks.com/2015/09/malware-x...

[4] https://arstechnica.com/information-technology/2015/09/apple...

[5] http://www.reuters.com/article/2015/09/20/us-apple-china-mal...

[6] http://www.nytimes.com/2015/09/21/business/apple-confirms-di...

My point is that these are all things which analytics apis (which, mind you, are also arguably malware) at the time did as well - reading the clipboard was common as many operated their own internal clipboard proxy due to the slowness of pasting in older iOS versions. It's only called malware and not Facebook because it was injected into developers' apps without their knowledge.

And the 'remotely controlled via commands' section is meaningless - apps can't JIT so such C&C was simply turning flags on-and-off to go on different code paths.

Excellent examples!

The OS layer can be compromised - all recent iOS jailbreaks besides ones that rely on checkm8 use a series of userland exploits to break out of the sandbox and gain rootfs access. Nothing is stopping a seemingly innocuous App Store from installing an app that silently jailbreaks the phone in the background to then bypass the OS whitelists that gatekeep these private APIs to Apple-provided apps.

Also slots nicely under the "failure of an OS" category.

Legislation like this forces Apple to actually maintain a good OS lest it be riddled with malware. They seem to be doing fine on macOS they can do the same for iOS.

Craig Federighi said it himself that the level of malware on MacOS is unacceptable[0]. It's impossible to make a completely secure OS that never has bugs - it's less impossible to create a review system with rules and processes that limits the amount of user-downloaded malware to single-digit numbers.

0: https://www.cnbc.com/2021/05/19/apples-head-of-software-says...

Craig Federighi is a very powerful executive doing everything in his power to protect his company's business model. That includes lying as he did in that court. Craig uses a Mac everyday he's fine with it's security.

I'm sure his MDM-enforced gatekeeper setting is on "Apps downloaded from the App Store" and not in the default position that includes "and identified developers".

https://support.apple.com/guide/mdm/security-privacy-payload...