Annotating Apple’s Anti-Sideloading White Paper

Wednesday, 23 June 2021

Apple today released a white paper arguing against proposed legislation that would mandate the ability to sideload apps (and thereby alternative app stores) on iOS/iPadOS:¹ “Building a Trusted Ecosystem for Millions of Apps”.² I think it’s good, fair, and cogent. I highly encourage you to read it — it’s not long — then come back for my annotations below.

The paper opens with this quote from Steve Jobs, announcing the iPhone SDK:³

“We’re trying to do two diametrically opposed things at once: provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc. This is no easy task.” — Steve Jobs, 2007

As ever, Steve Jobs was a succinct and forceful communicator. That “diametrically opposed” tension he described at the outset, 14 years ago, remains exactly the core of Apple’s argument in this paper today.

Page 4, under a section subtitled “This approach to security and privacy has been highly effective”:

Additionally, even users who prefer to only download apps from the App Store could be forced to download an app they need for work or for school from third-party stores if it is not made available on the App Store. Or they could be tricked into downloading apps from third-party app stores masquerading as the App Store.

This, to me, is perhaps the key point that sideloading proponents ignore. Arguments in favor of allowing sideloading on iOS, from users, tend to boil down to “It’s my device, I should be allowed to install whatever I want. If most users want to stick with the App Store, that’s fine for them and they’ll keep all the benefits as they currently stand, while I and others will have the freedom to install whatever we want.” That argument is not wrong! There would be benefits to allowing sideloading, exactly along the lines of how there are benefits to being able to install apps outside the App Store via TestFlight, enterprise distribution, and compiling apps from source code with Xcode.

Sideloading would take things to a new level though. TestFlight still requires some approval from Apple, and TestFlight distribution is limited to 10,000 users. Enterprise distribution requires an enterprise certificate from Apple. And compiling from source code requires a developer account, significant technical expertise, and, well, the source code to the app.

What the sideloading arguments ignore are the enormous tradeoffs involved. Yes, there would be benefits — a lot of cool apps that aren’t permitted in the App Store would be installable by as many iOS users as want to install them. But many non-technical users would inevitably wind up installing undesirable apps via work/school requirements or trickery that they could not be required or tricked into installing today. Consider just the example of “proctoring apps” that students are required to install for remote test taking. They’re a surveillance menace, as the EFF reported in August.

Technically, yes, on platforms that allow it, sideloading is the user’s choice. But socially and psychologically, it often isn’t.⁴

Page 4:

In the end, users would have to constantly be on the lookout for scams, never knowing who or what to trust, and as a result many users would download fewer apps from fewer developers.

This is another key point that cannot be overstated. As things stand today, you cannot “mess up” your iOS device by installing the wrong software. You can easily uninstall all traces of any app you do install with a tap-and-hold on the app’s icon. No app you install can entrench invisible background agents that act like system software. And because of this, hundreds of millions of non-technical iOS users install far more software on their iOS devices than they do or did on their PCs — including Macs. This, despite the fact that PCs are far more powerful devices. Typical users install more apps on their less capable phones than they do on their far more capable PCs. This is as close as we can get to proof that Apple’s App Store model on iOS hasn’t just worked, but has proven to be wildly successful and popular with users.

Related point: An app’s ability to even request access to health data, or contacts, or to create a VPN, rests on App Store review. If an app says it’s a game but requests the entitlement to prompt the user for access to health data, Apple’s App Store review will reject it. An Epic-run App Store would be making parallel and different decisions about which entitlements to grant to which apps. A sideloaded app would make those decisions for itself. Surveillance tracking would go back to “whatever the app wants to do”.

Page 9:

iPhone is used every day by over a billion people — for banking, to manage health data, and to take pictures of their families. This large user base would make an appealing and lucrative target for cybercriminals and scammers, and allowing sideloading would spur a flood of new investment into attacks on iPhone, well beyond the scale of attacks on other platforms like Mac.

Here Apple dances around the elephant in the room — the question of why iOS shouldn’t just work like the Mac with regard to non-App Store software. Apple’s deft argument is that there are far fewer Macs than iOS devices, making the Mac a less enticing target for scammers and crooks (including privacy crooks). That’s more or less the argument Windows proponents used to explain the profound prevalence of malware on Windows compared to the Mac back in the day, whilst Apple (and Mac proponents) argued otherwise, that the Mac actually was far more secure at a technical level.

