Malicious Requirement, Non-Malicious Compliance

2025.08.03   prev     next

IN the mid-2000s, before Apple even made a phone, BlackBerry was very popular. In fact, it was the most popular mobile device out there, and it didn’t even peak until a couple years after iPhone’s debut.

BlackBerry was a very controlled, locked-down, curated product. The permission-plus-startup-cost barrier to becoming a third-party app developer was steep — then RIM controlled the price of your app, and kept 50% of the revenue. User confidence in the safety of third-party apps came mainly from RIM’s extreme selectivity of who was even allowed to develop. But there were distinct benefits to RIM’s policies: Piracy, scams, junk, and malware were virtually non-existent.

Apple, which had never before done a locked-down, curated product like that, decided that iPhone (and a few years later iPad) would be its first foray into such a controlled platform. But at the same time, it sought to tease out the things about RIM’s control that seemed overly negative, and attempt to achieve the best of both worlds: Startup cost was essentially nothing (provided you already had a Mac), and permission was universal, even to indie developers who wanted to take a crack at it. The developers controlled the price of their own apps, and Apple kept only 30% of the revenue. Us­er confidence in the safety and quality of third-party apps was maintained by a first-of-its-kind, internal team to screen every app submission.

The result was meteoric success that eventually blew BlackBerry away — although iPhone represented so many revolutionary improvements (giant touchscreen, great UI, etc.) that it’s difficult to know for sure which features were most responsible for that success. But the variety and quality of mobile apps in the App Store clearly eclipses anything that came before it, or since.

HTML Rendering

One revolutionary feature of i­Phone was its real, mobile web-browser, which, of course, necessitated an HTML rendering engine. As part of control over the platform, Apple made an early decision that there would be only one HTML renderer on iPhone and iPad. It’s built into the OS, and every app that wants to render HTML uses it. Apple alone is responsible for maintaining it, optimizing it for speed and battery efficiency, patching it when security flaws are discovered, and keeping it up-to-date with evolving web standards. No other HTML renderer is allowed on iPhone and iPad; all apps (first- and third-party) use it, if they need to do HTML rendering. That’s the way iPhone and iPad have worked for their entire existence, everywhere in the world that they are sold. That is, until just recently.

EC, DMA

A few years ago, the EC — the European Commission of the European Union — was deciding what to put into its impending DMA (“Digital Markets Act”), a big law with lots of requirements, all of them on non-EU companies.

One of the items under consideration was whether to require Apple to allow third-party HTML renderers on iPhone and iPad. The EC hosted multiple companies, and heard their arguments. Prominent among the make-Apple-do-it contingent were Google and Mozilla, which make the Chrome and Firefox browsers, respectively. Each uses its own HTML rendering engine — Blink for Chrome, and Gecko for Firefox — on various platforms, but not on iPhone and iPad, where they use Apple’s only-allowed, built-in, WebKit engine. Both companies, if I recall correctly, argued to the EC that Apple was squelching competition. Under this theory, if a company made a faster HTML renderer, it would be a better user experience, and more users would be drawn to that company’s browser (or other product).

Apple’s counterargument, one can only imagine, went something like this: We’re not telling anyone what to do on Android. Or Windows. Or Linux. Or even our own Macintosh! Or other products, like smart TVs, etc. But we’ve decided that this is the best thing for users of our iPhone and iPad products. There’s lots of competition out there, over which we have no control, but users and developers should have the choice to go with our iPhone/iPad system as we have designed it.

The EC didn’t care for that logic, and liked the anti-Apple argument, so it chose to include a requirement in the DMA that Apple must support third-party HTML engines. Of course, the law didn’t mention Apple by name. Courts take a dim view of laws that target specific companies; laws are supposed to be definitions of bad behavior, and those definitions are supposed to apply to everyone — as in, “no one is above the law.” But the DMA did somehow define this requirement in a way that it applies only to Apple. You might be thinking, oh, is that because Apple is the only company that was disallowing alternate HTML engines? No, actually, totally separate from who’s allowing it and who isn’t, the DMA manages to require just one company to allow it: Apple.

BrowserEngineKit

