The Web App Switcheroo

It’s unusual that Apple seems to have used the Digital Markets Act, a regulation intended to get it to be a better commercial citizen, to show how terrible it can be when it doesn’t get its way.

Apple gave the EU a bunch of new, regional-body-mandated features in a region-locked way. But it also took something away—the ability to run web applications in a way native to the iPhone. For those familiar with your Apple history, you probably know that Apple tried to sell developers on web apps being good enough upon the iPhone’s initial launch, only to learn the hard way that, hey, perhaps this wasn’t the path forward for this new platform.

It set the stage for the current conflict, but it’s also long been in the background, a signifier of how Apple might act if it couldn’t control a part of its ecosystem. Sure, web apps work in the modern day, they’ve long been an element of the Safari web browser, but Apple has often been feet-draggy on some of the more innovative features of HTML, CSS, and JavaScript in its browser, lowering the quality of the experience of web apps in ways that make them second-class citizens on this insanely popular smartphone.

Now, Apple is making web apps—which are running at this point on devices so fast that there is no reason that 90% of apps couldn’t just be coded as web pages—a scapegoat for its distaste for this law it doesn’t like. As the company stated on a developer site:

To comply with the Digital Markets Act, Apple has done an enormous amount of engineering work to add new functionality and capabilities for developers and users in the European Union—including more than 600 new APIs and a wide range of developer tools.

The iOS system has traditionally provided support for Home Screen web apps by building directly on WebKit and its security architecture. That integration means Home Screen web apps are managed to with the security and privacy model for native apps on iOS, including isolation of storage and enforcement of system prompts to access privacy impacting capabilities on a per-site basis.

Without this type of isolation and enforcement, malicious web apps could read data from other web apps and recapture their permissions to gain access to a user’s camera, microphone or location without a user’s consent. Browsers also could install web apps on the system without a user’s awareness and consent. Addressing the complex security and privacy concerns associated with web apps using alternative browser engines would require building an entirely new integration architecture that does not currently exist in iOS and was not practical to undertake given the other demands of the DMA and the very low user adoption of Home Screen web apps. And so, to comply with the DMA’s requirements, we had to remove the Home Screen web apps feature in the EU.

EU users will be able to continue accessing websites directly from their Home Screen through a bookmark with minimal impact to their functionality. We expect this change to affect a small number of users. Still, we regret any impact this change—that was made as part of the work to comply with the DMA—may have on developers of Home Screen web apps and our users.

For those who didn’t catch that, let me translate that for you: Apple is stating that it will no longer let its users take advantage of web apps from the home screen, at all, because it doesn’t control the access that alternative web browsers have with that experience.

Le sigh.

In one sense, yes, Safari is a common vector for jailbreaks and similar attacks, and the decision to protect users seems on its face to be admirable. But on the other hand, it feels like Apple doing what it has long done in situations like these—it has cloaked a decision that conveniently protects its market position in the language of safety.

It’s one thing when Apple does it to convince you that upgrading your own SSD is somehow a security risk. It’s another when it feels like a tactic that also conveniently forces competing browsers, many of which have better support for HTML features that Safari has infamously gone out of its way to not support, to join the ecosystem with one hand tied behind their back. It’s a convenient place to pinpoint a security problem, and it is not the first time the company has done something like this.

You could argue this the other way, I’m sure—one look at how Microsoft started digging into Chrome’s open tabs feels like a good argument in Apple’s favor. But context is important here, and Apple is making this move at a time when it’s losing a lot of ground. It feels like this is a small way it makes some up.

Currently, a major internet regulation is likely to pass the Senate, one that many have found to be particularly troublesome and problematic. But one reason it looks likely to pass and may even land on Biden’s desk comes down to the name of the proposed law: The Kids Online Safety Act.

Legislators have figured out that if you put “kids” and “safety” together in the name of a law, any law, it raises its chance of passage, because who wants to be the monster who didn’t vote for the kid’s safety bill come election time? This has been used to excellent effect in many U.S. states that have started to require people to share their IDs to access adult content. These state-level laws often refer safety or kids in their names, but in effect force the vast majority of Americans to share their personal information to access content they are legally allowed to access.

To me, when Apple cites privacy and safety reasons as a reason for limiting what you can do with the products you own, it is doing the exact same thing—it is using the language of protection to limit your rights. Language is a powerful weapon in these contexts, and Apple is one of the best at it.

Apple can be a great company at security, and it can do so without being so ruthlessly competitive and protective of its financial position. It needs to stop pretending that one can be true without the other.