But the truth Apple won’t come out and say is that it’s both. The Mac was more secure by design, but also a far less enticing target because of how many more users were (and still are) on Windows. And, today, iOS is more secure and private than the Mac. That’s the nature of the Mac as a full PC platform.

I’ll admit it: if Mac-style sideloading were added to iOS, I’d enable it, for the same reason I enable installing apps from outside the App Store on my Mac: I trust myself to only install trustworthy software. But it doesn’t make me a hypocrite to say that I think it would be worse for the platform as a whole.⁵

The Mac is fundamentally designed for users who are at least somewhat technically savvy, but tries its best to keep non-savvy users from doing things they shouldn’t. But you can always hurt yourself, sometimes badly, with any true power tool. The iPhone is the converse: designed first and foremost for the non-savvy user, and tries to accommodate power users as best it can within the limits of that primary directive.

Page 11:

The goal of App Review is to ensure that apps on the App Store are trustworthy and that the information provided on an app’s App Store page accurately represents how the app works and what data it will access. We are constantly improving this process: we update and refine our tools and our methodology continuously.

The problem Apple is facing today is that it’s clear that one word in the above is inaccurate: the opening “the”. The above is a goal of the App Store — and I would argue that it remains the primary goal. But clearly the App Store serves another goal for Apple: making the company money. Exhibit A: last year’s Hey fiasco. Nothing about Apple’s rejection of Hey (or, I’d wager, some number of thousands of other apps flagged by App Store review for similar reasons) was about trustworthiness. It was about money.

That’s a conflict of interest, and it detracts significantly from Apple’s entirely legitimate trustworthiness argument defending the App Store model for distribution. I remain convinced Apple wouldn’t be facing these regulatory pressures today if they’d walked away from a strategy of maximizing App Store profits years ago, and I also think they could largely dissipate these pressures today by doing it now — better late than never.

Also on page 11:

Once users download an app through the App Store, they are able to control how that app functions and what data it is able to access, using features such as App Tracking Transparency and permissions. Parents can further control what their kids buy with the Ask to Buy feature, how much time they spend on certain categories of apps with Screen Time features, and what data they share. Users are also able to centrally manage all app-related payments, and are able to easily view and cancel subscriptions that are paid for via In-App Payments. These controls could not be fully enforced on sideloaded apps.

All of this is true. But that last point, that all in-app subscriptions are listed in an obvious location, where it’s easy to unsubscribe, and you get email notifications before every renewal, is the singular reason why I think Apple should not — and should not be forced to — allow in-app purchases and especially subscriptions via developers’ own payment systems. What I endorse is allowing apps to direct users to the web to make purchases and subscriptions. In-app purchases vs. out-app purchases. Let Apple earn its cut by showing that in-app purchases have higher conversions.

My favorite example is The New York Times — by all accounts a reputable and trustworthy company. Subscribe to the Times in-app, where Apple gets a cut, and you can easily unsubscribe at any time with two taps in the Settings apps. Subscribe to the Times on their website, and you literally have to call them on the telephone and argue with a Times rep whose job is to talk you out of unsubscribing.

The current in-app purchase requirements are incredibly reassuring to me, as a user. I subscribe to many publications and services through in-app purchase that I would not subscribe to otherwise. Let apps offer the ability to use their own purchasing systems, but make it clear they’re doing so on the web, not in-app. (That’s what Hey does — and people trust Hey because they trust the company behind it.)

Page 12, in a list of statistics of App Store “protections in action in 2020”:

Apple deactivated 244 million customer accounts due to fraudulent and abusive activity, including fake reviews. It also rejected 424 million attempted account creations due to fraudulent and abusive patterns.

My reaction to these numbers: Jiminy!

Assuming these number are accurate, they explain Apple’s seeming nonchalance to the continuing existence of scam apps that do get into the App Store, and the pervasiveness of fraudulent reviews. They’re catching the overwhelming majority of them.

I still say: not good enough, especially on the task of identifying and eliminating successful scams. But, still, wow, those are big numbers.