There was plenty of time for Apple to prepare its compliance before the DMA went into effect on May 2, 2023, and on that day — along with changes for many other DMA requirements — Apple rolled out a new feature for iOS developers, BrowserEngineKit, whereby you can create your own HTML rendering engine project, drop in your own HTML rendering code (like that found in Blink or Gecko), compile it, adjust it to work correctly and optimally on iOS, testing it in the on-screen simulator and on your own developer-controlled iPhones and iPads, and when you feel it’s ready for prime time, ask Apple to activate it. Ap­ple then looks at it, gives it the OK (in a timely manner, else risk running afoul of the DMA), then activates it so you can distribute it to ordinary, typical users of iPhones and iPads, and it will run there. There’s nothing convoluted, confusing, or flaky about BrowserEngineKit; it’s straightforward and works as advertised.

Unused

So here we are, well over two years since the DMA went into effect. How many companies are using BrowserEngineKit? Zero. That’s right: none. Not even Goo­gle and Mozilla? Not even them. After Apple went to all the trouble to create the feature, it’s been sitting unused for over two years. Why is that? Why would even the companies that clamored for it, then decide not to use it?

One seemingly plausible explanation is that the feature works only in the EU. When the EC announced the inclusion of the Ap­ple HTML engine requirement in the DMA, the companies that lobbied for it conveyed public jubilation. Then later, when Apple revealed the details of the upcoming feature, those companies expressed “extreme disappointment” that the feature would be limited to the region where it’s legally mandated. But were they really surprised? Apple doesn’t want this feature anywhere; it never did. It’s implementing the feature even in the EU only because it’s required by law to do so.

And even with the feature working only in the EU, wouldn’t Google and Mozilla want to use it anyway? The EU may be small compared to the whole world of i­Phone/iPad users, but if it’s significant enough for Apple to jump through stupid hoops just to be able to stay there, then why isn’t it significant enough for Google and Mozilla to port their already-crafted Blink and Gecko code into BrowserEngineKit, in order to address at least the EU audience? But nope, they have­n’t done it at all. Why not?

No Real Benefit

Because it would make no difference, that’s why.

When the user clicks a link, and there is a noticeable pause before the web page appears, only a portion of that delay, maybe a small minority of it, is spent rendering the HTML. A lot of it is spent just communicating with the web serv­er somewhere far away, and waiting for that potentially busy server to supply the HTML, graphics, and other elements of the page. Suppose you created an HTML rendering engine that was, overall, about 10% faster than Apple’s. (That would be an extraordinary achievement; Apple puts a lot of effort into making its renderer as fast as it can be.) Then your improvement over Apple would reduce the us­er’s wait time by 10% at the very most, but probably a lot less than that, because it would have no effect on the other causes of the delay. Would the user even notice?

And when the page appears, it would be the same: it would look the same and act the same, all as defined by the website creator’s HTML, graphics, etc. After all that effort to create your own rendering engine, the user wouldn’t see any difference at all.

That’s why Google and Mozilla don’t want to bother with Brows­er­En­gine­Kit.

Spyware

So why did those companies push the EC to make Apple do this? They’re not going to say, of course, but there’s a pretty obvious answer. They were hoping that when this law passed, Apple would just give up on controlling iOS, and let everyone install whatever they want. Or at least issue some kind of digital certificate to the companies that have their own HTML renderer, allowing them to install pretty much anything. Then Goo­gle and Mozilla (and almost certainly Meta) would install their own HTML engine alright — but it wouldn’t just render HTML; it would also report everything it does back to its maker. The browser would report every page you visit, every link you click, anything and everything, back to the company. And you can’t sue them for privacy invasion, because somewhere in that “I Agree” button you had to tap to make the app run in the first place, it contains legalese that you are consenting to being spied on. And that’s been tested in the courts; it holds up.

Apple’s position appears to be: Put whatever you want in the “I A­gree” button, and that may get you off the hook in a courtroom — but that doesn’t mean we have to let you do it. And our decision is, no, you’re not going to do that to our users. If you don’t like that, feel free to yank your product from our platform, then wait for us to change our minds. We won’t.

If you create a BrowserEngineKit project, you have to submit it to Apple for their vetting and approval. And believe me, they’re going to vet the hell out of it. If there’s anything in there besides just code to render HTML to a user-viewable web page, Apple’s going to reject it. And I wouldn’t be surprised if Apple also made publicly available exactly what they found in there, that caused them to reject it. So, of course, Google, Mozilla, Meta, et al. don’t even try to do that. Apple’s enemies like to call its strategy “malicious compliance,” but it’s really Apple finding a non-malicious way to comply with a very intentionally malicious legal requirement.

Saving Face

Wouldn’t Google and Mozilla at least submit a clean HTML renderer to Apple (for the EU), just to save face, after all that lobbying to get it passed into law? But if they did that, then everyone would soon see that it isn’t even a noticeable improvement over the way it was previously, and everyone would become acutely aware that those firms’ EC arguments were disingenuous all along.

So BrowserEngineKit sits unused, in silent mockery of the EC’s gullibility/complicity with companies that chose to make a business of ravaging user privacy.

The Spirit of Spite

The EC doesn’t like being made a fool of, and with no legal avenue to go after Google and Mozilla for getting it to do something so idiotic, the EC likely will target its wrath at Apple, the company a­gainst which it does have a legal way to attack: fines. Under the EU’s theory of law, the EC can fine Apple just for violating the “spirit” of the law, with virtually no specificity of exactly what Apple is doing wrong, in-effect saying, our law doesn’t actually require that you allow invasive spyware on your platform, but you know that’s the real objective, so just do it already, or we’ll keep fining the hell out of you.

Exit?

The fines are potentially enormous, far outstripping Apple’s entire EU annual profits, and Apple has made it very clear over the years that it does not sell any product or operate in any market where it can’t make a profit. Will EU courts uphold massive, “spirit of the law” EC fines? And if they do, and the only way Apple can avoid paying those fines is by exiting the EU altogether, will it? That seems unthinkable — but just because Apple has made lots of money selling privacy-secure products in the EU up to this point, doesn’t mean that it can do so going forward. The legal atmosphere in the EU has dramatically changed.

Update 2025.08.06 — The UK and Japan soon also to require Apple to enable third-party HTML rendering engines. Japan’s order further prohibits Apple from:

hindering the adoption of third-party browser engines [via] indirect actions such as imposing unreasonable technical or financial barriers ...

No specificity on exactly what that means. And no mention of whether Apple will even be allowed to prohibit integrated spyware.

Update 2025.08.21 — The EC browser engine story closely parallels what happened with Google’s multi-year, public, pressure campaign to get Apple to adopt RCS, and scrap the blue-bubble-green-bubble system of its Messages app.

Google created its own, Google-controlled version of RCS, which it pushed on Android phone makers with inconsistent success. The system did not feature true end-to-end encryption: that is, readable only by the sender and the receiver, not by anyone in-between. In Google’s RCS, message encryption happens in a way that allows Goo­gle itself to read the unencrypted message.

On its public face, Google’s why-isn’t-Apple-using-RCS campaign seemed to be about emoticon reactions, dot-dot-dot activity indicators, and other things that Apple was depriving of Android users by limiting them to SMS messaging when texting with iPhone users. But Google’s ulterior issue was its inability to see the message content being sent between iPhone users. Google was hoping that Apple would relent (or be forced by legislators to relent), and would just scrap its end-to-end encrypted i­Mes­sage in favor of Google’s RCS, which would then enable Google to see all that iPhone-to-iPhone message content.

Apple surprised everyone by announcing that it will soon support RCS. However, this RCS support would use only the GSM Association definition of RCS, not Goo­gle’s proprietary, Google-controlled version, and would be used only as a fallback when Apple-to-Apple iMessage is not possible (as SMS was already being used). Also Apple immediately began working with the GSMA to develop true end-to-end encryption as a feature of GSMA RCS. In other words, Apple found a non-malicious way to do what Google was publicly scolding it for not doing, while simultaneously declining to do the very malicious thing that Google was privately hoping Apple would do.

As soon as it became apparent that it was never going to get access to Apple’s users’ iPhone-to-iPhone message content, Google lost all interest in talking about blue bubbles and green bubbles.

prev     next