Open Web Advocacy
RSS FeedA feed of the latest posts from our blog.2026-03-26T00:00:00Zhttps://open-web-advocacy.orgOpen Web Advocacycontactus@open-web-advocacy.orgOur Submission to the CMA on Apple’s iOS Interoperability Commitments2026-03-26T00:00:00Zhttps://open-web-advocacy.org/blog/our-submission-to-the-cma-on-apples-ios-interoperability-commitments/TL;DR: The UK’s Competition and Markets Authority (CMA) has stated that developers need access to key iOS and iPadOS features to build innovative products and services, so UK consumers do not miss out. As outlined in our previous article, Apple’s proposed commitments are far too weak to deliver that outcome. The CMA has the power to impose effective and enforceable interoperability obligations on mobile operating system gatekeepers under the UK’s Digital Markets, Competition and Consumers Act 2024 (DMCCA), but it does not appear to be using those powers.
This submission sets out our response to the CMA’s consultation on Apple’s and Google’s proposed commitments, focusing specifically on Apple’s proposed interoperability commitments. Building on the concerns raised in our earlier analysis, we explain why Apple’s proposal offers no meaningful outcomes, and why non-binding commitments are unlikely to deliver the interoperable access that developers, businesses, and consumers need. We argue that the CMA should not use voluntary commitments and instead should impose clear, enforceable interoperability requirements on both Apple and Google that support competition, innovation, and genuine user choice.
Our primary concerns are:
Apple retains extremely broad discretion to reject interoperability requests while remaining in full compliance, meaning the gatekeeper still decides how much competition to allow.
This is especially harmful for browsers and web apps, where API access determines whether they can compete fairly with native apps and Apple’s own services.
Weak voluntary commitments risk delaying real change while giving the appearance of action.
Worse, accepting such a weak model could entrench a dangerously low standard for interoperability in the UK and beyond, and make it harder for the CMA to enforce an effective remedy in future.
This is likely to reduce growth and innovation in the UK, which works against the CMA’s 2025 government steer.
Most importantly, it would leave in place the kind of anticompetitive conduct that the DMCCA was specifically passed to address, to the detriment of both UK consumers and UK businesses.
A big thank you to everyone who wrote in. Public submissions really do matter, and they help the CMA understand how these issues affect people in practice. Even a short one-paragraph email explaining why this matters to you as a business or consumer can make a meaningful difference.
# Response to Apple's Interoperability Commitments
Summary: Open Web Advocacy’s primary recommendation is that the CMA reject Apple’s proposed commitments and instead pursue conduct requirements that ensure genuine interoperability.
We thank the CMA for inviting feedback in both written form and through meetings. We are grateful for the opportunity to contribute to this process and to support the development of fair competition in the UK’s digital economy.
The CMA has undertaken incredible and valuable work in the digital sector over the past five years, including through the Mobile Ecosystems Market Study, the Browsers and Cloud Gaming Market Investigation Reference, and the SMS investigations concerning Apple and Google. We are deeply appreciative of the considerable effort the CMA has invested in identifying anti-competitive conduct, as well as the openness with which it has engaged with external stakeholders, including non-profits such as ourselves.
In particular, the CMA’s decision in 2021 to investigate browser engine and web app competition issues has had a significant and lasting positive impact, influencing regulatory approaches in other jurisdictions, including the EU, Australia, and Japan.
This matters as a genuinely open and interoperable ecosystem of the Web offers the clearest route to challenging the Apple and Google app store duopoly because it creates a middleware layer through which developers can reach users across operating systems. Developers can write applications once for all platforms in a single programming language, lowering cost and raising quality. Crucially, they are not forced to depend on proprietary app stores or submit to the shifting, self-preferential commercial and technical demands of gatekeepers. This reduces reliance on the dominant app stores, lowers barriers to entry, and expands consumer choice. Yet the Web is currently being constrained on mobile, primarily by Apple’s anti-competitive conduct in relation to browser engines. Fair API access, and especially effective access to those APIs for browsers, is critical to unlocking this parallel ecosystem and delivering its competitive benefits to UK businesses and consumers.
More broadly, in the context of this consultation, we are pleased that the CMA has recognised interoperability as an important mechanism for supporting effective competition for the benefit of consumers:
Furthermore, it is important that developers have interoperable access to key functionality in Apple’s iOS and iPadOS. Without the ability to access these enabling functions, UK developers cannot create the full range of innovative products and services that they would do otherwise, and UK consumers miss out as a result.
CMA - Proposed Commitments - Call for Evidence (emphasis added)
We are, however, concerned by both the substance of the measures now proposed and the method of enforcement adopted in this first wave of changes under the DMCCA.
In particular, the interoperability commitment places no obligation on Apple to share any API and provides Apple with many ways to reject any request while still remaining in full compliance. There are no clear criteria by which Apple can fail this commitment via the rejection of interoperability requests.
We are also concerned by the CMA’s decision to rely on voluntary commitments rather than imposing ex ante conduct requirements. Had the commitments themselves been robust, for example by including an obligation comparable to Article 6(7) of the Digital Markets Act (DMA), we would still have been concerned about the potential for delay inherent in a voluntary approach.
In this case it is particularly troubling because both the substance of the commitment and the mechanism chosen to enforce it are weak. It is also concerning that the measure is described as an "interoperability commitment", both in the commitment itself and in the CMA’s public communications. That risks setting a dangerous precedent by suggesting that this is the level of interoperability the CMA is prepared to accept, despite leaving Apple free to withhold any API access. It may also encourage other jurisdictions to adopt similarly weak standards, harming UK businesses’ global reach, and could make it more difficult for the CMA to impose a genuinely effective interoperability requirement in the future.
We are not alone in our concerns:
First, the commitment explicitly preserves Apple’s discretion to decline requests. [...] This reservation substantially limits the substantive impact of the interoperability commitment. [...] it should not be confused with a meaningful interoperability obligation of the kind found, for example, in Article 6(7) of the EU’s Digital Markets Act. [...] Second, the assessment criteria include alignment with Apple’s platform priorities and potential impact on Apple’s intellectual property rights. These criteria are inherently subjective and could be invoked to justify declining requests that would enhance competition.SCiDA Project - Response (emphasis added)
Apple’s proposal, as publicly described, does not create any clear right for developers to access specific APIs or functionalities, even when Apple’s own services rely on them. It leaves Apple free to accept or reject requests based on broad, subjective criteria, to delay decisions, and to impose fees or conditions that are particularly harmful to Free Software and smaller developers. A weak UK model would provide Apple with arguments against stronger regimes such as the EU’s DMA. If the CMA endorses a light-touch approach, Apple can point to it as the “compromise” that others should follow, thereby undermining efforts to enforce robust obligations in the EU and elsewhere. It would waste the DMCCA’s potential at the moment when it matters most. Endorsing Apple’s voluntary scheme would confirm those fears and risk emboldening other gatekeepers to offer similarly weak proposals. Weak enforcement entrenches anti-competitive behaviour and harms UK innovators, many of whom build on or contribute to Free Software. If Apple remains free to limit interoperability and to discriminate against Free Software, UK-based developers will continue to face structural barriers to reaching users on iOS, and UK users will continue to be denied the benefits of an open, diverse software ecosystem.
FSFE - Response (emphasis added)
We acknowledge the CMA’s desire to be pragmatic so that it can take action quickly and proportionately, but we are concerned about the precedent it is setting by accepting a weaker level of intervention. [...] This may not be problematic if commitments fully and effectively resolve issues, however this is unlikely to be the case often and it may result in increased pressure on the CMA to enforce weaker remedies in place of stronger intervention that leads to better market outcomes. Increasing the likelihood of commitments being offered as a first port of call also adds burden to the process that may slow the pace that the CMA is able to achieve effective remedies. We encourage the CMA to recognise and guard against this risk.Which? - Response (emphasis added)
# 1.1. The CMA’s Statutory Duty to Promote Competition
The CMA has recently made a number of concerning comments questioning the need to always push for competition:
Equally, it does not require us to take an overly narrow, ideological stance in defence of competition. In the current economic, political and geopolitical context, that would not, in my view, discharge our mandate in the UK’s best interests. [...] Not competition for its own sake, but in service of national priorities – specifically driving economic growth and improving household prosperity. Not competition above all else, but as a powerful tool to deploy alongside other levers – like tax, subsidy, investment, or regulation. [...] And mobile, where we secured meaningful commitments from Google and Apple to deliver improved certainty, transparency and fairness for thousands of UK businesses, dependent on app stores to access their customers. Those commitments – which include rigorous monitoring and reporting requirements - create immediate benefits without necessitating a lengthy formal process.
Sarah Cardell - the CMA’s Chief Executive (emphasis added)
It has also been suggested by the former chair of the CMA Marcus Bokkerink, that the CMA has effectively ceased enforcement of the DMCCA on US based tech giants:
I was asked if the current UK government approach to competition policy has had a chilling effect on enforcement. The short answer is two-fold. In anything to do with digital infrastructure, digital services, and AI involving US-HQd technology platform businesses with overwhelming market power, enforcement has effectively ceased (in turn discouraging innovations and alternatives to economic dependency from developing).
Marcus Bokkerink - Former Chair of the CMA (emphasis added)
However, promoting competition for the benefit of consumers is not optional. It is the CMA’s core statutory duty under the Enterprise and Regulatory Reform Act 2013:
(1)There is to be a body corporate known as the Competition and Markets Authority. (2)In this Part that body is referred to as “the CMA”. (3)The CMA must seek to promote competition, both within and outside the United Kingdom, for the benefit of consumers.Enterprise and Regulatory Reform Act 2013 - Part 3 (emphasis added)
That position was reinforced in the most recent government strategic steer, which made clear that free and fair competition, alongside consumer protection, is a driver of growth, innovation, productivity and investment in the UK:
The primary mission of this government is economic growth. Free and fair competition and effective consumer protection support growth by driving forward innovation, increasing productivity, and encouraging investment – including international direct investment – into the UK.
Strategic steer to the Competition and Markets Authority (emphasis added)
Moreover, the CMA is institutionally independent from the government. Tax, subsidy, investment and wider regulation are tools available to Parliament and government, not to the CMA. The CMA has its own statutory powers and responsibilities, and it should exercise those rather than pointing to policy levers that sit outside its remit.
Finally, the CMA has not explained in any meaningful detail why conduct requirements would fail to benefit UK consumers, or how they might harm them. Without that analysis, third-parties are left without a clear basis for assessing the claim that the CMA should refrain from using its DMCCA powers and instead rely on the government to act through tax, subsidy, investment, or other forms of regulation.
# 1.2. Legal Basis for Interoperability Requirements under the DMCCA
Interoperability was one of the very clear reasons that the CMA, using DMCCA, could impose conduct requirements.
This was highlighted during the parliamentary debates. As Viscount Camrose, former Under Secretary of State in the Department for Science, Innovation and Technology, explained:
Depending on the scope of the designation, the DMU can set conduct requirements under Clause 20(3)(e) to promote interoperability, not only with a platform but in a range of contexts, including web browsers, apps, operating systems and websites.
Viscount Camrose (emphasis added)
Damian Collins made a similar point in even stronger terms:
There are only in effect two app stores, and given the lack of interoperability, they are virtually monopolies.
Damian Collins (emphasis added)
The same point is reflected in the Explanatory Notes to the Act, which expressly state that the regime is intended to:
Ensure that designated undertakings comply with rules (called conduct requirements) on how they treat consumers and other businesses in relation to the activities in which they have been designated. [...] • Give the CMA powers to address proactively the root causes of competition issues in digital markets. It could intervene to impose interoperability obligations on designated undertakings to help new competitors enter the marketDigital Markets, Competition and Consumers Act 2024 - EXPLANATORY NOTES (emphasis added)
This is then spelt out directly in the Act itself. Section 20(3) provides that conduct requirements may be imposed for the purpose of preventing a designated undertaking from:
(b) using its position in relation to the relevant digital activity, including its access to data relating to that activity, to treat its own products more favourably than those of other undertakings; ...restricting interoperability between the relevant service or digital content and products offered by other undertakings; [...] (h) restricting the ability of users or potential users to use products of other undertakings.
DMCCA - Section 20 (3) (emphasis added)
Taken together, these materials show that interoperability was not a marginal or incidental issue in the design of the DMCCA. It was specifically identified by Parliament and directly incorporated into the statutory framework as one of the matters that conduct requirements may address.
This all suggests that there is a strong legal basis for the CMA to impose robust interoperability conduct requirements analogous to Article 6(7) of the DMA in relation to Apple or Google, should it choose to do so. Such an approach would not be an expansive reading of the CMA’s powers. It would be a straightforward use of powers that were plainly intended to address precisely these kinds of interoperability restrictions.
# 1.3. Voluntary Commitments vs Ex Ante Requirements
We consider commitments could prove a swift, effective and proportionate way of addressing these specific concerns and we have worked with Apple and Google to interrogate and further develop their proposals. Our goal is to deliver meaningful outcomes to UK consumers and businesses, and we seek to deliver these outcomes in the most effective and efficient way for the specific circumstances, using the full range of tools available to us.CMA - Proposed Commitments - Call for Evidence (emphasis added)
A useful starting point is to ask what ex ante digital regulation is for.
Regulators around the world face a basic structural problem: a handful of technology firms have legal and financial resources that exceed those of the authorities overseeing them. In practice, that means fines can be absorbed as a cost of doing business, while antitrust cases are typically lengthy, complex, and difficult to prove.
Ex ante regimes such as the EU Digital Markets Act, the UK DMCCA, and Japan’s Smartphone Act are designed to address exactly these problems. First, they allow for penalties large enough that even the biggest firms cannot simply ignore them. Second, they empower regulators to set clear pro-competitive rules in advance for firms whose scale and market power justify such obligations.
That matters because it changes the enforcement dynamic. Under an ex ante regime, gatekeepers are expected to comply proactively and to demonstrate that they are doing so. The regulator no longer needs to spend years proving the full antitrust case from first principles. Instead, it need only show that the gatekeeper has failed to comply with the applicable conduct requirements and that those requirements were lawfully imposed under the statute.
This makes enforcement faster, more predictable, and more effective. It also gives gatekeepers the opportunity to come into compliance voluntarily before any formal investigation begins, while creating significant legal consequences for refusing to do so.
There is already strong evidence, including from the EU, that Apple has self-preferenced its own products and services by giving them better and earlier access to APIs.
In the browser context, this was also a finding of the Browser and Cloud Gaming Market Investigation Reference final report:
We conclude that the evidence demonstrates that Safari has or has had wider and more immediate access to functionalities on iOS than other mobile browsers.
Browser and Cloud Gaming MIR - Final Report (emphasis added)
The same conduct is also central to the US Department of Justice’s antitrust case against Apple, which alleges that:
Apple suppresses such innovation [...] by denying access to key points of connection between apps and the iPhone’s operating system (called Application Programming Interfaces or “APIs”).
DOJ Complaint Against Apple (emphasis added)
Given the scale of the revenue Apple derives from this conduct, and the length of time for which it has persisted, it is difficult to believe the company would voluntarily stop engaging in it. Indeed, the EU experience suggests the opposite. Apple not only undermined compliance through excessive delays in processing API requests, but, once deadlines were imposed, also challenged the EU in court in multiple cases.
This is precisely why the CMA should be cautious about relying on voluntary commitments for the most important issues. The areas where Apple and Google earn the greatest returns from anti-competitive conduct are also the areas where they have the strongest incentive to resist meaningful change. They are also the areas where intervention is most urgent, because they impose the greatest costs on UK consumers and businesses and reduce the quality, openness, and competitiveness of software and devices.
Against that background, it is hard to see how voluntary commitments could be effective in relation to the most serious forms of self-preferencing and exclusionary conduct. More likely, they risk delay. Worse, they may give gatekeepers an opportunity to argue that they are already addressing the issue through arrangements the CMA has itself endorsed.
By contrast, where firms are genuinely willing to change lower-priority conduct voluntarily, those issues would also appear well suited to formal conduct requirements. In such cases, the CMA may never need to enforce them, because the firms would comply without resistance. There are already many examples under the DMA of Apple and Google making changes without the need for a formal investigation or infringement proceeding.
For all of these reasons, we urge the CMA to treat conduct requirements as one of the fastest, clearest, and most legally secure ways to address the most serious forms of self-preferencing and anti-competitive conduct by SMS firms. It is not clear that voluntary commitments will do anything other than slow the process down. There is also a real risk that they will provide strategic cover for gatekeepers while the underlying harms continue.
Competition can be the key mitigation for the UK’s digital dependency [...] With the Digital Markets, Competition and Consumers Act [...], but slow implementation and weak early enforcement risk squandering a rare pro-growthand pro-SMEopportunity. [...] The potential for huge economic growth from our tech sector is there, but competition is key. If competition flourishes, we will see more innovation, improved services and lower costs for consumers.
Peter Fortune - UK MP (emphasis added)
# 2. Review of Apple’s Proposed Interoperability Commitments
Apple has committed to providing a feedback channel for developers to make interoperability requests. Apple has committed to publicly publishing some annual statistics on this process and a statement that it is abiding by these commitments. Apple has also committed to reporting biannually more detailed data on the request system to the CMA.
This sounds promising until one examines the details, at which point multiple problems that invalidate the whole proposal become apparent.
Today’s announcement is unfortunately a gift to Apple and Google. Allowing dominant gatekeepers to set the terms of their own restraint— after years of abusing market power and dodging enforcement, including a US contempt finding against Apple — will not deliver real competition.
Coalition for App Fairness (emphasis added)
Given the highly dubious track record of these tech giants, we would question whether these voluntary commitments are really worth the paper they are printed on.
News Media Association (emphasis added)
Four years on from the publication of the mobile ecosystems market study report, the CMA isn’t actually proposing any formal conduct requirements at all. They are proposing to accept non-binding commitments from Google and Apple that they will run a fairer app review process and be fairer in how they rank apps in the app stores. Oh, and Apple is promising to consider interoperability requests fairly and objectively 😉 🤞 [...] This is disappointing. It’s an outcome so weak that the possibility is not even mentioned in the CMA’s 220-page guidance document published in December. It’s also deeply misleading for the CMA to describe these promises as “commitments”, which is a word with actual legal meaning (and legal enforceability) in the pro-competitive interventions process and in competition enforcement cases under the Competition Act.
Tom Smith - Former Legal Director at the CMA (emphasis added)
Five years after the CMA began investigating competition in the mobile ecosystem, this feels pretty weak to me. [...] Quite why the CMA does not aim to create a default interoperability requirement is beyond my small brain to fathom. But even within this very lightweight framing, Apple’s commitments are hugely underwhelming [...] Hang on: Apple can deny a competitor access to an existing iOS service, if it decides there won’t be enough user uptake? Then why did it implement it in the first place? If access to a feature, that Apple has already implemented and uses in its own products, doesn’t align “with Apple’s platform priorities”, why did they add that feature to their platform?
Bruce Lawson (emphasis added)
The first and biggest problem is that the proposal is layered with multiple ways of Apple not having to share any API it doesn’t want to, regardless of the circumstances. Nowhere in the proposed commitment does Apple commit to sharing the operating system features and functionalities used by its own apps, services and ancillary devices. It doesn’t even commit to this subject to security, privacy or other conditions.
Just in case there was any doubt, Apple states:
Receiving a request through the feedback channel will not create any obligation or expectation that Apple will commit to building a specific requested feature (or, if Apple does choose to build a requested feature, whether or* not it *will make it available to the Eligible Developer or developers generally for a fee), which will remain at Apple’s discretion in line with its commercial strategy and priorities.
Apple Proposed Commitments (emphasis added)
Apple’s “commitment” boils down to this: Apple will decide, case by case, what access it grants and to whom. It reserves the right to keep certain APIs or higher quality versions of APIs for its own apps, devices, and services. In effect, Apple is promising only that it will do what it wants.
Apple also concedes it may withhold API access where granting it could undermine its commercial strategy.
Eligibility to make these interoperability requests is limited to “developers [...] whose account membership with the Developer Program is registered in the UK”. This does not cover a significant majority of the apps and devices that are available to UK users via Apple’s app store. Many apps and devices that UK users rely on are developed by entities whose developer program is registered outside the UK. Apple needs to expand this to all developers and vendors that provide apps, services, or connected devices that work with iOS devices used by UK users, regardless of where the developer account is registered.
Receiving a request through the feedback channel will not create any obligation or expectation that Apple will commit to building a specific requested feature (or, if Apple does choose to build a requested feature, whether or not it will make it available to the Eligible Developer or developers generally for a fee), which will remain at Apple’s discretion in line with its commercial strategy and priorities.
Apple Proposed Commitments (emphasis added)
Apple has inserted a clause allowing it to charge for API access. This could be a powerful mechanism for Apple to block fair competition with its own apps. We argue here in extensive detail why API access should be free, something that the DMA already mandates.
Imagine if Microsoft charged developers for access to basic Windows APIs such as Bluetooth, so that an app had to pay Microsoft simply to use system functionality on devices that users already own. That would be an obvious barrier to competition and would clearly be ridiculous, but is the very thing that Apple is proposing here.
Apple will endeavour to provide developers with an update on the status of their requests within four weeks of receiving them. [...] Apple will inform developers of the outcome of its review of their requests, and the associated reasoning for this outcome. [...] Apple will inform developers generally about forthcoming changes to iOS and iPadOS, including those resulting from eligible requests, in its beta releases.
Apple Proposed Commitments (emphasis added)
Apple states that it will “endeavour” to provide developers with an update on the status of their requests within four weeks, inform them of the outcome and reasoning, and communicate forthcoming platform changes through beta releases.
These are weak, non-binding commitments. Apple is not required to meet the four-week timeframe, only to attempt to do so. Developers are given no certainty about whether a request has been approved, when any approved changes will be implemented, or even whether implementation will occur at all. The commitments also impose no obligation on Apple to publish in advance what changes it plans to make in response to a successful request, nor to provide a concrete delivery timeline.
Given that persistent delays were a primary reason the European Commission initiated specification proceedings against Apple, deadlines are an important requirement in any effective interoperability obligation.
Apple could fully comply with this proposal while effectively changing nothing.
The core problem is that Apple could simply deny every request for access to key APIs from companies that compete with Apple’s own apps, accessories, and services, and still claim it is following the rules. This lets Apple avoid sharing APIs indefinitely, with no real consequences. The CMA’s interventions are meant to drive real change but they risk failing in their aim of ensuring interoperable access to essential iOS and iPadOS functionality, leaving UK developers unable to build the full range of innovative products and services and UK consumers worse off through reduced choice and weaker competition.
That makes it very hard to believe this entirely voluntary proposal with no hard requirements to share anything will deliver the outcomes the CMA says it wants.
Given the powers available under the DMCCA and the SMS designations of Apple and Google, the CMA can do far better than this. Endorsing this proposal would effectively give regulatory cover to a process that offers no meaningful benefit for UK businesses or consumers. Worse, it could delay the introduction of measures that would actually be effective.
In many ways, history is repeating itself. In the late 1990s, Microsoft grew increasingly concerned that middleware could erode the Windows “applications barrier to entry”. If developers could target middleware APIs instead of Windows APIs, they could more easily port applications across operating systems, weakening the lock-in that made Windows so hard to displace.
Middleware technologies, as previously noted, have the potential to weaken the applications barrier to entry. Microsoft was apprehensive that the APIs exposed by middleware technologies would attract so much developer interest, and would become so numerous and varied, that there would arise a substantial and growing number of full-featured applications that relied largely, or even wholly, on middleware APIs. The applications relying largely on middleware APIs would potentially be relatively easy to port from one operating system to another. The applications relying exclusively on middleware APIs would run, as written, on any operating system hosting the requisite middleware. So the more popular middleware became and the more APIs it exposed, the more the positive feedback loop that sustains the applications barrier to entry would dissipate. Microsoft was concerned with middleware as a category of software; each type of middleware contributed to the threat posed by the entire category. At the same time, Microsoft focused its antipathy on two incarnations of middleware that, working together, had the potential to weaken the applications barrier severely without the assistance of any other middleware. These were Netscape's Web browser and Sun's implementation of the Java technologies.
US vs Microsoft - Finding of Fact (emphasis added)
One method of preventing third-party middleware from enabling this was simply to deny them access to the APIs they needed:
Microsoft's senior executives understood that if they could prevent this version of Navigator from presenting alternatives to the Internet-related APIs in Windows 95, the technologies branded as Navigator would cease to present an alternative platform to developers.
US vs Microsoft - Finding of Fact (emphasis added)
In 1998, the DOJ filed a suit against Microsoft alleging that the company had unlawfully maintained its monopoly by suppressing competition in web browsers on Windows. Central to the case were both contractual restrictions imposed on PC manufacturers and technical measures that made it difficult for users to remove Internet Explorer or use other programs such as Netscape and Java.
The final judgement imposed an affirmative interoperability obligation: Microsoft had to disclose the Windows interfaces that its own middleware relied on so that third-party developers could build competing middleware that interoperated with Windows on comparable terms.
Microsoft shall disclose [...] for the sole purpose of interoperating with a Windows Operating System Product [...] the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product. [...] In the case of a new major version of Microsoft Middleware, the disclosures required by this Section III.D shall occur no later than the last major beta test release of that Microsoft Middleware. In the case of a new version of a Windows Operating System Product, the obligations imposed by this Section III.D shall occur in a Timely Manner.US vs Microsoft - Final Judgment (emphasis added)
Microsoft also faced unusually high stakes during the litigation. In 2000, the district court ordered a breakup remedy, a decision that was later overturned on appeal, but it made the consequences of continued non-compliance genuinely alarming to Microsoft. It was against this backdrop that Microsoft sincerely complied with the requirements.
Gene Burrus, who spent 15 years at Microsoft managing antitrust compliance with American and European orders and decrees, had this to say:
With oversight from the DOJ, the District Court Judge, and the European Commission, Microsoft did not and could not consider compliance with the interoperability requirements to be optional or something they might take under consideration if asked. They were mandatory and therefore something the broad ecosystem could rely upon.
Gene Burrus (emphasis added)
This helped usher in significant competition in music hardware and software from Apple, whose success was used to launch the iPhone:
For example, the iPod did not achieve widespread adoption until Apple developed a crossplatform version of the iPod and iTunes for Microsoft’s Windows operating system, at the time the dominant operating system for personal computers. In the absence of the consent decree in United States v. Microsoft, it would have been more difficult for Apple to achieve this success and ultimately launch the iPhone.DOJ Complaint against Apple (emphasis added)
The iPod illustrates how yesterday’s antitrust enforced interoperability can translate into tomorrow’s innovation and growth. Apple’s breakthrough consumer product did not become a mass market phenomenon until iTunes and the iPod worked seamlessly on Windows. The iPod's success then laid the groundwork for the eventual triumph of the iPhone.
Interoperability obligations also made it far more feasible for third-party browsers such as Firefox and later Chrome to succeed on Windows, rather than leaving the field to an increasingly stagnant Internet Explorer. This shift was critical to allowing the web to compete on the desktop, where it now accounts for roughly 70% of user time.
The irony is that Apple, once a beneficiary of an ecosystem where the dominant platform was pushed to open up, is now large enough to fear the same sort of openness. Interoperability mandates are easy to celebrate when they pry open someone else’s gate, and much harder to embrace when your own platform becomes the one that must be easier to build on, easier to leave, and less able to treat integration as a moat.
To assess both the potential benefits of an interoperability obligation and the extent to which Apple might comply with such an obligation voluntarily, Europe and the DMA provides substantial evidence.
Article 6(7) has already produced a number of benefits for EU consumers and businesses. In some cases these benefits have spread globally, including in the UK.
The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services. The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.
DMA - Article 6(7) (emphasis added)
For benefits that are locked to the EU, equivalent enforcement would bring them to the UK.
Sometimes the battle for open source and freedom can take on very prosaic and practical terms, but the wins can benefit everybody. To give an example: In Beeper we need more memory for showing notifications, because we support end-to-end encryption for networks like Signal, but Apple’s default was to only give 15 megabytes — barely enough to do anything. The previous CEO of Beeper, Eric Migicovsky, started a lobbying effort with the EU’s Digital Markets Act on behalf of the team to give third-party apps the same memory limits that Apple provides for their own apps, which is 50MB instead of 15MB. (And up to 250MB on their higher end devices.) Today we’ve gotten a notification that as part of iOS 26 update Apple has shipped to 2.3B devices around the world, our memory limits issue has been addressed globally, for every application developer, and some interoperability requests we had for SMS/RCS have been addressed for EU users. Kudos and huge thank you to Apple for giving us all new capabilities to build amazing experiences for users on par with what they seek to deliver themselves.
Matt Mullenweg - co-founder of WordPress, founder of Automattic (emphasis added)
Apple was limiting all non-Apple apps to 15MB of memory, while allowing far higher limits for its own apps of 50MB, and 250MB on their higher end devices. Matt Mullenweg, the co-founder of WordPress, founder of Automattic successfully lobbied Apple to fix this using Article 6(7) of the DMA.
A gatekeeper can provide services or hardware, such as wearable devices, that access hardware or software features of a device accessed or controlled via an operating system or virtual assistant in order to offer specific functionalities to end users. In that case, competing service or hardware providers, such as providers of wearable devices, require equally effective interoperability with, and access for the purposes of interoperability to, the same hardware or software features to be able to provide a competitive offering to end users.
Digital Markets Act - Recital 55 (emphasis added)
Interestingly in this case it did not involve building or sharing a new API but rather equal access to existing APIs. This is covered by recital 55, which states that operating system gatekeepers must provide “equally effective interoperability”. The memory limit for non-Apple apps made the access to this made the interoperability with the hardware and software features of the device unequal, and thus in violation of Article 6(7).
iOS devices cannot establish a P2P Wi-Fi connection with third-party connected physical devices through either of the two connection protocols, as Apple has neither made AWDL available to third-party hardware providers, nor made Wi-Fi Aware available to third-party iOS developers [...] 5.4.7. Measures that Apple should implement: [...] (240) Apple should make Wi-Fi Aware available to third parties. [...] In its response to the Preliminary Findings, Apple proposes to introduce Wi-Fi Aware […] to provide effective interoperability with the P2P Wi-Fi connection feature on iOS for third-party connected physical devices.
DMA - Specification Proceeding - Features for Connected Physical Devices (emphasis added)
The DMA’s specification proceeding into third-party devices compelled Apple to share Wi-Fi Aware with third-party developers in the EU. Wi-Fi Aware (NAN) enables direct, high-speed connections between nearby devices without internet or infrastructure. This is low level functionality with a lot of potential applications including airdrop, local multiplayer, IoT control, proximity services and as yet uninvented innovations.
Previously Apple had reserved the functionality by not sharing AWDL (Apple Wireless Direct Link, a proprietary, high-speed mesh networking protocol developed by Apple) or making Wi-Fi Aware available to third-party developers.
Crucially, this decision was not a voluntary announcement by Apple– it was imposed by regulators. Apple has kept quiet about these changes publicly, likely because they involve opening up formerly closed-off tech. The DMA enforcement timeline was highlighted in an EU Q&A site and legal annex, not an Apple press release.7 The European Commission’s language makes it clear this is about enabling third-party devices and apps to use high-bandwidth peer-to-peer (P2P) Wi-Fi features equal to Apple’s own, rather than Apple benevolently adopting a new standard. In fact, the EU order compels Apple to deprecate AWDL and ensure third-party solutions using Wi-Fi Aware are just as effective as Apple’s internal protocols. [...] Apple’s reluctant adoption of Wi-Fi Aware marks a pivot point for device connectivity. For years, we’ve seen a split: Apple’s ecosystem “Just Works” within itself (thanks to AWDL, AirDrop, etc.), while other platforms muddled along with standards that never quite matched the seamlessness or performance. That left cross-platform interactions hamstrung – the experience of sharing something between an iPhone and an Android was far from instant or easy.
Adam Fish - Founder and CEO of Ditto (emphasis added)
Another interesting point here is that Apple will often claim security concerns but in this case when asked to actually back up those claims with evidence in a formal setting they failed to do so:
Apple’s reply to the Preliminary Findings, paragraph 376.c. Apple’s claims about integrity concerns regarding automatic Wi-Fi connection were unsubstantiated prior to the adoption of the Preliminary Findings. In fact, only in Apple’s mark-up of the Commission’s proposed measures of 23 January, did Apple even propose a mitigating measure, although again in an unsubstantiated way (see Section 4.7.7 of this Decision for details). In particular, Apple’s submission of 7 November 2024 and the cited slide deck presented on 18 October 2024, do not mention the automatic Wi-Fi connection or discuss any integrity, privacy or security concerns relevant to that feature.
DMA - Specification Proceeding - Features for Connected Physical Devices (emphasis added)
This is why placing the burden of proof on Apple to show that security measures are strictly necessary and proportionate is critical in any interoperability conduct requirement.
iOS 17.4 or later includes APIs that support contactless transactions for in-store payments, car keys, closed loop transit, corporate badges, home keys, hotel keys, program membership, and event tickets from within compatible iOS apps using host card emulation (HCE). Users based in the European Economic Area (EEA) with an iPhone running iOS 17.4 or later can initiate in-person NFC transactions from iOS apps at compatible NFC terminals or mobile devices.
Apple - Documentation (emphasis added)
In iOS 17.4 Apple shared previously reserved NFC functionality with third-parties in the EU for a range of purposes. This particular functionality was not compelled to be shared under the DMA, but rather under a long running antitrust investigation in the EU. However, this is a good example of functionality that Apple could be compelled to share in the UK under a conduct requirement.
For the globally implemented fixes described above, the DMA did not require Apple to roll out these changes worldwide, only in the EU. Apple therefore deserves some credit for addressing these anti-competitive practices globally rather than waiting to be compelled to do so region by region.
Apple’s initial response to Article 6(7) appears to have been to simply delay complying with requests for interoperability. In many cases neither accepting them nor rejecting them.
Apple also had an undefined process with multiple unnamed steps. Requesters were often told that their application had moved to the “next step”, without any details on what step that was, or what step had just been completed. In the case of some of the third-party device requests, Apple kept this going for over 6 months.
Apple informed the Commission that it has moved some of the aforementioned requests to 'the next phase of the interoperability process.' (11) (12) At the same time, Apple is 'still undertaking an assessment' of other interoperability requests made pursuant to Article 6(7) of Regulation (EU) 2022/1925 and has not yet moved these to the 'next phase' of Apple’s own review process.
Decision to a Specification Proceeding into Apple for Connected Devices (emphasis added)
This repeated delay is mentioned in the Commission’s Implementing Decision.
On its website, Apple indicated that it would aim at providing developers updates every 90 days.It appears from the 108 interoperability requests received by Apple from January 2024 until 31 October 2024, that the time taken by Apple to process interoperability requests through the different stages is significantly longer than the timelines mentioned in the previous paragraph.
Commission Implementing Decision (emphasis added)
In response the EU Commission opened a specification proceedings into Apple interop process. A specification proceeding is a process by which the EU Commission can more precisely spell out how to comply with a particular part of the DMA. The proposed measures of the interop process specification proceeding included increased upfront transparency of internal iOS and iPadOS features, timely communication and updates, fair and transparent handling of rejections and a more predictable timeline.
The EU Commission also opened a specification proceeding into interop for third-party devices in relation to several iOS connectivity features, predominantly used for and by connected devices. Including notifications, automatic Wi-Fi connection, AirPlay, AirDrop and automatic Bluetooth audio switching.
As a result of the interop process specification proceeding the EU Commission has imposed an interoperability process on Apple due to a repeated failure by Apple to both share reserved functionality and a slow-walking of existing requests.
Under the new process, third-parties have the right to file interoperability requests with Apple under Article 6(7) of the DMA. These requests can be for any software or hardware feature available on iOS and iPadOS. This includes even subsets of features, i.e. if Apple is reserving a better version for its own apps, services or devices, as well as, third-party devices interoperating with iOS or iPadOS.
Apple is only obligated to provide access to this functionality within the EU.
The request process follows 3 phases:
Phase I – Eligibility phase: Apple assesses the eligibility request to ensure that the requests fit within the scope. Must be completed within 20 days.
Phase II – Project Plan: The Project Plan should be completed by Apple within 40 working days, starting from the end of phase I. Apple should communicate the project plan to the developer who will have the opportunity to provide its feedback on it.
Phase III – Development: to establish a predictable and reliable timeline for the development phase. Apple should develop interoperability solutions that require minor, mild, and significant efforts within 6, 12, or 18 months from the submission of the interoperability request, respectively.
In response to Article 6(7) and the specification proceedings that attempted to make enforcement effective, Apple then took the EU Commission to court in three separate court cases related to Article 6(7).
In this case (still ongoing) Apple is taking the EU Commission to court claiming the following points:
Article 6(7), the article imposing interoperability requirements, which Apple argues is illegal due to being disproportionate under the European Charter of Fundamental Rights.
Apple in fact has 5 app stores, not one. i.e. the App Store on iOS, iPadOS, WatchOS, VisionOS and MacOS are distinct.
iMessage isn’t a number-independent interpersonal communications service.
Apple is asking that the court to annul the Commission’s decision designating iOS as a gatekeeper, declare Article 6(7) inapplicable, annul the finding that Apple’s App Store is a single core platform service, annul the finding that iMessage is a number-independent interpersonal communications service, and order the Commission to pay Apple’s costs.
These requirements are disproportionate under the European Charter of Fundamental Rights.
The European Commission exceeded the limits imposed by Article 291 TFEU.
That the Commission misapplied Article 6(7) of the DMA.
That Apple should not have to share new functionality with third-parties at the same time it grants them to its own apps and services.
Apple should not have time limits imposed on it for each step in the interop process.
Developers should not be able to request a technical reference from Apple to discover what undocumented functionality is available to request interoperability with.
# 4.2.1.3. Third-Party Devices Specification Process
In this case (also still ongoing) Apple is arguing that the EU misapplied the law by imposing specific interoperability requirements for the following features:
Background Execution
Automatic Audio Switching
Proximity-Triggered Pairing
Close-range Wireless File Transfer
iOS Notifications
Media Casting
Automatic Wi-Fi Connection
NFC Controller in Reader/Writer Mode
High-Bandwidth Peer-to-Peer Wi-Fi Connection
Apple is also arguing that it should not have to share new functionality with third-parties at the same time it grants them to its own apps, devices and services.
Apple argues that it does not need to allow third parties with interoperability for future updates, including new functionalities, of the features controlled or accessed via iOS at the same time as they are available to Apple. According to Apple, such an obligation is not within the scope of Article 6(7) of Regulation (EU) 2022/1925 and would limit Apple’s incentives to innovate, increase the development cost of new features, reduce Apple’s competitive advantage and allow third parties to free ride on Apple’s innovation.
Commission Implementing Decision (emphasis added)
To be successful, they rely not only on the CMA’s commitment to change, but also the willingness of businesses and advisors to engage constructively and co-operatively with what we are proposing.
Sarah Cardell - Chief Executive of the CMA (emphasis added)
Unfortunately, we believe accepting Apple's proposal would fail on all 4 of these fronts.
The CMA says digital markets move quickly and that its work must keep up with market dynamics while avoiding prolonged uncertainty that could chill investment and innovation. It emphasizes statutory time limits in the DMCCA, a duty of expedition, and a desire to focus on interventions that deliver positive outcomes quickly and effectively.
Apple's proposal places no obligation on it not to reserve APIs or better versions of APIs for its own apps, services and ancillary devices.
Apple’s proposal is too soft, too open-ended, and too dependent on Apple’s own internal priorities to deliver the rapid, market relevant outcomes the CMA says the regime should provide. A system where Apple need only try to send an update in four weeks, while retaining full discretion over whether anything is ever built, is not a pace oriented remedy.
Apple’s record in the EU makes the pace objection more serious. The Commission states that under Article 6(7), Apple must provide developers and businesses with free and effective interoperability with hardware and software features controlled by iOS and iPadOS. Yet the Commission still had to open specification proceedings. This supports the argument that absent binding obligations and enforceable deadlines, Apple will not deliver interoperability quickly on its own.
In this regard the proposal commitment fails on pace, as it will simply delay any potential effective remedy.
While it could be argued that this is simply an evidence collecting tool, the CMA has access to ample evidence in the EU both publicly and which they could request from the EU Commission.
The CMA says predictability is central because businesses need confidence to invest and innovate.
Again Apple's proposed process fails on predictability, as it is entirely up to Apple what APIs it will share. The central defect is that Apple keeps all material decisions discretionary. It lists criteria for assessing requests, but those criteria are exceptionally broad and subjective: expected user and developer uptake, alignment with Apple’s platform priorities, potential implementation costs, possible impacts on user experience and performance, security, safety, privacy, integrity, accessibility, and possible impacts on Apple’s intellectual property rights. These criteria are not framed as narrow exceptions to a presumptive duty to interoperate. They are a set of open ended considerations that Apple itself applies. That means a developer cannot reliably predict whether a request will succeed, because Apple can reject any request at will and remain in compliance. Worse, Apple states expressly that even an eligible request does not create an obligation to build anything, and that outcomes remain at Apple’s discretion.
Apple will also not provide businesses advanced warning that their request has been successful.
While a cynic could argue that it is predictable that Apple simply won't share any APIs that give its own services a significant anti-competitive advantage, that is clearly not the intent of the CMA's guidance here.
Predictability also requires that businesses are able to understand how the CMA will exercise its powers, what regulatory pathway will be followed, and what outcomes they can reasonably expect. In this case, the CMA has undermined that predictability by departing from the anticipated DMCC framework without providing any clear indication, criteria, or explanation for doing so. The decision to rely on voluntary commitments, rather than pursuing conduct requirements, was not signalled in advance and does not appear to follow an articulated or consistent approach. As a result, developers and market participants cannot reliably anticipate whether future issues will be addressed through binding obligations or negotiated commitments, nor what standard of intervention will apply. This lack of clarity weakens confidence in the regime, makes it harder for businesses to plan and invest, and undermines the ability to rely on the CMA’s processes and expected next steps.
Only a small number of designations have been made so far. For Google’s and Apple’s mobile ecosystems, the CMA has relied on non-binding “commitments” rather than imposing binding conduct requirements. These non-binding commitments have no clear statutory basis under the 2024 Act, carry no legal consequences if breached and are not contemplated anywhere in the CMA’s published guidance. Their use risks weakening the regime and forcing the CMA to restart enforcement if firms fail to comply, which is precisely the outcome that the last Government sought to avoid.
Peter Fortune - UK MP (emphasis added)
At first glance, Apple might argue its proposal is proportionate precisely because it is modest and flexible. But that is not the CMA’s concept of proportionality. The CMA says proportionality is about interventions being targeted, evidence led, tailored to maximize impact while minimizing costs, and chosen where DMCCA intervention is the most effective route to deliver the desired outcome.
Is it really proportionate to permit Apple to continue reserving APIs for its own services, to the detriment of UK businesses and consumers? And can a proposal that allows this conduct to continue truly be regarded as the most effective means of delivering the outcome the CMA itself has identified below:
Furthermore, it is important that developers have interoperable access to key functionality in Apple’s iOS and iPadOS. Without the ability to access these enabling functions, UK developers cannot create the full range of innovative products and services that they would do otherwise, and UK consumers miss out as a result.
CMA - Proposed Commitments - Call for Evidence (emphasis added)
The CMA’s proportionality framework requires that interventions be effective relative to the scale of the harm identified. In this context, the relevant evidence from both the EU and the US demonstrates a consistent pattern of delay, strategic obstruction, and “malicious compliance” by Apple when faced with interoperability or competition remedies. Even under binding regimes such as the DMA, the European Commission has had to initiate specification proceedings to secure meaningful outcomes, while in the United States Apple’s response to court-ordered remedies has involved the introduction of new barriers designed to preserve existing revenue streams. Against this background, a voluntary system in which Apple retains full discretion over whether and how to grant interoperability requests amounts to allowing it to mark its own homework. That is not proportionate to the scale of the competition problem identified. Where the evidence shows that weaker, discretionary mechanisms fail to change entrenched behaviour, a stronger, binding conduct requirement is not disproportionate but necessary.
On these grounds, we would argue that accepting Apple’s proposed commitments would fail on proportionality.
It does not seem clear that the CMA is following the expected process with regard to the DMCCA. It is not clear what part of the DMCCA the CMA is relying on for these voluntary commitments.
On the legal status of the commitments, we note that the DMCCA does not contain an explicit mechanism for voluntary commitments of this kind, and recommend that the CMA clarify their normative foundation and the consequences of non-compliance.
SCiDA Project - Response (emphasis added)
The CMA may be relying on Section 36 of the DMCCA. However, this does not seem to fit the process as Section 36 appears to apply only where the CMA is accepting a commitment from an undertaking that is already subject to a conduct investigation. If that is the route being used here, the CMA should make that explicit and publish the procedural steps that led to it.
If Section 36 is in fact the mechanism being used, it also appears to limit the CMA’s ability to open a conduct requirement investigation into the same conduct unless one of the statutory exceptions applies. Given the form of these commitments, that could be a significant problem because it may restrict the CMA’s future enforcement options.
(b) the CMA beginning a new conduct investigation in relation to the behaviour to which the commitment relates where— (i) it has reasonable grounds to believe that there has been a material change of circumstances since the commitment was accepted, (ii) it has reasonable grounds to suspect that the undertaking has not complied with one or more of the terms of the commitment, or (iii) it has reasonable grounds to suspect that information which led it to accept the commitment was incomplete, false or misleading in a material particular.
DMCCA - Section 36 (emphasis added)
In Apple’s case, none of those exceptions would obviously apply. There would likely be no material change in circumstances, no false or misleading information, and Apple could still comply with the commitment as drafted without sharing many important APIs. In that scenario, the CMA could arguably be prevented from opening a conduct investigation into interoperability because Apple would remain within the wording of the commitment.
The CMA has also been accused of misusing the word commitment in the first place which has a defined legal meaning.
It’s also deeply misleading for the CMA to describe these promises as “commitments”, which is a word with actual legal meaning (and legal enforceability) in the pro-competitive interventions process and in competition enforcement cases under the Competition Act.
Tom Smith - Former Legal Director at the CMA (emphasis added)
The way the DMCCA was expected to work as laid out, was that firms would be designated as having SMS status, then on an area by area basis the CMA would produce a binding conduct requirement. Nowhere in the SMS investigation was there any suggestion that voluntary commitments would be accepted from Apple and Google in place of conduct requirements.
Even parliament, which wrote the law, seemed somewhat surprised at the CMA's approach:
The CMA has recently started using the new powers granted by the Digital Markets, Competition and Consumers Act 2024 (DMCCA) to better protect consumers. Representations made to us throughout our consumer protection work suggest that there is plenty more for the CMA to do in this area. It is not clear it is making as many interventions as it should, nor is it clear it is fully using its new powers. For example, recently the CMA has sought voluntary undertakings from companies to remedy bad behaviour, rather than issuing binding orders.House of Commons - Business and Trade Committee (emphasis added)
While it is obviously at the CMA's discretion which conduct requirements to create, it is unclear to us whether the CMA's process is being correctly followed here.
Finally, the CMA’s most recent Strategic Steer directs it to consider the actions being taken by competition and or consumer protection agencies in other jurisdictions internationally and, where appropriate, to ensure that parallel regulatory action is timely, coherent, and avoids duplication where those actions effectively address issues arising in UK markets.
The CMA should consider the actions being taken by competition and/or consumer protection agencies in other jurisdictions internationally, and, where appropriate, seek to ensure parallel regulatory action is timely, coherent and avoids duplication where these parallel actions effectively address issues arising in markets in the UK.
Strategic steer to the Competition and Markets Authority (emphasis added)
# 5.5. Does Accepting Apple’s Proposal follow the 4 P’s
The 4Ps are supposed to describe a regime that gives businesses confidence that the rules will produce timely, knowable, effective, and participative outcomes. Apple’s proposal gives businesses only the right to ask Apple nicely. It is not clear that the CMA accepting this proposal satisfies any of the criteria of the 4 P’s.
We do not expect that commitments will be appropriate to address concerns following a Strategic Market Status (SMS) designation in all circumstances. For example, we are unlikely to pursue commitments where there is significant divergence between us and a firm on what we are looking to achieve, where firms have little incentive to change their conduct, where compliance is difficult to determine, observe or monitor, where measures can be easily circumvented, or where an SMS firm’s historical conduct does not give us confidence it will work constructively with us.
CMA - Proposed Commitments - Call for Evidence (emphasis added)
The above paragraph outlines four criteria by which the CMA will determine whether commitments as opposed to conduct requirements:
where firms have little incentive to change their conduct
where compliance is difficult to determine, observe or monitor
where measures can be easily circumvented
where an SMS firm’s historical conduct does not give us confidence it will work constructively with us
In contrast, limiting the features and functionality created by third-party developers—and therefore available to iPhone users—makes the iPhone worse and deprives Apple of the economic value it would gain as the platform operator. It makes no economic sense for Apple to sacrifice the profits it would earn from new features and functionality unless it has some other compensating reason to do so, such as protecting its monopoly profits. [...] Apple suppresses such innovation through a web of contractual restrictions that it selectively enforces through its control of app distribution and its “app review” process, as well as by denying access to key points of connection between apps and the iPhone’s operating system (called Application Programming Interfaces or “APIs”). Apple can enforce these restrictions due to its position as an intermediary between product creators such as developers on the one hand and users on the other.
DOJ Complaint Against Apple (emphasis added)
Better access to features and APIs on iOS for Apple’s apps, devices and services means that those services are superior to that of third-parties. In some cases it prohibits third-parties from offering those services at all.
Were third-parties able to compete fairly with either services or wearables this could significantly and permanently harm Apple’s revenue. It would likely force them to either raise the quality of their products or accept lower prices thus harming their incredibly high profit margin.
This would also lower lock-in for the iPhone. Lock-in is an important strategy at Apple and interoperability undermines it at its core. If users can have a mix of Apple and non-Apple devices, that raises the risk that users might entirely exit the Apple’s ecosystem.
Apple uses smartwatches, a costly accessory, to prevent iPhone customers from choosing other phones. Having copied the idea of a smartwatch from third-party developers, Apple now prevents those developers from innovating and limits the Apple Watch to the iPhone to prevent a negative “impact to iPhone sales. [...] Indeed, as early as 2010, then-CEO Steve Jobs discussed how to “further lock customers into our ecosystem” and “make Apple[’s] ecosystem even more sticky.” Three years later, Apple executives were still strategizing how to “get people hooked to the ecosystem.
DOJ Complaint Against Apple (emphasis added)
Apple’s flawed initial implementation of Article 6(7), followed by the series of lawsuits it brought against the Commission over the specification proceedings needed to make that provision effective, strongly suggests that Apple is unlikely to adopt an effective interoperability solution in the UK on a willing or voluntary basis. In practice, that means the most viable route for imposing such an obligation is through a conduct requirement under the CMA’s DMCCA powers.
Apple has not been compelled to share APIs in the United States, either by a court case or via a regulator. They have however been engaged in a very high profile court case with Epic over steering for in-app payments.
One can use their behavior in this case as a gauge to the degree to which Apple is willing to faithfully and genuinely engage in requirements from a regulator. In this case the requirements were court mandated, so one must assume that the compliance with voluntary requirements would be strictly worse.
Unfortunately Apple did not behave well in this case, and their behavior was quite possibly criminal:
Judge Yvonne Gonzalez Rogers said she was referring the matter to the US Attorney for Northern District of California to investigate whether a criminal contempt proceeding is appropriate.
Lily Jamali - BBC (emphasis added)
Though Apple largely prevailed in its original court case with Epic, the court issued an “anti-steering injunction” requiring that apps be allowed to direct users to external payment methods. The ruling left some flexibility in implementation, but Apple chose“an anti-competitive option at every step”.
Apple introduced a 27% commission on web purchases and layered on a deliberately intimidating warning screen for users leaving the app:
Rafael Onak, a user experience writing manager at Apple, instructed an employee to add the phrase “external website” to the screen because it “sounds scary, so execs will love it.” Another employee gave a suggestion on how to make the screen “even worse” by using the developer’s name, rather than the app name. “ooh - keep going,” another Apple employee responded in Slack. Even Cook got in on the action. When he finally saw the screen for approval, he asked that another warning be added to state that Apple’s privacy and security promises would no longer apply out on the web. In court, Apple tried to argue that the term “scary” didn’t actually mean it wanted the screen to scare people. “Scary,” it claimed, was a “term of art” — an industry term with a specialized meaning. In fact, the company claimed, “scary” meant “raising awareness and caution.” The court did not buy it, saying the argument strained “common sense.Jacob Kastrenakes - The Verge (emphasis added)
Rather than engaging in serious, detailed security reviews and proposing proportionate safeguards, Apple’s internal discussions have included non-security personnel, including current Apple CEO Tim Cook, exploring how to make the alternative user experience deliberately “even worse”.
Apple also attempted to engineer the directive to allow external links in apps by creating new barriers and requirements that would similarly defang those orders. It created full-page “scare screens” (I referred to them as “This App May Kill You” screens), demanded that all links be to static URLs (neutering their utility), and kept editing the warning labels to dissuade users as much as possible from ever agreeing to follow the link. (Cook is specifically credited with amping up the language in the warning screens.) The company’s internal struggle is fascinating to read about. While Apple Fellow and longtime App Store overseer Phil Schiller doesn’t come across entirely smelling like a rose, he does end up looking far better than literally any other Apple employee in the ruling. Schiller “advocated that Apple comply with the Injunction”—imagine that!—while Tim Cook, CFO Luca Maestri, and the company’s finance team instead decided to concoct a strategy of malicious compliance that led to the poison pill of the 27% commission.”
Jason Snell - Six Colors (emphasis added)
This approach backfired on Apple when the judge found:
Apple willfully chose not to comply with this Court’s Injunction, It did so with the express intent to create new anticompetitive barriers which would, by design and in effect, maintain a valued revenue stream; a revenue stream previously found to be anticompetitive. That it thought this Court would tolerate such insubordination was a gross miscalculation. As always, the cover-up made it worse. For this Court, there is no second bite at the apple.
Gonzalez Rogers (emphasis added)
The historical conduct of Apple in both the EU and the US is strong evidence of the risk of circumvention. Given the number of ways Apple has given itself to not share functionality with third-parties in their proposal, we would argue that the proposal itself is evidence that Apple wishes to continue to reserve functionality or superior versions of functionality for its own services.
# 6.5. Issues with Monitoring Under Current Proposal
The current proposal primarily relies on aggregate statistics. Given the complexities of requests for API access this is unlikely to be an effective mechanism. A far more straightforward mechanism is to make all requests and responses public, unless the requester specifically wishes to make it (or parts of it) confidential. This is the approach the DMA has taken.
This is important for several reasons. One, it will allow like minded developers to work collaboratively with other requesters on the proposed interoperability solutions. Two, where Apple’s rejections are unreasonable, they can be publicly cited and pressure can be applied on Apple and finally it allows non-profits and other regulators to assess the degree to which Apple is sharing functionality in response to requests.
# 7. Should Google have an Interoperability Requirement on Android
We have heard fewer concerns from developers about lack of access to functionality for Google, where Android allows for broader third-party interoperability.
CMA - Proposed Commitments - Call for Evidence (emphasis added)
While we believe that Google is genuinely better behaved at not reserving APIs for its own usage, it should be straightforward for the CMA to impose an equivalent requirement on Google with respect to Android.
The fact that they are already mostly in compliance should make the burden of complying and the level of enforcement required from the CMA both low.
This requirement needs to consider APIs that are delivered via Google Play Services as Android APIs. One good example of an API that Google is refusing to share with third-parties is WebAPK minting.
There is a genuine concern here that if the CMA adopts a weak voluntary proposal such as what Apple has put forward, that not only could it be ineffective but that it could be used as ammunition to attack effective regimes such as the DMA. Apple could point to a weaker UK model as the alternative other jurisdictions should follow as they design their own rules, pulling global standards down until they are ineffective.
We are also concerned that by accepting such commitments that the CMA could limit its ability to enforce future commitments, as Apple could argue that it is abiding by terms that the CMA itself endorsed on interoperability.
Our view is that enforcement action has been quite weak,” Byrne said. “We are concerned about whether you might pull your punches and leave the new powers available to the CMA unused,” he added later, referring to the Digital Markets, Competition and Consumers Act, which came into effect last year and has significantly expanded the regulator’s powers, enabling it to give companies specific regulatory rules and engage in proactive enforcement, impose stronger penalties, and directly enforce consumer protection laws.
Labour MP Liam Byrne - On opendemocracy (emphasis added)
Apple has a long record of fighting digital regulation worldwide, often through friendly sounding third-parties. The company particularly dislikes the EU’s Digital Markets Act (DMA) because it is actually forcing meaningful changes at Apple and has already delivered multiple benefits.
At the same time, Apple has used noticeably softer language about Japan’s Mobile Software Competition Act (MSCA), which is less stringent in key areas. When announcing major App Store and iPhone changes for Japan, Apple argued that Japan’s approach “balances openness with security and user protection” better than the EU’s DMA, including because Apple does not have to support web based app downloads in Japan in the way it does under the DMA.
Broadly speaking, Apple says Japan’s MSCA does a better job of balancing openness with security and user protection than the DMA in the EU. For example, Apple does not have to support app downloads from the web in Japan like it does under the DMA. Apple retains ability to protect users from malware and other security risks. This is especially true when it comes to protecting children, as outlined below.
Chance Miller - 9to5Mac (emphasis added)
John Gruber, who was present in the same briefing as the 9to5Mac report, said Apple’s tone was even clearer than the published summary suggested. He wrote that Apple repeatedly framed the MSCA as more aligned with Apple’s privacy and security priorities than the DMA, and emphasized that Japan’s framework respects Apple’s intellectual property in ways Apple claims the DMA does not.
You can search, but you won’t find quotes from Schiller, nor any other Apple representatives, speaking of their “great respect for” and appreciation of the work they’ve done together regarding the European Commission and the DMA. [...] I was in the same briefing with Apple representatives as Miller, and I’d say Apple was more clear than that. In addition to seeing the MSCA as more aligned with Apple’s own priorities regarding privacy and security than the DMA, Apple repeatedly emphasized that the MSCA respected Apple’s intellectual property in ways that the DMA does not. Complying with the DMA is adversarial and obtuse. [...] Because of the DMA, Apple has delayed and outright withheld major features in the EU. iPhone Mirroring, one of Apple’s best new features in recent years, is still unavailable in the EU. Apple fully expects more features to be delayed or withheld from the EU as time goes on. (With Apple Watch, they’ve now been forced to remove (or perhaps better said, hamstring) a feature that existed since Apple Watch debuted in 2015.) There have been no such feature delays (let alone withholdings) in Japan"
John Gruber - Daring Fireball (emphasis added)
One group, The App Association has said:
“Addressing the negative effects of the Digital Markets Act (DMA) on small businesses has been a priority for the App Association”. “The DMA is hamstringing small tech companies in the U.S. and EU”. “In taking aim at big tech, it is causing untold collateral damage on App Association members and other small tech companies that rely on the global reach of curated online marketplaces” “Reducing security and trust in the app ecosystem will only ‘level the playing field’ for gatekeepers and large developers”
The App Association (emphasis added)
Reading this, one might become concerned that app developers are genuinely worried about stronger tech rules for Apple and Google. However, it appears that the app association is not quite as independent from Apple as it makes out:
[[Apple]] plays a dominant behind-the-scenes role shaping the group’s policy positions, according to four former App Association employees who asked not to be named discussing internal matters
Bloomberg - Apple Flexes Muscle as Quiet Power Behind App Group (emphasis added)
The App Association says it “gives a voice to small technology companies” and that its “policy priorities reflect the opportunities and challenges today’s small business app developers and IoT innovators face in the app ecosystem.” But its positions on major legislation have aligned with Apple’s. The group’s list of policy statements going back to early 2017 include some specifically praising Apple and others opposing legislation that Apple also opposes, such as antitrust bills targeting Big Tech.Jon Brodkin - Ars Technica (emphasis added)
Washington D.C. tech industry group The App Association boldly refers to itself as, “the leading industry voice on the app economy,” and says it represents more than 5,000 app makers and connected device companies spread out around 27 countries worldwide. What The App Association’s website doesn’t say is that more than half its estimated $9 million worth of sponsorships revenues in 2020 came from one company—Apple.Mack DeGeurin (emphasis added)
The App Association, perhaps unsurprisingly, was one of the few groups with a positive viewpoint on Apple’s and Google’s voluntary commitments in the UK:
The commitments from Apple and Google are good news for small British app developers and a sensible solution to the CMA’s concerns. [...] ‘The CMA’s consultative approach shows they have heard the concerns of our members, who reject the EU model of heavy-handed regulation where government bodies become de-facto product designers for the tech we all use daily.
The App Association (emphasis added)
The CMA needs to guarantee that any proposal it accepts, at a minimum, does not reduce the benefits from foreign digital regimes. As documented in this response, a number of these benefits have spread to the UK, and are currently benefiting UK consumers and UK businesses.
The CMA must also ensure that accepting such voluntary commitments does not weaken its ability to pursue conduct requirements in the future.
The global regulatory environment must be considered when imposing conduct requirements. Weak enforcement sets precedent for future weak enforcement, strong enforcement does the opposite.
# 9. Why the UK needs a General Interoperability Conduct Requirement
Interoperability is the foundation of effective competition in digital markets. On mobile platforms, access to operating system features and application programming interfaces (APIs) determines what third-party developers can build, how well their products perform, and whether they can compete on equal terms with the platform owner’s own apps and services. Without meaningful interoperability, competition is constrained not by innovation or consumer preference, but by technical restrictions imposed by the gatekeeper.
This is in particular critical to allowing the Web to compete fairly as an interoperable alternative to Apple and Google’s native app ecosystems. Allowing browsers, and via them web apps, to compete fairly unlocks the world's best interoperable solution to app development and distribution. API access both for browsers and the web apps they power as middleware, is a critical part of making this viable. By allowing browsers to securely provide API access to the web apps they power, this disassociates that access from the conditions and fees that Apple and Google impose on developers. Providing browsers with a right to access required APIs is a key part of enabling this.
For native apps, including third-party browsers, Apple’s control over iOS gives it the power to decide which capabilities are available to others and under what conditions. As the Competition and Markets Authority has previously observed:
Apple’s control over iOS also allows it to determine the ‘rules of the game’ by determining which APIs are made available to third parties and on what terms. This is important as the functionality of native apps and browser engines on a mobile device is determined by which APIs they can access
CMA - Mobile Ecosystems Market Study (emphasis added)
Interoperability also plays a crucial role in reducing user lock-in. When devices, apps, and services work only within a single ecosystem, consumers face significant costs when attempting to switch platforms. Data may not transfer easily, accessories may become unusable, and familiar services may lack equivalent functionality elsewhere.
This lock-in weakens competitive pressure on the dominant firm. If users cannot realistically leave, the firm has less incentive to improve products, lower prices, or respect consumer preferences. Developers likewise become dependent on the platform for distribution and functionality, making them vulnerable to unilateral changes in rules, fees, or access.
Interoperability via middleware would reduce lock-in for Apple’s devices. Lock-in is a clear reason for Apple to block interoperability, as can be seen in this email exchange where Apple executives dismiss the idea of bringing iMessage to Android.
The #1 most difficult [reason] to leave the Apple universe app is iMessage ... iMessage amounts to serious lock-inUnnamed Apple Employee (emphasis added)
iMessage on Android would simply serve to remove [an] obstacle to iPhone families giving their kids Android phones ... moving iMessage to Android will hurt us more than help us, this email illustrates why.
Craig Federighi - Apple's Senior Vice President of Software Engineering (emphasis added)
Or this now infamous exchange between Tim Cook and Vox Media's LiQuan Hunt:
Not to make it personal, but I can't send my mom certain videos, or she can't send me certain videos
Vox Media's LiQuan Hunt (emphasis added)
Apple will often claim when they reserve a feature for itself or limit interoperability that the primary purpose is not to increase lock-in or Apple’s own profits, but rather to protect its own users.
Tie all of our products together, so we further lock customers into our ecosystemSteve Jobs (emphasis added)
I think this is all pretty simple, [Apple's] iBooks is going to be the only bookstore on iOS devices. We need to hold our heads high. One can read books bought elsewhere, just not buy/rent/subscribe from iOS without paying us, which we acknowledge is prohibitive for many things.
Steve Jobs (emphasis added)
I just watched a new Amazon Kindle app ad on TV. It starts with a woman using an iPhone and buying and reading books with the Kindle app. The woman then switches to an Android phone and still can read all her books. While the primary message is that there are Kindle apps on lots of mobile devices, the secondary message that can’t be missed is that it is easy to switch from iPhone to Android. Not fun to watch.Phil Schiller (emphasis added)
This is now being viewed increasingly sceptically by both regulators around the world and the general public.
That is not to say that there are no security issues related to sharing APIs, but rather that Apple should be restricted to only strictly necessary security measures which Apple can prove are justified and proportionate.
As the DOJ noted in their complaint against Apple:
In the end, Apple deploys privacy and security justifications as an elastic shield that can stretch or contract to serve Apple’s financial and business interests.
DOJ Complaint against Apple (emphasis added)
Last year there were calls for the Competition and Markets Authority (CMA) to be “more pro-business”, which appeared to suggest that the UK should ease up on enforcing rules against some of the world’s most powerful companies. Former Chancellor Jeremy Hunt went so far as to publicly admonish the CMA, urging regulators to “understand their wider responsibilities for economic growth”.
The move follows a meeting between CMA Chief Executive Sarah Cardell and other regulators with British Finance Minister Rachel Reeves to deliver ideas on how to stimulate growth. Regulators were told to “tear down the barriers hindering business and refocus their efforts on promoting growth.
Ryan Browne - CNBC (emphasis added)
But this framing is backwards. Weakening enforcement of competition rules does not drive economic growth, quite the opposite. Economists widely agree that tolerating anti-competitive behaviour entrenches dominant firms, stifles innovation, and ultimately harms consumers and startups alike. It also risks conflating the continued expansion of already powerful corporations with genuine economic growth. The CMA’s role is not to enable dominant firms to use anti-competitive conduct to grow and further entrench their market position, but to maintain competitive conditions so that new entrants and challengers can succeed, driving innovation, productivity, and broader benefits across the economy.
It seems like the UK now welcomes monopolies provided they have an investment story. There’s something really topsy-turvy about this.
Former CMA Regulator (emphasis added)
This matters as competition is the primary driver of growth and innovation. Companies that, due to anti-competitive behaviour or some structural reason, do not face sufficient competition, are likely to raise prices and minimize expenditure beyond what is necessary to retain existing customers.
Consumers, competition, and the competitive process—not Apple alone—should decide what options consumers should have. And competition, not Apple’s self-interested business strategies, should be the catalyst for innovation essential to our daily lives, not only in the smartphone market but in closely related industries like personal entertainment, automotive infotainment, and even more innovations that have not yet been imagined. Competition is what will ensure that Apple’s conduct and business decisions do not thwart the next Apple.DOJ Complaint against Apple (emphasis added)
The idea that easing pressure on gatekeepers will help startups is fundamentally flawed. In reality, failing to curb the control dominant firms exert over their platforms, especially through blocking competition, actively harms smaller players and undermines the interests of the UK public. Interoperability rules will help startups not hurt them:
The victims of a DMA pause would be America's most innovative upstarts — especially AI start-ups. The DMA's interoperability and fairness rules were designed to pry open closed platforms and give smaller companies a fighting chance. [...] Big Tech lobbyists portray the DMA as anti-American. In reality, the DMA's goals align with American ideals of fair competition. This isn't Europe versus America; it's open markets versus closed ones.
Luther Lowe - Y Combinator - Head of Public Policy (emphasis added)
Start-ups are a key part of the innovation economy, it is the gatekeepers who often lag in innovation. The CMA’s most recent report highlighted that Apple can and does profitably forego innovation without fear of losing customers to competitors with this quote:
Apple’s vice president of iPhone marketing who explained in February 2020: ‘In looking at it with hindsight, I think going forward we need to set a stake in the ground for what features we think are ‘good enough’ for the consumer. I would argue were [sic] already doing more than what would have been good enough.’ After identifying old features that ‘would have been good enough today if we hadn’t introduced [updated features] already’, she explained, ‘anything new and especially expensive needs to be rigorously challenged before it’s allowed into the consumer phone.’
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
We do not expect that commitments will be appropriate to address concerns following a Strategic Market Status (SMS) designation in all circumstances. For example, we are unlikely to pursue commitments where there is significant divergence between us and a firm on what we are looking to achieve, where firms have little incentive to change their conduct, where compliance is difficult to determine, observe or monitor, where measures can be easily circumvented, or where an SMS firm’s historical conduct does not give us confidence it will work constructively with us.
CMA - Proposed Commitments - Call for Evidence (emphasis added)
The second issue with the proposed approach is that accepting commitments may set an unintended benchmark for the acceptability of commitments in place of Conduct Requirements. In allowing these priority issues to be resolved through commitments, and noting the prominence that is associated with the first set of interventions in this investigation (and only the second interventions proposed by the Digital Markets Competition Regime as a whole), SMS firms may take encouragement that offering commitments is a viable way to resolve issues that have been identified … and it may result in increased pressure on the CMA to enforce weaker remedies in place of stronger intervention that leads to better market outcomes. Increasing the likelihood of commitments being offered as a first port of call also adds burden to the process that may slow the pace that the CMA is able to achieve effective remedies. We encourage the CMA to recognise and guard against this risk.Which? - Response (emphasis added)
The CMA has been clear that commitments will not be suitable in every SMS case, especially where remedies are easy to circumvent, hard to monitor, or where the firm’s past conduct suggests it will not engage constructively.
In Apple’s case, the measures they are proposing “can be easily circumvented”, Apple’s historical conduct both globally and with the DMA "does not give us confidence it will work constructively with [[the CMA]]” and Apple not only has “little incentive to change their conduct” but has vast incentives to preserve the status quo.
Our recommendation is therefore that the CMA impose a clear, enforceable requirement on Apple to provide, free of charge, access to all APIs and operating system features needed for third-parties to interoperate with iOS. This obligation should be subject only to security measures that are strictly necessary and proportionate to protect the integrity of the operating system. The burden of proving that any restriction is necessary and proportionate should rest entirely with Apple. Eligible third-parties should include all businesses and developers that provide apps, services, and ancillary devices to UK consumers.
This is especially important for third-party browsers with their own engines and the open, interoperable web ecosystem they enable. Allowing that ecosystem to thrive and compete on fair terms would also reduce the regulatory burden on the CMA in relation to app stores, by placing meaningfulcompetitive pressure on SMS app stores to moderate their fees and policies or risk losing developers. Effective API access, particularly for browsers, is essential to unlocking this ecosystem and delivering its benefits to UK businesses and consumers.
We further recommend that the CMA closely examine the EU’s experience under the DMA with comparable interoperability obligations, including the extent of Apple’s compliance and the practical lessons on enforcement. We recommend that the CMA team meet directly with the EU enforcement team responsible for DMA Article 6(7) and with the US Department of Justice team leading the Apple case to align on evidence, enforcement lessons, and practical remedies under the Multilateral Mutual Assistance Framework. We recommend that the CMA defer any final decisions on interoperability until these discussions have taken place and the resulting evidence, technical detail, and enforcement lessons have been reviewed and incorporated. This ensures the CMA’s approach is grounded in real-world enforcement experience and avoids predictable loopholes as well as results in remedies that are practical, measurable, and indeed enforceable.
In particular, the CMA should consider what additional safeguards are needed around deadlines, API stability, transparency, and monitoring so that the requirement is effective in practice.
OWA would like to make the following recommendations:
Our primary recommendation is that the CMA reject Apple’s proposed commitments and instead pursue conduct requirements that ensure genuine interoperability
The interoperability process must be clear, detailed and have defined steps.
Each step must have binding deadlines for Apple.
Apple must enable a public tracker system, where developers can submit their requests and make those requests public, with public responses while reserving the ability for the developer to make confidential submissions.
Upfront publication of any security measures, with Apple required to justify them publicly as strictly necessary and proportionate.
No presumption that Apple’s security is inherently more secure than third-parties.
APIs provided free of charge.
An independent appeals process.
Finally, the CMA should build in a structured review and update mechanism from the outset, on the assumption that new circumvention strategies will emerge and will need to be addressed quickly.
Without these measures, it is, in our view, highly likely that the CMA’s stated objective to grant developers interoperable access to key functionality in Apple’s iOS and iPadOS to create innovative products will fail.
OWA believes that the Web’s unmatched track record of safely providing frictionless access to information and services has demonstrated that it can enable a more vibrant digital ecosystem. The web’s open, interoperable, standards-based nature creates an inclusive environment that fosters competition, delivering the benefits of technology to users more effectively and reliably than any closed ecosystem.
OWA’s goal is to ensure that browser competition is carried out under fair terms, that user choice in browsers matters, and that web applications are provided equal access and rights necessary to safely contest the market for digital services.
OWA believes competition, not walled gardens, leads to the brightest future for consumers, businesses, and the digital ecosystem.
Open Web Advocacy is a not-for-profit organization made up of a loose group of software engineers from all over the world, who work for many different companies and have come together to fight for the future of the open web by providing regulators, legislators and policy makers the intricate technical details that they need to understand the major anti-competitive issues in our industry and potential ways to solve them.
We are available to regulators, legislators and policy makers for presentations/Q&A and we can provide expert technical analysis on topics in this area.
For those who would like to help or join us in fighting for a free and open future for the web, please contact us at any of the links below.
]]>
Q&A with Simonetta Vezzoso: The Open Web, Apple, and the DMA2026-03-23T00:00:00Zhttps://open-web-advocacy.org/blog/question-and-answer-with-simonetta-vezzoso--the-open-web--apple-and-the-dma/TL;DR: Alex Moore (Executive Director of OWA) and John Ozbay (CEO and Founder of Cryptee) were recently interviewed by Simonetta Vezzoso, a European academic specializing in digital competition law and the EU’s Digital Markets Act (DMA).
John, you are a software engineer. How did you end up doing digital policy in the general interest on top of your day job?
I'm a software engineer and I'm the founder and CEO of a company called Cryptee. About two years ago, Apple wanted to try to kill web apps and they used European Commission's DMA as an excuse. I reached out to a bunch of amazing folks at Open Web Advocacy and I got involved in and I've been doing this ever since. My platform is intentionally not on the app stores because I never wanted to give Apple or Google 30% of the commission. We intentionally decided that we're going to ship only web apps.
John Ozbay - CEO and Founder of Cryptee
Alex was asked how the open web supports the goals of the DMA and similar regulatory efforts:
How does the open web support the goals of the DMA and similar digital regulation regimes around the world in your opinion?
That's a good question and I think it really comes down to when you talk about the open web, it is really the only existing scalable interoperable cross-platform competitive constraint on the mobile operating systems and app store gatekeepers. Because if you talk about the DMA's core aims: contestability, fairness, interoperability, user choice, all of those line up perfectly with what a healthy web delivers.
Now, the other thing that the web delivers is much lower switching costs. And that's because you get lower development costs because you write once, deploy everywhere. You have a reduced dependency on app stores. You don't have to pay gatekeeper fees. The apps work automatically on third party devices. And really, so if you're talking about a clear route to challenging the Apple and Google duopoly, then having a middleware layer that works across those operating systems is our best bet.
And then if you talk about what the downstream consumer benefits of this is going to be lower prices, better innovation, higher quality software and again less lock in and a better chance for a new operating system or device ecosystems to emerge.
Alex Moore - Executive Director of OWA
John also had an excellent description of why the web remains uniquely accessible for smaller businesses:
What's amazing about the web is that it doesn't require you to have a multi-million dollar company to take part in to create a website. You can do it for a few bucks yourself or it doesn't require you to have any specific technical knowledge when you can use stuff like Squarespace to create websites for yourself. So that's the cool thing about the web is that it's open versus if you think about app stores, they're not exactly open.
They're the opposite of open where you have to pay Apple some fees and it's only specific for a specific platform and all these things are restrictions around what you can and can't do on iOS and which features you're allowed to ship and which features you're not allowed to ship. You have to sign some special agreements with Apple or Google and whatnot. So, we believe that the web is cool because it's very very open and it stands for all this openness that comes from not being attached to any specific gatekeeping business party.
John Ozbay - CEO and Founder of Cryptee
Alex was also asked why the European Commission has not yet brought an anti-circumvention case against Apple:
If Apple formally allows alternative web browser engines, but other contractual or technical barriers mean that none have been shipped so far, why hasn't this become a test case for anti-circumvention? In your opinion, what's stopping it?
I suppose it's good to think about the digital market in terms of practicalities. [...] Apple has a legal budget of a billion dollars per year now when you're going up against a party that has a legal budget that dwarfs your own budget. It means you need to be quite careful when you're enforcing the regulation. Making sure you follow every single step and that when you take it to court, you are going to win that battle because every battle lost in court means that it's going to weaken the digital regulation to everyone else. And so what I think that means in terms of the digital market, there's a certain capacity about how many cases they can take on and process per year. And I think one of the biggest areas that the EU could look at improving is to expand the bandwidth of what the DMA could actually handle at one time. And then maybe we could get through more of these cases concurrently.
And you have to realize Apple makes an enormous amount of money from Safari. I think the last count was something like $22 billion dollars per year because they set Google searches the default and they get a revenue share agreement with Google and so even if they lose 1% of market share globally that's worth $200 million a year for them. So they will fight tooth and nail to protect browser share including putting up all these stupid rules to prevent other competitors from getting into the market and actually being able to compete.
Now in terms of browser engines we have made some progress over the last couple of years in that there's been a whole list of just ridiculous conditions that we've managed to overturn and those issues have been fixed. But the big one that is still a major sticking point is Apple has basically said that if you want to ship your browser to EU, you have to ship a brand new browser, right? And so you got to think about that from the browser company's point of view. Let's say you've got 20 million or say you got 10 million users in the EU and they're in your Apple WebKit based browser. Now what Apple's saying is they want you to bring out another browser and cannibalize your own market by migrating the users. Now the thing is we've already come up with easily workable solutions that are even jurisdictionally constrained with the EU. They can even allow both engines to live within a single app, you know, have two engines inside one app and then you just have a toggle. If we're inside the EU, we use their real browser engine. If we're outside the EU, we use the WebKit one. That's just a contractual change. So to fix that one, all they need to do is go into one contract, change one line, and that problem's done. No technical changes needed whatsoever.
Alex Moore - Executive Director of OWA
The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services.
Digital Markets Act - Article 5(7) (emphasis added)
At this point, it is clear that compliance is not being meaningfully achieved. The European Commission should open a formal investigation into Apple’s compliance with Article 5(7). Without decisive action by the European Commission, Apple appears set to hold back browser, browser engine, and web app competition on iOS indefinitely, undermining the objective laid out in Recital 43.
When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users.
Digital Markets Act - Recital 43 (emphasis added)
]]>
Google Backs Down: Will Grant Hotseat in EU Browser Choice Screen2026-03-12T00:00:00Zhttps://open-web-advocacy.org/blog/google-backs-down--will-grant-hotseat-in-eu-browser-choice-screen/TL;DR: In a significant win for smaller browsers, the open web, and the EU’s Digital Markets Act (DMA), Google has agreed to place the browser selected through the EU browser choice screen directly in the Pixel homescreen hotseat (replacing Chrome).
Previously, even when users selected a different default browser, Chrome remained in this prominent position, steering users back toward Google’s own browser and undermining the user’s choice.
We are grateful to BEUC, Mozilla, Vivaldi, DuckDuckGo, Ecosia and Brave for their valuable support in achieving this result, and to OWA volunteers John Ozbay, Roderick Gadellaa and James Heppell who helped make this happen at the DMA workshops last year. Finally, and perhaps most of all, we thank the European Commission’s Digital Markets Act team for its important precedent-setting work. The EU’s browser choice screens will help push the world toward a fairer and more competitive browser ecosystem, where gatekeepers can no longer rely on operating system defaults to preserve their market share and must instead compete to earn it.
The hotseat refers to the set of app icons located on the dock at the bottom of the homescreen on both iOS and Android devices. These icons have the advantage of always being shown regardless of which homescreen the user is on. This is prized real estate for any commonly used app.
The hotseat on Android’s homescreen
On all Apple devices and many Android devices, the gatekeeper’s browser is placed in the hotseat via the default setup of the device.
# Our Longstanding Argument for Respecting User Choice
As far back as early 2023, OWA started its campaign for browser choice screens, including hotseat placement, through meetings with regulators.
OWA’s Presentation to the UK CMA’s Browsers and Cloud Gaming MIR Team in 2023
This has long been a concern for Open Web Advocacy, and it was included in our list of recommendations published in our 7th of March 2024 article marking the beginning of DMA compliance obligations for gatekeepers:
Reduce the power of the default browser with a choice screen
Ensure that both Apple and Google implement effective designs for their browser choice screens. Specifically, the choice screen should not self-preference their own browsers, should grant the chosen browser the “hotseat” and should appear on all existing devices once and all new devices (including after backup and restore).
Open Web Advocacy
OWA’s Presentation to the EU’s Digital Markets Act 6(3) Team in 2024
However Google refused to make the equivalent change on covered Android devices. When we (along with Mozilla) questioned Google about this at last year’s DMA workshop, Google representatives essentially flatly denied they had any obligation to do so under the wording in the DMA:
And then the question from Open Web Advocacy on hotseat, again our approach to this is informed by what the DMA says, and Article 6(3) is clearly about defaults, a hotseat is not a default, so a default is a service that will trigger as a result of a generic user action, as I mentioned earlier, and so if the user goes to do something, for example clicks on a URL, it would be the browser that is used in order to fulfil that specific user intent. The placement of a particular app on a device has nothing to do with the default. And so that is our view in respect of how the hotseat question fits with what we are talking about, when we are talking about compliance with the DMA.
Clare Kelly - Google - Senior Competition Counsel (emphasis added)
We disagreed. Specifically Google was trying to narrow the DMA by treating "default settings" as meaning only "which app was default", but the DMA’s own wording is broader. Article 6(3) covers any operating system default setting that directs or steers users toward a gatekeeper’s browser by default, not just which app is set as the default browser. That means pre-set choices like home screen placement or other OS-level configurations can also fall within scope when they advantage the gatekeeper’s services. In this context, the DMA applies specifically to defaults that shape user behavior in ways that favor the gatekeeper or determine which browser or service users are steered toward. You can read our full analysis here.
On the 9th of March 2026, it emerged that Google had reversed its stance and agreed to give the chosen browser the hotseat, likely due to the work behind the scenes of the EU Commission:
Due to pressure from stakeholders (and most prominently, from Open Web Advocacy),the gatekeeperfinally budged and agreed to place the icon of the browser selected by the user as a default from the choice screen displayed according to Article 6(3) DMA in the hotseat of new Pixel devices (page 125 of Alphabet’s compliance report) (although not on all Android devices).
Dr Alba Ribera Martínez - Lecturer in Competition Law at University Villanueva (emphasis added)
Choice Screen Design
Without prejudice to Google’s legal position that this is not required by Article 6(3), Google has agreed to place the icon of the browser selected by the user from the choice screen in the hotseat of new Pixel devices.
Google - EU Digital Markets Act Compliance Report
Given the successful implementation and precedent of the EU browser choice screen, we urge other regulators (such as the CMA and JFTC) to implement an equivalent design for both Apple and Google.
The EU choice screen is a strong design, but could be improved for future implementations with the following changes:
On iOS, the choice screen should display on startup, not on the user’s first interaction with Safari.
Changing default browser (not via the choice screen) should replace the operating system’s browser on the homescreen or in the hotseat.
The choice screen should be redisplayed on each major version upgrade where the gatekeeper’s browser is still the default.
The choice screen on Android should apply to any device where Chrome is placed prominently on the homescreenorhotseat via the default setup of the device.
On new devices, the gatekeeper’s browser should be uninstalled if it was not selected.
The choice screen should not force browser vendors to ship their browser via the gatekeeper’s app store in jurisdictions where alternative app stores and direct download are available.
If you're thinking about doing choice screens in your jurisdiction, please reach out!
This development is another success for the DMA and for browser competition in Europe.
The EU browser choice screen has already helped smaller browsers gain market share by allowing users to make a genuine choice about their default browser. This choice screen has already led to meaningful gains in market share; Mozilla, for example, saw its daily active users double in France and Germany on iOS, where the hotseat change is implemented. DuckDuckGo’s findings suggest that replacing Safari in the hotseat boosted the iOS choice screen’s effectiveness by a factor of nine. Ensuring that the chosen browser also occupies the hotseat reinforces that choice and prevents platform owners from directing users back to their own products.
Browsers need to compete on merit, not via privileged placement within an operating system. It is genuine competition between browsers that delivers the best outcomes for consumers and developers. This change is one more step in the right direction.
]]>
OWA on RedMonk: Why the Mobile Web Still Can’t Compete with Native Apps, and How to Fix It!2026-02-27T00:00:00Zhttps://open-web-advocacy.org/blog/owa-on-redmonk--why-the-mobile-web-still-cant-compete-with-native-apps-and-how-to-fix-it/
We recently spoke with RedMonk senior analyst Kate Holterhoff about a question that has shaped the mobile ecosystem for over a decade: why has the open web struggled to compete with native apps on mobile, and what can regulators do to restore competition?
Talk to me about the history. When was the OWA founded?
Kate Holterhoff
So we started in early 2021 and we’d been waiting for features from Apple for about 10 years. The main ones being install prompts for web apps and notifications, which we identified as the biggest blockers for web apps taking off. And we tried very hard to get Apple to do it. So we were messaging their top engineers. We were petitioning them. We were posting on WWDC saying we need these features. We can’t produce apps without them. Safaris got lots of bugs, please, can you get a bigger budget from your VPs? And we ended up, we kept pushing for that and then we just got no, we had made no progress. It basically got stonewalled in terms of features and functionality.
And then eventually we’re like, this isn’t working, we better form a group and then we did with a bunch of random engineers and we got together and we started talking to regulators basically to say look there’s this amazing potential for basically the entire app market and it’s being squeezed out by the gatekeepers. Could you look at intervening? And we started with the UK’s competitions and markets authority. And yeah, we started having meetings with them and then it kind of just snowballed from there.
Alex Moore
Why web apps are a threat to Apple:
The threat of web apps for them is enormous because what it means is that web apps are equal on all devices. And so if you build a web app, it’s going to work equally on Android, I mean, without these blockers it’s going to work equally on Android as well as iOS. And then that loses their competitive advantage. In addition, there’s no App Store fees. I think it’s around $24 billion a year in App Store fees at the moment. But obviously, if it was going via the web. They don’t collect any of that revenue. The other thing it would also allow, it would allow for other competitors. So if you think about other mobile phone ecosystems, there’s pretty much iOS and Android.
It’s not really possible for a third or a fourth or a fifth competitor to come into the market because you need that entire ecosystem set up. If web apps had been allowed to succeed and were the predominant form of apps, anybody could create a mobile device because then you’d have access to the library of apps that you need to be successful. And I’d argue that one of the reasons, say, Windows Phone didn’t take off was because they didn’t have the library of apps. And it was too much of an uphill battle to try and sell each of the developers. You got your iOS app, you got your Android app. Can you now build a Windows app as well?
Alex Moore
And why web apps could replace native apps:
And I just want to respond to what I hear often when I speak to developers who really are cynical about the eventual success of web apps. And they just say that native apps work better. And they sort of dismiss the PWAs as just not being realistic as much as they maybe ideologically agree with all the points that you’re making here. What is your response to folks who are skeptical of PWAs being able to function at the level of native apps?Kate Holterhoff
So the way I like to think about it is, at the end of the day, what you’re talking about in terms of the difference between native apps and web apps is, do you really think that web apps do not have the capability of painting to the screen 60 frames a second and doing the kinds of interactions that native apps can do? [...] So a great example is Photoshop. They ported the entirety of desktop Photoshop into a web browser. [...] If you can build a software as complicated as Photoshop in the web, then all of the other software, which is arguably significantly more simple, is also possible. [...] All the features and functionalities that we’re missing from native. Most of them are artificial. They’re just Apple’s, they’ve refused to provide an easy installation process and there’s no competition. So there’s nothing pushing them to invest significantly so that the lowest common denominator across the browsers is at a higher level.Alex Moore
]]>
Apple’s Interoperability Commitments to the UK’s CMA Promise Nothing2026-02-25T00:00:00Zhttps://open-web-advocacy.org/blog/apples-interoperability-commitments-to-the-uk-cma-promise-nothing/TL;DR: The UK's Competition and Markets Authority (CMA) has stated that developers need access to key iOS and iPadOS features to build innovative products and services, so UK consumers do not miss out. But Apple’s proposed interoperability commitments are far too weak to deliver that outcome. The CMA has the power to impose effective and enforceable interoperability obligations on mobile operating system gatekeepers under the UK's Digital Markets, Competition and Consumers Act 2024 (DMCCA), it just doesn’t appear to be using them.
We welcome views on Apple’s proposed commitments in relation to interoperable access requests. [...]
We welcome feedback from stakeholders on the approach as set out in this document, and on the respective proposed commitments provided by both Apple and Google individually, as well as on both approaches in the round. In particular, we welcome views on the metrics proposed to support in monitoring the delivery and effectiveness of the commitments. If you wish to provide such views, please get in touch at mobilesms@cma.gov.uk by 5pm on 3 March 2026. Should any aspects of your views be confidential, we ask that you also provide a non-confidential version of your views alongside.
CMA - Proposed Commitments - Call for Evidence (emphasis added)
The CMA has invited stakeholders to submit views on Apple’s proposed commitments. Because API access is essential to a competitive and fair mobile ecosystem, we encourage non-profits, developers, businesses that operate in the UK, and UK consumers to share their perspectives.
In particular, we ask respondents to address:
Whether a general interoperability requirement should be imposed on Apple and/or Google in relation to their mobile operating systems?
Whether Apple’s proposed commitments are likely to deliver fair and effective API access for businesses operating in the UK, and whether they would end Apple’s self-preferencing of APIs?
Any personal experiences where APIs or equivalent platform functionality were denied or made unavailable to third-parties.
Whether an interoperability requirement of this kind would lead to greater growth and innovation in the UK?
Apple claims it's built a walled garden, but they won't let you leave. That's not a walled garden, it's a walled prison. Interoperability gives users the keys they need to come and go as they please.
Cory Doctorow
In late 2025, OWA arranged a meeting between the CMA, sci-fi author and world-renowned expert on interoperability Cory Doctorow, Y Combinator head of policy Luther Lowe, global policy counsel at the Coalition for App Fairness Gene Burrus, and ourselves. The purpose was to explain why adding a broad interoperability requirement, similar to Article 6(7) of the EU’s Digital Markets Act (DMA), to Apple and Google’s code of conduct is essential for fair and effective competition on mobile operating systems. We were concerned this requirement appeared to be missing from the recent SMS (Strategic Market Status) investigation.
Furthermore, it is important that developers have interoperable access to key functionality in Apple’s iOS and iPadOS. Without the ability to access these enabling functions, UK developers cannot create the full range of innovative products and services that they would do otherwise, and UK consumers miss out as a result.
CMA - Proposed Commitments - Call for Evidence (emphasis added)
We consider commitments could prove a swift, effective and proportionate way of addressing these specific concerns and we have worked with Apple and Google to interrogate and further develop their proposals. Our goal is to deliver meaningful outcomes to UK consumers and businesses, and we seek to deliver these outcomes in the most effective and efficient way for the specific circumstances, using the full range of tools available to us.CMA - Proposed Commitments - Call for Evidence (emphasis added)
Apple has committed to providing a feedback channel for developers to make interoperability requests. Apple has committed to publicly publishing some annual statistics on this process and a statement that it is abiding by these commitments. Apple has also committed bi-annually reporting more detailed data on the request system to the CMA.
This all sounds great, until you dig into the details, and at which point multiple problems that invalidate the whole proposal become apparent.
Today’s announcement is unfortunately a gift to Apple and Google. Allowing dominant gatekeepers to set the terms of their own restraint— after years of abusing market power and dodging enforcement, including a US contempt finding against Apple — will not deliver real competition.
Coalition for App Fairness (emphasis added)
Given the highly dubious track record of these tech giants, we would question whether these voluntary commitments are really worth the paper they are printed on.
News Media Association (emphasis added)
Four years on from the publication of the mobile ecosystems market study report, the CMA isn’t actually proposing any formal conduct requirements at all. They are proposing to accept non-binding commitments from Google and Apple that they will run a fairer app review process and be fairer in how they rank apps in the app stores. Oh, and Apple is promising to consider interoperability requests fairly and objectively 😉 🤞
[...]
This is disappointing. It’s an outcome so weak that the possibility is not even mentioned in the CMA’s 220-page guidance document published in December.
It’s also deeply misleading for the CMA to describe these promises as “commitments”, which is a word with actual legal meaning (and legal enforceability) in the pro-competitive interventions process and in competition enforcement cases under the Competition Act.
Tom Smith Former Legal Director at the CMA (emphasis added)
Five years after the CMA began investigating competition in the mobile ecosystem, this feels pretty weak to me. [...]
Quite why the CMA does not aim to create a default interoperability requirement is beyond my small brain to fathom. But even within this very lightweight framing, Apple’s commitments are hugely underwhelming [...] Hang on: Apple can deny a competitor access to an existing iOS service, if it decides there won’t be enough user uptake? Then why did it implement it in the first place? If access to a feature, that Apple has already implemented and uses in its own products, doesn’t align “with Apple’s platform priorities”, why did they add that feature to their platform?
Bruce Lawson (emphasis added)
The first and biggest problem is that the proposal is layered with multiple ways of Apple not having to share any API it doesn’t want to, regardless of the circumstances. Nowhere in the proposed commitment does Apple commit to sharing the operating system features and functionalities used by its own apps, services and ancillary devices. It doesn’t even commit to this subject to security, privacy or other conditions.
Just in case there was any doubt, Apple states:
Receiving a request through the feedback channel will not create any obligation or expectation that Apple will commit to building a specific requested feature (or, if Apple does choose to build a requested feature, whether or not it will make it available to the Eligible Developer or developers generally for a fee), which will remain at Apple’s discretion in line with its commercial strategy and priorities.
Apple Proposed Commitments (emphasis added)
Apple’s “commitment” boils down to this: Apple will decide, case by case, what access it grants and to whom. It reserves the right to keep certain APIs or higher quality versions of APIs for its own apps, devices, and services. In effect, Apple is promising only that it will do what it wants.
Apple also concedes it may withhold API access where granting it could undermine its commercial strategy. Put plainly: if enabling an API would help someone compete with Apple, that alone can be a reason not to provide it.
Eligibility to make these interoperability requests is limited to “developers [...] whose account membership with the Developer Program is registered in the UK”. This does not cover a significant majority of the apps and devices that are available to UK users via Apple’s app store. Many apps and devices that UK users rely on are developed by entities whose developer program is registered outside the UK. Apple needs to expand this to all developers and vendors that provide apps, services, or connected devices that work with iOS devices used by UK users, regardless of where the developer account is registered.
Receiving a request through the feedback channel will not create any obligation or expectation that Apple will commit to building a specific requested feature (or, if Apple does choose to build a requested feature, whether or not it will make it available to the Eligible Developer or developers generally for a fee), which will remain at Apple’s discretion in line with its commercial strategy and priorities.
Apple Proposed Commitments (emphasis added)
Apple has inserted a clause allowing it to charge for API access. This could be a powerful mechanism for Apple to block fair competition with its own apps. We argue here in extensive detail why API access should be free, something that the DMA already mandates.
Imagine if Microsoft charged developers for access to basic Windows APIs such as Bluetooth, so that an app had to pay Microsoft simply to use system functionality on devices that users already own. That would be an obvious barrier to competition and would clearly be ridiculous, but is the very thing that Apple is proposing here.
Apple will endeavour to provide developers with an update on the status of their requests within four weeks of receiving them. [...]
Apple will inform developers of the outcome of its review of their requests, and the associated reasoning for this outcome. [...]
Apple will inform developers generally about forthcoming changes to iOS and iPadOS, including those resulting from eligible requests, in its beta releases.
Apple Proposed Commitments
Apple states that it will “endeavour” to provide developers with an update on the status of their requests within four weeks, inform them of the outcome and reasoning, and communicate forthcoming platform changes through beta releases.
These are weak, non-binding commitments. Apple is not required to meet the four-week timeframe, only to attempt to do so. Developers are given no certainty about whether a request has been approved, when any approved changes will be implemented, or even whether implementation will occur at all. The commitments also impose no obligation on Apple to publish in advance what changes it plans to make in response to a successful request, nor to provide a concrete delivery timeline.
Given that persistent delays were a primary reason the European Commission initiated specification proceedings against Apple, deadlines are an important requirement in any effective interoperability obligation.
Apple could fully comply with this proposal while effectively changing nothing.
The core problem is that Apple could simply deny every request for access to key APIs from companies that compete with Apple’s own apps, accessories, and services, and still claim it is following the rules. In practice, this turns the proposal into a blank cheque that lets Apple avoid sharing APIs indefinitely, with no real consequences. The CMA’s interventions are meant to drive real change but they risk failing in their aim of ensuring interoperable access to essential iOS and iPadOS functionality, leaving UK developers unable to build the full range of innovative products and services and UK consumers worse off through reduced choice and weaker competition.
That makes it very hard to believe this entirely voluntary proposal with no hard requirements to share anything will deliver the outcomes the CMA says it wants.
Given the powers available under the DMCCA and the SMS designations of Apple and Google, the CMA can do far better than this. Endorsing this proposal would effectively give regulatory cover to a process that offers no meaningful benefit for UK businesses or consumers. Worse, it could delay the introduction of measures that would actually be effective.
Interoperability is the foundation of effective competition in digital markets. On mobile platforms, access to operating system features and application programming interfaces (APIs) determines what third-party developers can build, how well their products perform, and whether they can compete on equal terms with the platform owner’s own apps and services. Without meaningful interoperability, competition is constrained not by innovation or consumer preference, but by technical restrictions imposed by the gatekeeper.
Apple’s control over iOS gives it the power to decide which capabilities are available to others and under what conditions. As the Competition and Markets Authority has previously observed:
Apple’s control over iOS also allows it to determine the ‘rules of the game’ by determining which APIs are made available to third parties and on what terms. This is important as the functionality of native apps and browser engines on a mobile device is determined by which APIs they can access
CMA - Mobile Ecosystems Market Study (emphasis added)
Interoperability also plays a crucial role in reducing user lock-in. When devices, apps, and services work only within a single ecosystem, consumers face significant costs when attempting to switch platforms. Data may not transfer easily, accessories may become unusable, and familiar services may lack equivalent functionality elsewhere.
This lock-in weakens competitive pressure on the dominant firm. If users cannot realistically leave, the firm has less incentive to improve products, lower prices, or respect consumer preferences. Developers likewise become dependent on the platform for distribution and functionality, making them vulnerable to unilateral changes in rules, fees, or access.
Interoperability via middleware would reduce lock-in for Apple’s devices. Lock-in is a clear reason for Apple to block interoperability, as can be seen in this email exchange where Apple executives dismiss the idea of bringing iMessage to Android.
The #1 most difficult [reason] to leave the Apple universe app is iMessage ... iMessage amounts to serious lock-inUnnamed Apple Employee (emphasis added)
iMessage on Android would simply serve to remove [an] obstacle to iPhone families giving their kids Android phones ... moving iMessage to Android will hurt us more than help us, this email illustrates why.
Craig Federighi - Apple's Senior Vice President of Software Engineering (emphasis added)
Or this now infamous exchange between Tim Cook and Vox Media's LiQuan Hunt:
Not to make it personal, but I can't send my mom certain videos, or she can't send me certain videos
Vox Media's LiQuan Hunt
Apple will often claim when they reserve a feature for itself or limit interoperability that the primary purpose is not to increase lock-in or Apple’s own profits, but rather to protect its own users.
Tie all of our products together, so we further lock customers into our ecosystem Steve Jobs (emphasis added)
I think this is all pretty simple, [Apple's] iBooks is going to be the only bookstore on iOS devices. We need to hold our heads high. One can read books bought elsewhere, just not buy/rent/subscribe from iOS without paying us, which we acknowledge is prohibitive for many things.
Steve Jobs (emphasis added)
I just watched a new Amazon Kindle app ad on TV.
It starts with a woman using an iPhone and buying and reading books with the Kindle app. The woman then switches to an Android phone and still can read all her books. While the primary message is that there are Kindle apps on lots of mobile devices, the secondary message that can’t be missed is that it is easy to switch from iPhone to Android.
This is now being viewed increasingly sceptically by both regulators around the world and the general public.
That is not to say that there are no security issues related to sharing APIs, but rather that Apple should be restricted to only strictly necessary security measures which Apple can prove are justified and proportionate.
As the DOJ noted in their complaint against Apple:
In the end, Apple deploys privacy and security justifications as an elastic shield that can stretch or contract to serve Apple’s financial and business interests.
DOJ Complaint against Apple
In many ways, history is repeating itself. In the late 1990s, Microsoft grew increasingly concerned that middleware could erode the Windows “applications barrier to entry”. If developers could target middleware APIs instead of Windows APIs, they could more easily port applications across operating systems, weakening the lock-in that made Windows so hard to displace.
Middleware technologies, as previously noted, have the potential to weaken the applications barrier to entry. Microsoft was apprehensive that the APIs exposed by middleware technologies would attract so much developer interest, and would become so numerous and varied, that there would arise a substantial and growing number of full-featured applications that relied largely, or even wholly, on middleware APIs. The applications relying largely on middleware APIs would potentially be relatively easy to port from one operating system to another. The applications relying exclusively on middleware APIs would run, as written, on any operating system hosting the requisite middleware. So the more popular middleware became and the more APIs it exposed, the more the positive feedback loop that sustains the applications barrier to entry would dissipate. Microsoft was concerned with middleware as a category of software; each type of middleware contributed to the threat posed by the entire category. At the same time, Microsoft focused its antipathy on two incarnations of middleware that, working together, had the potential to weaken the applications barrier severely without the assistance of any other middleware. These were Netscape's Web browser and Sun's implementation of the Java technologies.
US vs Microsoft - Finding of Fact (emphasis added)
One method of preventing third-party middleware from enabling this was simply to deny them access to the APIs they needed:
Microsoft's senior executives understood that if they could prevent this version of Navigator from presenting alternatives to the Internet-related APIs in Windows 95, the technologies branded as Navigator would cease to present an alternative platform to developers.
US vs Microsoft - Finding of Fact (emphasis added)
In 1998, the DOJ filed a suit against Microsoft alleging that the company had unlawfully maintained its monopoly by suppressing competition in web browsers on Windows. Central to the case were both contractual restrictions imposed on PC manufacturers and technical measures that made it difficult for users to remove Internet Explorer or use other programs such as Netscape and Java.
The final judgement imposed an affirmative interoperability obligation: Microsoft had to disclose the Windows interfaces that its own middleware relied on so that third-party developers could build competing middleware that interoperated with Windows on comparable terms.
Microsoft shall disclose [...] for the sole purpose of interoperating with a Windows Operating System Product [...] the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product. [...] In the case of a new major version of Microsoft Middleware, the disclosures required by this Section III.D shall occur no later than the last major beta test release of that Microsoft Middleware. In the case of a new version of a Windows Operating System Product, the obligations imposed by this Section III.D shall occur in a Timely Manner.US vs Microsoft - Final Judgement (emphasis added)
Microsoft also faced unusually high stakes during the litigation. In 2000, the district court ordered a breakup remedy, a decision that was later overturned on appeal, but it made the consequences of continued non-compliance genuinely alarming to Microsoft. It was under this backdrop that Microsoft sincerely complied with the requirements.
Gene Burrus who spent 15 years at Microsoft, managing antitrust compliance with American and European orders and decrees had this to say:
With oversight from the DOJ, the District Court Judge, and the European Commission, Microsoft did not and could not consider compliance with the interoperability requirements to be optional or something they might take under consideration if asked. They were mandatory and therefore something the broad ecosystem could rely upon.
Gene Burrus
This helped usher in significant competition in music hardware and software from Apple, whose success was used to launch the iPhone:
For example, the iPod did not achieve widespread adoption until Apple developed a crossplatform version of the iPod and iTunes for Microsoft’s Windows operating system, at the time the dominant operating system for personal computers. In the absence of the consent decree in United States v. Microsoft, it would have been more difficult for Apple to achieve this success and ultimately launch the iPhone.DOJ Complaint against Apple (emphasis added)
The iPod illustrates how yesterday’s antitrust enforced interoperability can translate into tomorrow’s innovation and growth. Apple’s breakthrough consumer product did not become a mass market phenomenon until iTunes and the iPod worked seamlessly on Windows. The iPod's success then laid the groundwork for the eventual triumph of the iPhone.
Interoperability obligations also made it far more feasible for third-party browsers such as Firefox and later Chrome to succeed on Windows, rather than leaving the field to an increasingly stagnant Internet Explorer. This shift was critical to allowing the web to compete on the desktop, where it now accounts for roughly 70% of user time.
The irony is that Apple, once a beneficiary of an ecosystem where the dominant platform was pushed to open up, is now large enough to fear the same sort of openness. Interoperability mandates are easy to celebrate when they pry open someone else’s gate, and much harder to embrace when your own platform becomes the one that must be easier to build on, easier to leave, and less able to treat integration as a moat.
# Small businesses are the drivers of growth and innovation
Last year there were calls for the Competition and Markets Authority (CMA) to be “more pro-business”, which appeared to suggest that the UK should ease up on enforcing rules against some of the world’s most powerful companies. Former Chancellor Jeremy Hunt went so far as to publicly admonish the CMA, urging regulators to “understand their wider responsibilities for economic growth”.
The move follows a meeting between CMA Chief Executive Sarah Cardell and other regulators with British Finance Minister Rachel Reeves to deliver ideas on how to stimulate growth. Regulators were told to “tear down the barriers hindering business and refocus their efforts on promoting growth.
Ryan Browne - CNBC
But this framing is backwards. Weakening enforcement of competition rules does not drive economic growth, quite the opposite. Economists widely agree that tolerating anti-competitive behaviour entrenches dominant firms, stifles innovation, and ultimately harms consumers and startups alike. It also risks conflating the continued expansion of already powerful corporations with genuine economic growth. The CMA’s role is not to enable dominant firms to use anti-competitive conduct to grow and further entrench their market position, but to maintain competitive conditions so that new entrants and challengers can succeed, driving innovation, productivity, and broader benefits across the economy.
It seems like the UK now welcomes monopolies provided they have an investment story. There’s something really topsy-turvy about this.
Former CMA Regulator
This matters as competition is the primary driver of growth and innovation. Companies that, due to anti-competitive behaviour or some structural reason, do not face sufficient competition, are likely to raise prices and minimize expenditure beyond what is necessary to retain existing customers.
Consumers, competition, and the competitive process—not Apple alone—should decide what options consumers should have. And competition, not Apple’s self-interested business strategies, should be the catalyst for innovation essential to our daily lives, not only in the smartphone market but in closely related industries like personal entertainment, automotive infotainment, and even more innovations that have not yet been imagined. Competition is what will ensure that Apple’s conduct and business decisions do not thwart the next Apple.DOJ Complaint against Apple (emphasis added)
The idea that easing pressure on gatekeepers will help startups is fundamentally flawed. In reality, failing to curb the control dominant firms exert over their platforms, especially through blocking competition, actively harms smaller players and undermines the interests of the UK public. Interoperability rules will help startups not hurt them:
The DMA's interoperability and fairness rules were designed to pry open closed platforms and give smaller companies a fighting chance. [...] Big Tech lobbyists portray the DMA as anti-American. In reality, the DMA's goals align with American ideals of fair competition. This isn't Europe versus America; it's open markets versus closed ones.
Luther Lowe - Y Combinator - Head of Public Policy (emphasis added)
Start-ups are a key part of the innovation economy, it is the gatekeepers who often lag in innovation. The CMA most recent report highlighted that Apple can and does profitably forego innovation without fear of losing customers to competitors with this quote:
Apple’s vice president of iPhone marketing who explained in February 2020: ‘In looking at it with hindsight, I think going forward we need to set a stake in the ground for what features we think are ‘good enough’ for the consumer. I would argue were [sic] already doing *more* than what would have been good enough.’ After identifying old features that ‘would have been good enough today if we hadn’t introduced [updated features] already’, she explained, ‘anything new and especially expensive needs to be rigorously challenged before it’s allowed into the consumer phone.’
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
We do not expect that commitments will be appropriate to address concerns following a Strategic Market Status (SMS) designation in all circumstances. For example, we are unlikely to pursue commitments where there is significant divergence between us and a firm on what we are looking to achieve, where firms have little incentive to change their conduct, where compliance is difficult to determine, observe or monitor, where measures can be easily circumvented, or where an SMS firm’s historical conduct does not give us confidence it will work constructively with us.
CMA - Proposed Commitments - Call for Evidence (emphasis added)
The CMA has been clear that commitments will not be suitable in every SMS case, especially where remedies are easy to circumvent, hard to monitor, or where the firm’s past conduct suggests it will not engage constructively.
In Apple’s case, the measures they are proposing “can be easily circumvented”, Apple’s historical conduct both globally and with the DMA "does not give us confidence it will work constructively with [[the CMA]]” and Apple not only has “little incentive to change their conduct” but has vast incentives to preserve the status quo.
Our recommendation is therefore that the CMA impose a clear, enforceable requirement on Apple to provide, free of charge, access to all APIs and operating system features needed for third parties to interoperate with iOS. This obligation should be subject only to security measures that are strictly necessary and proportionate to protect the integrity of the operating system. The burden of proving that any restriction is necessary and proportionate should rest entirely with Apple. Eligible third parties should include all businesses and developers that provide apps, services, and ancillary devices to UK consumers.
We further recommend that the CMA closely examine the EU’s experience under the DMA with comparable interoperability obligations, including the extent of Apple’s compliance and the practical lessons on enforcement. In particular, the CMA should consider what additional safeguards are needed around deadlines, API stability, transparency, and monitoring so that the requirement is effective in practice.
Key requirements should include:
A clear process with defined steps.
Binding deadlines for Apple at each step.
The ability for developers to make requests public, with public responses where the requesting developer wishes.
Upfront publication of any security measures, with Apple required to justify them publicly as strictly necessary and proportionate.
No presumption that Apple’s security is inherently more secure than third parties.
APIs provided free of charge.
An independent appeals process.
Finally, the CMA should build in a structured review and update mechanism from the outset, on the assumption that new circumvention strategies will emerge and will need to be addressed quickly.
Without these measures, it is, in our view, highly likely that the CMA’s stated objective to grant developers interoperable access to key functionality in Apple’s iOS and iPadOS to create innovative products will fail.
]]>
How Apple’s Key Tactic Could Prevent Japan’s Smartphone Act from Improving Browser Competition2026-01-06T00:00:00Zhttps://open-web-advocacy.org/blog/how_apples_key_tactic_could_prevent_japans_smartphone_act_from_improving_browser_competition/TL;DR: Japan’s new Smartphone act requires that Apple allow browser vendors to use their own engines in Japan. However, Apple looks set to use the same tactic it has used in the EU to avoid complying with the same provision of the Digital Markets Act for the last twenty-one months. Namely, Apple demands that browser vendors lose all their existing Japanese users and produce a brand new browser, rather than simply updating their existing users. Apple will also not allow browser vendors to use their own engine on iPadOS and other iOS variants.
As a quick background to new readers, we (Open Web Advocacy) are a non-profit dedicated to improving browser and web app competition on all operating systems. We have engaged with multiple regulators including in the EU, UK, Japan, Australia and the United States.
Banning browser engines is prohibited, as are actions “preventing” their adoption.
There must be functionally equivalent API access for 3rd parties, subject to justifiable measures.
It must be easy to change the default settings of the operating system.
A choice screen for browsers must be provided “promptly after the first activation”.
The act came into full effect on the 18th of December 2025.
We’d like to extend our gratitude to the extensive work over many years by the HDMC (Headquarters for Digital Market Competition), JFTC (Japan Fair Trade Commission) and others in improving browser, browser engine and web app competition.
For the last 16 years, Apple has banned browser vendors from porting their own browser engines to iOS. They have done this via App Store Rule 2.5.6:
2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript.
WebKit is the engine that powers Safari, and several smaller browsers on Linux and macOS.
In practice, 2.5.6 is a requirement that on iOS, browsers from Google, Microsoft, Mozilla, Samsung, Vivaldi, Brave, Opera and others cannot use their own engines the way they do everywhere else. These engines take hundreds of thousands of engineer hours to develop, and are excluded from Apple’s most successful consumer operating system. Competing browser vendors are only allowed to produce shells around a very specific, unaltered version of Safari’s WebView; a component whose features Apple dictates.
Apple has a browser monopoly on iOS, which is something Microsoft was never able to achieve with IE Scott Gilbertson - The Register (emphasis added)
All of this is compounded by yet another Apple policy: no third-party browser engines. You can install apps like Chrome, Firefox, Brave, DuckDuckGo, and others on the iPhone — but fundamentally they’re all just skins on top of Apple’s WebKit engine. That means that Apple’s decisions on what web features to support on Safari are final. If Apple were to find a way to be comfortable letting competing web browsers run their own browser engines, a lot of this tension would dissipate.* Dieter Bohn and Tom Warren - The Verge (emphasis added)
So it’s not just one browser that falls behind. It’s all browsers on iOS. The whole web on iOS falls behind. And iOS has become so important that the entire web platform is being held back as a result.Niels Leenheer - HTML5test (emphasis added)
…because WebKit has literally zero competition on iOS, because Apple doesn’t allow competition, the incentive to make Safari better is much lighter than it could (should) be.
Chris Coyier - CSS Tricks (emphasis added)
What Gruber conveniently failed to mention is that Apple’s banning of third-party browser engines on iOS is repressing innovation in web apps. Richard MacManus - NewsStack (emphasis added)
No other major operating system imposes such a ban. Microsoft Windows, Android, Linux, and Apple’s own macOS all enable browser vendors to choose and modify their own engines. All rival iOS browsers are essentially Safari under the hood. This browser ban is unique to Apple’s iOS.
On Apple Mobile Devices, all mobile browsers are required to use Apple’s WebKit browser engine, as specified in Apple’s App Store Review guidelines. Apple therefore does not face competition from rival mobile browser engines within its Mobile Ecosystem. This position will not change unless Apple lifts its prohibition on the use of alternative browser engines within its Mobile Ecosystem.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Japan’s new law directly prohibits Apple’s behaviour, so will this be enough to solve the issue for Japanese users? That is, will Japanese users be allowed to enjoy the benefits of genuine browser and web app competition?
Unfortunately the answer appears to be no, due to the precise method Apple is complying with the law. Apple has adopted the same tactic that they used in the EU where they have been required to allow browser vendors to use their own engines for 21 months, despite this not a single browser vendor has been able to port their engine to iOS.
# EU's Digital Markets Act - Apple's Circumvention
Apple has been required to allow browser vendors to use their own engines on iOS within the EU since March 7th 2024. This is under the EU’s Digital Markets Act:
The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services.Article 5(7) - Digital Markets Act (emphasis added)
Both Google and Mozilla began porting their respective browser engines, Blink and Gecko, to iOS. Other browser vendors are dependent on these ports to bring their own engines to their browsers on iOS, as their products are typically soft forks (copies with modifications) of Blink or Gecko.
However there were significant issues with Apple’s contract and technical restrictions that made porting browser engines to iOS “as painful as possible” for browser vendors.
Apple’s proposals fail to give consumers viable choices by making it as painful as possible for others to provide competitive alternatives to Safari [...] This is another example of Apple creating barriers to prevent true browser competition on iOS.
Damiano DeMonte - Mozilla (emphasis added)
Many of Apple’s barriers rely on vague security and privacy grounds for which Apple has published no detailed technical justification for both their necessity and proportionality. As the US’s Department of Justice wrote in their complaint:
In the end, Apple deploys privacy and security justifications as an elastic shield that can stretch or contract to serve Apple’s financial and business interests.
DOJ Complaint against Apple (emphasis added)
At the DMA workshop in 2025, we directly raised with Apple the primary blocker preventing third-party browser engines from shipping on iOS. Apple claimed that vendors like Google and Mozilla have “everything they need” to ship a browser engine in the EU and simply "have chosen not to do so”.
We recognize under the DMA that we've been forced to change. And we have created a program that keeps security and privacy in mind, that keeps the integrity of the operating system in mind, and allows third parties to bring their browser engine, Google, Mozilla, to the platform. And for whatever reason, they have chosen not to do so.Kyle Andeer - Apple - Vice President Apple Legal (emphasis added)
Apple has been fully aware of these barriers since at least June 2024, when we covered them in exhaustive detail. Multiple browser vendors have also discussed these same issues with Apple directly. The suggestion that Apple is unaware of the problems is not just ridiculous, it’s demonstrably false. Apple knows exactly what the issues are. It is simply refusing to address them.
The most critical barriers that continue to block third-party engines on iOS include:
Loss of existing EU users: Apple forces browser vendors to create entirely new apps to use their own engine, meaning they must abandon all current EU users and start from scratch.
Web developer testing: Apple allows native app developers outside the EU to test EU-specific functionality, but offers no equivalent for web developers to test their software using third-party browser engines on iOS. Apple stated during the workshop to expect updates here but has provided no details since.
No updates on long trips outside EU: Apple has not confirmed they will not disable browser updates (including security patches) if an EU user travels outside the EU for more than 30 days. This, far from being a security measure, actively lowers users' security by depriving them of security updates.
Hostile legal terms: The contractual conditions Apple imposes are harsh, one-sided, and incompatible with the DMA’s requirement that rules for API access can only be strictly necessary, proportionate security measures.
Dual engine support: Apple now allows browsers to include both WebKit and their own engine in the same app. This is essential for introducing a new engine to the platform while maintaining fallback compatibility.
However, the most critical barrier remains firmly in place: Apple still forces browser vendors to abandon all their existing EU users if they want to ship a non-WebKit engine. This single requirement destroys the business case for porting an engine to iOS. Building and maintaining a full browser engine is a major undertaking. Requiring vendors to start from scratch in one region (even a region as large as the EU), with zero users, makes the investment commercially nonviable.
Instead, transaction and overhead costs for developers will be higher, rather than lower, since they must develop a version of their apps for the EU and another for the rest of the world. On top of that, if and when they exercise the possibility to, for instance, incorporate their own browser engines into their browsers (they formerly worked on Apple's proprietary WebKit), they must submit a separate binary to Apple for its approval. What does that mean exactly? That developers must ship a new version of their app to its customers, and 'reacquire' them from zero.Alba Ribera Martínez - Lecturer in Competition Law and Digital Markets (emphasis added)
At face value, Apple appears to have complied with the letter of Article 5(7). It technically allows third-party engines, but only under technical platform constraints and contractual conditions that render porting non-viable.
The gatekeeper shall ensure and demonstrate compliance with the obligations laid down in Articles 5, 6 and 7 of this Regulation. The measures implemented by the gatekeeper to ensure compliance with those Articles shall be effective in achieving the objectives of this Regulation and of the relevant obligation.
Article 8(1) - Digital Markets Act (emphasis added)
The gatekeeper shall not engage in any behaviour that undermines effective compliance with the obligations of Articles 5, 6 and 7 regardless of whether that behaviour is of a contractual, commercial or technical nature, or of any other nature, or consists in the use of behavioural techniques or interface design.
Article 13(4) - Digital Markets Act (emphasis added)
These two articles clarify that it is not enough for Apple to simply allow alternative engines in theory. The measures must be effective in achieving the article’s objectives, and Apple must not undermine those objectives by technical or contractual means.
The intent of this provision is laid out clearly in the recitals of the DMA:
In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users.
Recital 43 - Digital Markets Act (emphasis added)
In other words, Apple should not be in a position to dictate what features, performance, or standards in competing browsers and the web apps they power. That is, the intent is to guarantee that browser vendors have the freedom to implement their own engines, thereby removing Apple’s ability to control the performance, features, and standards of competing browsers and the web apps built on them.
Twenty-one months since the DMA came into force, no browser vendor has successfully ported a competing engine to iOS. The financial, technical, and contractual barriers Apple has put in place remain insurmountable. These restrictions are not grounded in strictly necessary or proportionate security justifications.
This is not what effective compliance looks like. Article 5(7)’s goals, enabling engine-level competition and freeing web apps from Apple’s ceiling on functionality and stability, have not been met. Under Article 8(1) and Article 13(4), that makes Apple non-compliant.
The contract for Japan is almost identical to the one for the EU. Apple however appears intent on making browser vendors apply for and sign a contract for each and every region in which they are forced to allow browser competition.
Thankfully, Apple is not forcing browser vendors to have an entirely separate browser for each region. Browser vendors may use the same browser in the EU as they use for Japan:
Be distributed solely on iOS in Japan (except for any other jurisdiction or Apple platform expressly permitted by Apple under the Developer Agreement (including any addenda) for which You have likewise obtained a corresponding entitlement profile);
Web Browser Engine Entitlement Addendum for Apps in Japan (emphasis added)
Be distributed solely on iOS and/or iPadOS in the European Union (except for any other jurisdiction or Apple platform expressly permitted by Apple under the Developer Agreement (including any addenda) for which You have likewise obtained a corresponding entitlement profile);
Web Browser Engine Entitlement Addendum for Apps in EU (emphasis added)
It also appears that Apple will not be allowing browser vendors to use their own engine on iPadOS (a subvariant of iOS with minor changes due to larger screens and an optional Apple pencil).
Apple has also firmly kept the key restraint in place. Browser vendors wishing to upgrade their Japanese users to their own engine will be unable to do so. Instead they must submit a brand new browser and restart from zero users.
This is the same tactic Apple has used to hold back browser competition in the EU for the last twenty-one months, and unfortunately if they are allowed to do it in Japan, it will be successful in preventing this law from allowing effective browser competition in Japan.
By prohibiting actions that prevent the adoption of alternative browser engines as components of individual software, this Act aims to enhance competition in individual software by allowing app providers to offer diverse browser engine choices. [...]
(B) Actions that "Prevent" the Adoption of Alternative Browser Engines
Actions that prevent the adoption of alternative browser engines refer to conduct that creates a high likelihood of making it difficult for individual app providers to incorporate such engines into their individual software when providing it via a designated provider’s application store. Such actions may include: imposing unreasonable technical restrictions on individual app providers while allowing them to adopt alternative browser engines, placing excessive financial burdens on individual app providers for adopting alternative browser engines, and steering smartphone users away from using individual software that incorporates alternative browser engines.
The determination of whether a designated provider's action constitutes "preventing" the adoption of alternative browser engines does not require that it be completely impossible for individual app providers to adopt alternative browser engines. Instead, the determination is made based on the degree of likelihood that such a result will occur.
The degree of likelihood of causing practical difficulty in adopting alternative browser engines is assessed comprehensively based on various factors, including: the nature of the designated provider’s actions, the duration of such actions, the impact on individual app providers seeking to adopt alternative browser engines, and the extent of impact on smartphone users utilizing such individual software.
Mobile Software Competition Act Guidelines (emphasis added)
As in the EU, Japan has anticipated attempts at circumvention where browser vendors are nominally permitted to use their own engines but only under conditions that make doing so financially unviable and unlikely to deliver meaningful benefits to Japanese users or businesses.
The act prohibits actions that "prevent" the adoption of alternative browser engines. The Mobile Software Competition Act Guidelines define actions that "prevent" the adoption of alternative browser engines as conduct that creates a high likelihood of making it difficult for app providers to incorporate such engines when distributing software through a designated provider’s app store. These actions include imposing unreasonable technical restrictions, placing excessive financial burdens on app providers that seek to adopt alternative engines, and steering smartphone users away from software that uses those engines.
A finding of prevention does not require that adoption be completely impossible. Instead, it depends on the likelihood that the conduct will result in practical difficulty.
The requirement that browser vendors be unable to update their existing browsers to use their own engines, lose all their existing Japanese users and be required to submit a new browser which must require users from zero will prevent browser vendors from adopting their own engines.
The published guidelines would clearly apply to Apple’s conduct, which creates a high likelihood of making it difficult for app providers to incorporate alternative browser engines. In making a judgement on the likelihood of such prevention, one can also look at the EU, where Apple has implemented an equivalent solution and not a single browser vendor has successfully ported an independent browser engine under the DMA.
The primary fix is to reject Apple’s requirement that browser vendors are not allowed to upgrade their existing Japanese users to their own engine. Apple then has three plausible options to comply:
Apple could allow browsers to compete fairly with their own engines globally. This is the only option that would enable fair competition.
The JFTC can likely not compel such a global solution, but the resulting complexity arises solely from Apple’s choice to limit competition only to those regions where they are legally compelled to allow it.
Allow browser vendors to provide two signed binaries under one application (one bundle id).
These two binaries would be:
One - A signed binary which contains the real browser with its own engine to ship to Japan and other jurisdictions that mandate Apple allow browsers to be able to choose and modify their engine.
Two - A signed binary which contains the version of the browser which is forced to use Apple’s WKWebView which can be shipped in other jurisdictions.
The operating system would then choose which binary the end user receives based on region. This would allow all existing users to be updated to the new engine.
#Solution C - Global Dual Engine Binary with Toggle
Allow browser vendors to ship a single binary globally which contains both the browser vendor's own engine and the WKWebView version. For jurisdictions that haven’t yet forced Apple to allow competition, the browser would use the WKWebView, and for those who have, the browser would use the browser's own engine. Apple can indicate to the browser app whether they are allowed to use their own engine, and based on that the browser could then decide if they wish to use their own engine. Likely only a small technical change would be required for this solution to work. That is for Apple to provide some mechanism to let browser vendors detect whether they can use their engine or not, as legally required. Aside from that this would likely require no technical changes on Apple’s end, they would simply need to update their contracts to allow it.
An end to Apple’s ban on third-party browser engines on iOS would be profound. The first consequence is that Safari would come under intense pressure to compete. Given that Safari is Apple’s highest margin product, Apple will not abandon it. Its current budget is a minute fraction of the revenue it pulls in, doubling or tripling its budget would be the obvious response. We have already seen a significant increase in budget and activity in response to the threat of regulators allowing other browser vendors to use their own engines.
More powerful browsers on iOS would be available to power web apps. Features such as install prompts, working and feature complete push notifications and higher stability would be game changing for web apps viability. Suddenly, developers would have a viable and interoperable alternative to Apple’s app store. The web could become as dominant on mobile as it is on desktop.
For everything else there is always the open Internet.If the App Store model and guidelines or alternative distribution and Notarization for iOS and iPadOS apps are not best for your app or business idea that’s okay, we provide Safari for a great web experience too. Apple App Store Rules (emphasis added)
This change will make web apps a genuine and powerful alternative; until then, Apple’s pretence that “there is always the open internet” functions mainly to mask their app store’s monopolistic dominance.
While legal experts expect the EU to challenge Apple's insincere compliance with the DMA, developers should take this opportunity to rethink their native app serfdom. They should push web apps to their limits and then demand further platform improvement. The web doesn't require commission payments, technology fees based on usage, or permission from platform rentseekers. The web can set the iPhone free, even if Apple won't.Thomas Claburn - The Register (emphasis added)
We would like to thank both the HDMC and JFTC for their tireless work. We are deeply concerned that Apple may attempt to replicate in Japan the same tactics it used in the EU, tactics that have undermined the Digital Markets Act’s goal of allowing effective competition between browser engines.
We ask that the JFTC not allow Apple to prevent browser vendors from upgrading their existing Japanese users from using their own engine. We ask that the JFTC ensures that the Smartphone Act is successful in goals with respect to browser engines and is not undermined by such tactics. We also ask that the JFTC considers imposing the same requirement on iPadOS and other iOS variants for interoperability purposes.
]]>
Open Web Advocacy 2025 in Review2026-01-05T00:00:00Zhttps://open-web-advocacy.org/blog/owa-2025-review/TL;DR: A lot happened in 2025 for browsers and web apps with new investigations, laws, and court cases across the EU, Japan, the US, Australia, and the UK. OWA continues to play a key role in pushing for fair and effective browser and web app competition on all platforms. Apple is now barred from blocking third-party browser engines on iOS in 28 countries, soon likely 30. However, it continues to resist real competition. Learn what is happening worldwide and how you can help!
As the calendar turns and we step into 2026, it's a perfect moment to reflect on 2025’s developments, achievements, and what lies ahead regarding regulators, browsers, and web applications. The momentum we have built over the past year did not happen by accident. It was shaped by persistence, collaboration, and a shared belief that the open web deserves to be allowed to compete fairly.
Looking back on 2025, the pace was relentless. Through it all, meaningful progress was made, not in theory, but in real outcomes that strengthen the ecosystem we all depend on. While it is a long road to fair and effective browser and web app competition, change is happening.
The lesson from 2025 is clear. When those who love what makes the web amazing come together, we can achieve wonders!
We would like to thank everyone who contributed their time or financial support to this cause. None of this would be possible without you.
If you love what we're doing and would like to support our work, please consider
making a donation.
OWA is a registered not-for-profit fighting for the Web against heavily financed gatekeepers
to ensure the future of Browser competition and Web Apps
OWA has so much more work to do advocating for the web all over the globe. We will always need your support, and you can do that in many ways:
Open Web Advocacy is a not-for-profit whose mission is to educate regulators, policymakers, businesses, and the public on the intricate technical details they need to understand both the major anti-competitive issues affecting browsers and web apps and the promise of a more open and competitive future enabled by capable web apps.
We do this by talking to regulators all over the world including in the EU, the UK, Japan, the US and Australia. We also produce educational content and talks with the aim of explaining key issues that are holding back the mobile web and how to fix them.
We believe that as a direct result of our work the following achievements have been made:
The Web could be an outstanding mobile application platform. It already dominates on desktop, where more than 70 percent of user time is powered by web technologies. It offers so many innate advantages: build once with a single code base, run smoothly on every operating system, enjoy strong security, high performance, broad interoperability, and freedom from gatekeepers. No fees from operating system gatekeepers. No app store rules. No app review. Consumers win through higher quality, more secure, more private and cheaper software. Developers win by having a direct relationship with their customers free from gatekeeper fees, censorship and control.
Yet this future is being prevented by anti-competitive practices. If we work together, we can change that and create a world where the Web can finally compete on equal terms across all platforms
In the EU, the landmark Digital Markets Act came into force on 7th March 2024.
It contained 3 incredibly important passages for browsers and web apps.
First, prohibiting browser engines is banned:
Article 5(7) The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services.
Digital Markets Act - Article 5(7) (emphasis added)
Second, the DMA explicitly states why gatekeepers can not ban third-party browser engines: Gatekeepers should not be able to dictate the functionality of web apps:
When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsersand, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users.
Digital Markets Act - Recital 43 (emphasis added)
Third, gatekeepers must provide access to all the same APIs that are available to the gatekeepers own apps and services. This access may be subject to strictly necessary, proportionate and justified security conditions:
Article 6(7) The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services.
The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.
Digital Markets Act - Article 6(7) (emphasis added)
Finally the DMA comes with real teeth. It grants the Commission the power to fine gatekeepers found not to be in compliance up to 10% of global revenue, which in Apple’s case would be up to $39 billion USD per offence.
Apple, however, is taking a belligerent and obstructionist approach to the DMA. With a three trillion dollar market value and over 1 billion dollars a year in legal spending, Apple has legal power that outstrips that of small nations. It is also not afraid to step as close to the line of non-compliance as possible. As Apple’s former general counsel Bruce Sewell explained, the strategy when he was at Apple was to steer as close to the line as possible because “that’s where the competitive advantage occurs”, and even large fines are seen as acceptable costs.
# Apple's Browser Engine Ban Persists, Even Under the DMA
https://www.youtube.com/watch?v=_nRU9XUbnpM
However, despite the DMA aiming to allow browsers to compete fairly with their own engines, not a single browser vendor has successfully ported their engine to iOS in the last 21 months.
Both Google and Mozilla began porting their browser engines Blink and Gecko respectively to iOS. Other browser vendors are dependent on these ports to bring their own engines to their browsers iOS, as their products are typically soft forks (copies with modifications) of Blink or Gecko.
However there were significant issues with Apple’s contract and technical restrictions that made porting browser engines to iOS “as painful as possible” for browser vendors.
‘Apple’s proposals fail to give consumers viable choices by making it as painful as possible for others to provide competitive alternatives to Safari [...] This is another example of Apple creating barriers to prevent true browser competition on iOS.
Damiano DeMonte - Mozilla (emphasis added)
Many of Apple’s barriers rely on vague security and privacy grounds for which Apple has published no detailed technical justification for both their necessity and proportionality. As the US’s Department of Justice wrote in their complaint:
In the end, Apple deploys privacy and security justifications as an elastic shield that can stretch or contract to serve Apple’s financial and business interests.
DOJ Complaint against Apple
At the DMA workshop this year, we directly raised with Apple the primary blocker preventing third-party browser engines from shipping on iOS. Apple claimed that vendors like Google and Mozilla have “everything they need” to ship a browser engine in the EU and simply "have chosen not to do so”.
We recognize under the DMA that we've been forced to change. And we have created a program that keeps security and privacy in mind, that keeps the integrity of the operating system in mind, and allows third parties to bring their browser engine, Google, Mozilla, to the platform. And for whatever reason, they have chosen not to do so.Kyle Andeer - Apple - Vice President Apple Legal (emphasis added)
Apple has been fully aware of these barriers since at least June 2024, when we covered them in exhaustive detail. Multiple browser vendors have also discussed these same issues with Apple directly. The suggestion that Apple is unaware of the problems is not just ridiculous, it’s demonstrably false. Apple knows exactly what the issues are. It is simply refusing to address them.
The most critical barriers that continue to block third-party engines on iOS include:
Loss of existing EU users: Apple forces browser vendors to create entirely new apps to use their own engine, meaning they must abandon all current EU users and start from scratch.
Web developer testing: Apple allows native app developers outside the EU to test EU-specific functionality, but offers no equivalent for web developers to test their software using third-party browser engines on iOS. Apple stated during the workshop to expect updates here but has provided no details since.
No updates on long trips outside EU: Apple has not confirmed they will not disable browser updates (including security patches) if an EU user travels outside the EU for more than 30 days. This, far from being a security measure, actively lowers users' security by depriving them of security updates.
Hostile legal terms: The contractual conditions Apple imposes are harsh, one-sided, and incompatible with the DMA’s requirement that rules for API access can only be strictly necessary, proportionate security measures.
Dual engine support: Apple now allows browsers to include both WebKit and their own engine in the same app. This is essential for introducing a new engine to the platform while maintaining fallback compatibility.
However, the most critical barrier remains firmly in place: Apple still forces browser vendors to abandon all their existing EU users if they want to ship a non-WebKit engine. This single requirement destroys the business case for porting an engine to iOS. Building and maintaining a full browser engine is a major undertaking. Requiring vendors to start from scratch in one region (even a region as large as the EU), with zero users, makes the investment commercially nonviable.
Instead, transaction and overhead costs for developers will be higher, rather than lower, since they must develop a version of their apps for the EU and another for the rest of the world. On top of that, if and when they exercise the possibility to, for instance, incorporate their own browser engines into their browsers (they formerly worked on Apple's proprietary WebKit), they must submit a separate binary to Apple for its approval. What does that mean exactly? That developers must ship a new version of their app to its customers, and 'reacquire' them from zero.Alba Ribera Martínez - Lecturer in Competition Law and Digital Markets (emphasis added)
In October, OWA was invited to attend and give a short speech on our views of Apple’s compliance with the Digital Markets Act (DMA) at a meeting with the Working Group on the Implementation of the Digital Markets Act.
In our speech we argued that the Web was critical to EU society and that Apple was not complying with the DMA.
The open web is essential to a free European society. It enables every EU consumer and business to connect and transact without living under the thumb of tech giants. Its strength is that it is ubiquitous, built on open standards and free from gatekeeper control. If you want to reach users on every device without gatekeepers telling you how to run your business, the web is your only choice.
Apple understands well the power of the open web, in fact, they launched the iPhone with the key promise of having a 'full browser'.
But now, on Apple’s mobile operating system, the Web is blocked from reaching its full potential. Apple prevents third-party browsers from using their own engines, underinvests in its own browser Safari, and hides the option to install web apps that compete with its own app store. [...]
Take third-party browser engines on iOS. Nineteen months after the start of DMA compliance, they are still missing. Apple requires browser makers to restart from zero users if they want to use their own engines, and at one point blocked browser vendors from even testing their own browsers outside the EU. It is still unclear whether these browsers will continue to work when EU users travel. These conditions and many others make it impossible for competitors to invest in porting their engines to iOS.
This means that EU consumers and EU businesses lose. They lose by having lower quality, less interoperable browsers with poorer support for web apps. This in turn denies a competitor to both Apple’s and Google’s app stores, which raises costs and lowers quality, and damages security and privacy across the entire mobile app ecosystem.
OWA - At EU Parliament Working Group
Apple is taking the EU Commission to court in three separate court cases related to Article 6(7).
Designation
In this case (still ongoing) Apple is taking the EU Commission to court claiming the following points:
Article 6(7), the article imposing interoperability requirements, which Apple argues is illegal due to being disproportionate under the European Charter of Fundamental Rights.
Apple in fact has 5 app stores, not one. i.e. the App Store on iOS, iPadOS, WatchOS, VisionOS and MacOS are distinct.
iMessage isn’t a number-independent interpersonal communications service.
Apple’s claim to have multiple App Stores is despite the fact that users use the same Apple account across all of them, and pay once for apps on all of them. As well as this, developers upload and update their apps to all of them in a single process.
Apple is also challenging iMessage’s classification as a number-independent interpersonal communications service, despite the fact that you can use iMessage without a phone number, and despite the EU Commission having already decided against designating it as a gatekeeper.
Apple is asking that the court to annul the Commission’s decision designating iOS as a gatekeeper, declare Article 6(7) inapplicable, annul the finding that Apple’s App Store is a single core platform service, annul the finding that iMessage is a number-independent interpersonal communications service, and order the Commission to pay Apple’s costs.
Interoperability Specification Process This case (also still ongoing) relates to the final decision in the EU Article 6(7) specification proceeding against Apple. Article 6(7) of the DMA is the one which mandates that gatekeepers must provide API access to third-parties free of charge, subject to strictly necessary, proportionate and justified security conditions.
The EU Commission has imposed an interoperability process on Apple due to a repeated failure by Apple to both share reserved functionality and a slow-walking of existing requests.
Apple informed the Commission that it has moved some of the aforementioned requests to 'the next phase of the interoperability process.' (11) (12) At the same time, Apple is 'still undertaking an assessment' of other interoperability requests made pursuant to Article 6(7) of Regulation (EU) 2022/1925 and has not yet moved these to the 'next phase' of Apple’s own review process.
Decision to a Specification Proceeding into Apple for Connected Devices (emphasis added)
For example, in relation to interoperability for third-party devices, Apple slow-walked their request process for over 9 months. The requests mentioned date back as far as March 2024, yet Apple neither implemented nor formally rejected them. This repeated delay is mentioned in the Commission’s Implementing Decision.
On its website, Apple indicated that it would aim at providing developers updates every 90 days.
It appears from the 108 interoperability requests received by Apple from January 2024 until 31 October 2024,that the time taken by Apple to process interoperability requests through the different stages is significantly longer than the timelines mentioned in the previous paragraph.
Commission Implementing Decision (emphasis added)
Under the new process, third parties have the right to file interoperability requests with Apple under Article 6(7) of the DMA. These requests can be for any software or hardware feature available on iOS and iPadOS. This includes even subsets of features, i.e. if Apple is reserving a better version for its own apps, services or devices, as well as, third-party devices interoperating with iOS or iPadOS.
Apple is only obligated to provide access to this functionality within the EU.
The request process follows 3 phases:
Phase I – Eligibility phase: Apple assesses the eligibility request to ensure that the requests fit within the scope. Must be completed within 20 days.
Phase II – Project Plan: The Project Plan should be completed by Apple within 40 working days, starting from the end of phase I. Apple should communicate the project plan to the developer who will have the opportunity to provide its feedback on it.
Phase III – Development: to establish a predictable and reliable timeline for the development phase. Apple should develop interoperability solutions that require minor, mild, and significant efforts within 6, 12, or 18 months from the submission of the interoperability request, respectively.
Under the DMA, Apple can attach security measures when it opens up access to a particular feature in order to protect the integrity of the operating system. However, these must be justified by Apple and must be objective. This document has a lot of discussion as to exactly what this means.
If you are a third-party company or developer that requires functionality that Apple currently reserves for itself in the EU to make your apps or devices better (or possible), then you can follow this process and make an interop request. All of these requests can be done at a non-legal technical level, as simple technical requests for required functionality. Apple is not allowed to ignore these requests and must respond in writing within the above time limits.
Apple is arguing in their court case that:
These requirements are disproportionate under the European Charter of Fundamental Rights.
The European Commission exceeded the limits imposed by Article 291 TFEU.
That the Commission misapplied Article 6(7) of the DMA.
That Apple should not have to share new functionality with third-parties at the same time it grants them to its own apps and services.
Apple should not have time limits imposed on it for each step in the interop process.
Developers should not be able to request a technical reference from Apple to discover what undocumented functionality is available to request interoperability with.
Third-Party Devices Specification Process In this case (also still ongoing) Apple is arguing that the EU misapplied the law by imposing specific interoperability requirements for the following features:
Background Execution
Automatic Audio Switching
Proximity-Triggered Pairing
Close-range Wireless File Transfer
iOS Notifications
Media Casting
Automatic Wi-Fi Connection
NFC Controller in Reader/Writer Mode
High-Bandwidth Peer-to-Peer Wi-Fi Connection
Apple is also arguing that it should not have to share new functionality with third-parties at the same time it grants them to its own apps, devices and services.
Apple argues that it does not need to allow third parties with interoperability for future updates, including new functionalities, of the features controlled or accessed via iOS at the same time as they are available to Apple. According to Apple, such an obligation is not within the scope of Article 6(7) of Regulation (EU) 2022/1925 and would limit Apple’s incentives to innovate, increase the development cost of new features, reduce Apple’s competitive advantage and allow third parties to free ride on Apple’s innovation.
Commission Implementing Decision
While Google does allow browser vendors to compete with their own engines on Android, they have undermined the effectiveness of the EU browser choice screen by not granting the chosen browser the hotseat.
On iOS in the EU, selecting a third-party browser from the choice screen replaces Safari in the hotseat (dock), ensuring the user’s choice is respected. This change has already led to meaningful gains in market share; Mozilla, for example, saw its daily active users double in France and Germany on iOS, where the hotseat change is implemented. DuckDuckGo’s findings suggest that replacing Safari in the hotseat boosted the iOS choice screen’s effectiveness by a factor of nine. Yet Google refuses to make an equivalent change on Android, relying on an unreasonably narrow and, in our view, incorrect interpretation of the Digital Markets Act. Even when users choose a different browser, Chrome remains prominently placed, undermining their decision and steering them back toward Google’s own product.
We directly questioned Google on this at the DMA workshop. Read this article for our full analysis.
For over 8 years, Google has failed to keep its commitment to share the ability to install web apps with third-party browsers on Android, despite public requests from Samsung, Microsoft, Brave & Kiwi browser.
In 2015, Google introduced a method on Android to install web apps and subsequently replaced it with a better system called "WebAPK minting" in 2017. This system allows Chrome on Android to install web apps that integrate well with the operating system. At the time, now more than 8 years ago, Google promised to share this with third-party browser vendors. However, as of today this functionality is still exclusive to Chrome on most Android devices (Note: Samsung has implemented their own version for Samsung Internet on Samsung devices).
QUESTION: I am a developer of another browser on Android, can I have this seamless install process?
We are working on it. We are committed to making this available to all browsers on Android and we will have more details soon.
Google
A WebAPK is a thin wrapper Native App that provides a splash screen, system launcher integration, and system settings configuration points. When launched, a WebAPK essentially starts a tab in the browser which installed the WebAPK, loading the specific URL the web app developer configures. Google has implemented this API using Google Play Services.
All native apps on Android are packaged as APKs, either via an app store such as Google Play or via sideloading. WebAPKs allow web apps to be integrated into the OS for the purposes of discoverability, permissions management, shortcut creation, registering urls with the operating system (so links will open in the web app instead of a browser tab) and uninstallation. This means that web apps installed as WebAPKs are able to be shown in Android’s app drawer and search, system app pages such as apps, storage, screen time and battery usage, and shown without a browser badge.
Android’s security model is built around signed native APKs. In order for web apps to integrate properly on Android without significant architectural changes, web apps need to be wrapped in a signed native APK. This allowed Google to support web apps across existing versions of Android without having to introduce a new architecture to support web apps and wait for years for it to be updated.
Under Article 6(7) of the DMA, Google is obligated to share operating system APIs available to its own services with third-parties free of charge. In the recent DMA workshop it was clarified by the Commission that Google Play Services APIs were considered operating system APIs under the DMA. Thus, WebAPK Minting is an operating system API which Google is exclusively granting to Google Chrome in violation of Article 6(7).
The EU Commission should open a preceeding into this and compel Apple to comply with Article 5(7) of the DMA. These changes will finally allow browser vendors and the Web to compete fairly on iOS.
The UK was particularly busy this year with a new law, investigations closing and new ones opening. OWA has worked with the UK’s Competition and Markets Authority (CMA) for the last four years across 3 separate investigations. You can read a full timeline of our involvement here.
We are incredibly thankful for the hard work and dedication the CMA has shown in pursuing an issue that, while critical to mobile software development, is so densely technical. Their hard work looks set to finally pay off under the DMCC, which will finally grant the CMA the power to fix the wrongs that both the mobile ecosystem investigation and the mobile browsers and cloud gaming market investigation reference identified.
This can be thought of as the UK’s equivalent to the EU’s Digital Markets Act, although it has differences in how it is implemented as covered in this article. The DMCC mostly leaves it up to the CMA to decide what rules are appropriate to impose; the DMA dictates its rules with significantly less room for flexibility.
Firms with Strategic Market Status designation will be required to adhere to one or more tailored conduct requirements. The DMCC Act provides a structured framework for the Competition and Markets Authority (CMA) to follow when implementing these requirements.
Non-compliance with a conduct requirement could result in substantial penalties, amounting to up to 10% of the company’s global turnover.
Only the largest companies can be designated: those with turnover greater than £1 billion in the UK or £25 billion globally, thresholds introduced “to make clear that smaller firms will not be in scope”.
We all rely on browsers to use the internet on our phones, and the engines that make them work have a huge bearing on what we can see and do. Right now, choice in this space is severely limited and that has real impacts – preventing innovation and reducing competition from web apps. We need to give innovative tech firms, many of which are ambitious start-ups, a fair chance to compete.
Andrea Coscelli - Chief Executive of the UK's Competition and Markets Authority (emphasis added)
They published its final report in March. The conclusion was clear: Apple’s “WebKit restriction”, which forces all browsers on iOS to use Apple’s engine, harms competition, stifles innovation and functionality, particularly for web apps.
Most importantly, the MIR recommended a complete reversal of Apple’s ban on third-party browser engines. For the first time, a regulator proposes a remedy requiring Apple to allow third-party browsers to install and manage web apps using their own engines. This is a critical win for developers, startups, and anyone who relies on an open web.
The report (which is more than 600 pages) contains a number of significant conclusions including:
We conclude that the WebKit restriction means that there is no competition between browser engines on iOS.
We also conclude that the WebKit restriction harms competition in the market for mobile browsers on iOS.
We conclude that Apple’s WebKit restriction limits the ability of rival browser vendors to improve the performance of their mobile browsers on iOS.
We conclude that Apple’s WebKit restriction limits the ability of rival browser vendors to innovate and improve their mobile browsers on iOS.
We conclude that Apple’s WebKit restriction increases costs of rival browser vendors as it requires them to develop and maintain an additional version of their mobile browser, based on WebKit, to serve iOS users.
We conclude that this reduces the features available to consumers and web developers, and limits effective competition between browser vendors on iOS on security, privacy, and performance.
We conclude that the WebKit restriction does not give rise to rivalry-enhancing efficiencies in mobile browsers on iOS that would offset the negative effects on competition associated with the WebKit restriction we have identified
We conclude that the WebKit restriction therefore limits the features available to users and decreases competition between mobile browsers on privacy features on iOS.
MIR’s Final Report
We wholeheartedly agree with the MIR’s conclusion that the WebKit restriction limits users’ choice, raises costs for developers and browser vendors, reduces the features and performance available to both users and developers, and undermines browser competition on iOS.
“A requirement for Apple to provide equivalent access to functionality for browsers using alternative browser engines.”
“A requirement mandating Apple to provide equivalent WebKit access for all WebKit-based browsers on iOS.”
“A requirement for Apple in respect of in-app browsing to provide interoperability with bundled engines for in-app browsing and allow sufficient cross-app functionality to enable third-party browsers to provide in-app browsing in native apps.”
“A requirement for Apple not to enter into agreements with Google where it receives search advertising revenues connected to the use of Chrome on iOS.”
“A requirement for Apple and Google to make changes to choice architecture for browsers.”
“A requirement that prevents Google from making payments to OEMs and its licensing of its first-party apps and proprietary APIs conditional upon the prominent display and specific default-settings for Google Chrome on Android devices.”
“A number of the above requirements would need to be complemented by ensuring Apple: (i) permits browser apps to use alternative browser engines; and (ii) enables browser vendors using alternative browser engines to install and manage progressive web apps.”
According to the CMA these interventions could lead to greater browser and web app competition:
These types of potential interventions could lead to greater competition for developing browser features related to performance, privacy and/or security which support user needs. They could also encourage greater use of web apps as an alternative to native apps accessed through a mobile app store, which could lead to lower development costs and lower barriers to entry and expansion for app developers and greater accessibility of apps by users.
CMA - SMS Investigation Request for Comment (emphasis added)
According to the CMA’s current roadmap, they will be conducting investigations into both “Requiring Apple to allow third-party browsers and app developers to use alternative browser engines on iOS and iPadOS” and “to explore the potential for Progressive web apps” in the first half of 2026. We will be reporting more on this as it happens!
Banning browser engines is prohibited, as are actions “preventing” their adoption.
There must be functionally equivalent API access for 3rd parties, subject to justifiable measures.
It must be easy to change the default settings of the operating system.
A choice screen for browsers must be provided “promptly after the first activation”.
The act came into full effect on the 18th of December this year.
We’d like to extend our gratitude to the extensive work over many years by the HDMC, JFTC and others in improving browser, browser engine and web app competition.
On December 17th, Apple published how it intends to comply with the new law with respect to browser engines. However, Apple looks set to use the same tactic it has used in the EU to avoid complying with the same provision of the Digital Markets Act for the last twenty-one months. Namely, Apple demands that browser vendors lose all their existing Japanese users and produce a brand new browser, rather than simply updating their existing users. Apple will also not allow browser vendors to use their own engine on iPadOS and other iOS variants.
In late 2020, the U.S. Department of Justice (DOJ), in conjunction with state attorneys general representing 11 states, brought a landmark antitrust case against Google for unlawfully maintaining a monopoly in the general search engine market. In August 2024, Judge Mehta ruled in favor of the DOJ, declaring unequivocally that “Google is a monopolist, and it has acted as one to maintain its monopoly”.
We believe this ruling was correct, necessary, and that the DOJ’s case was compelling.
The DOJ then proposed an extensive list of remedies aimed at restoring competitive conditions in the market for general search engines in the United States. The vast majority of these numerous remedies the DOJ proposed seemed reasonable and proportionate. But amidst this sweeping package, two key remedies in particular had the potential to cause significant, severe, and sustained collateral damage to the web platform.
They were:
A total ban on search engine revenue sharing deals between browser vendors and Google.
A forced sale of Chrome by Google (and barring Google from re-entering the browser market for 10 years).
THE COURT: So I mean, it seems to me Mozilla, in some sense, would have a more compelling argument than you because it's not like Apple is going to go out of business if I don't -- you know, if you can no longer get revenue share. You've got other sources of revenue; Mozilla hardly has any.
UNITED STATES OF AMERICA vs GOOGLE LLC
Even more concerning was the likely collapse in web platform investment if Google is forced to sell Chrome. Google currently funds an estimated 90% of Chromium development. Chromium is the open-source project that powers a number of browsers including Chrome, Edge, Opera, Samsung Internet, Vivaldi, Brave, and many other smaller browsers. If Google is forced to divest Chrome and can no longer fund the project, that investment may evaporate overnight. Smaller browsers do not have the resources to fill that gap. In total, this could result in an estimated 70% drop in funding for the web platform, a catastrophic blow to the ongoing evolution of the web. Progress in new web features could stagnate, and the performance and stability of the web platform will deteriorate.
This in turn would harm the ability of the web to compete with the mobile app store duopoly of Apple and Google, directly undercutting the DOJ’s case against Apple, and threatening recent progress by UK and EU regulators to improve competition between browsers and between web apps and native apps. Critical efforts to port both Chromium and Gecko to iOS could have been abandoned entirely.
We appreciated that the DOJ took these concerns seriously and acknowledged the importance of a viable future for Chromium and the open web in its Revised Final Judgment Proposal, which required an evaluation of the buyer’s business and investment plans, including those for the open-source Chromium project. The proposal states:
The evaluation of any potential buyer shall include the potential buyer’s proposed business and investment plans (including those for open-source project Chromium), the United States’ evaluation, at its sole discretion, of any potential risks to national security, the potential buyer’s plans for sharing and protecting user data included in the acquisition, and any other issues a potential buyer may present.
Plaintiffs’ Revised Proposed Final Judgment(emphasis added)
Despite this we were still greatly concerned that these changes could be devastating to the funding of the web platform. In our paper we proposed the following potential alternative remedies:
Google will not be required to divest Chrome; nor will the court include a contingent divestiture of the Android operating system in the final judgment. Plaintiffs overreachedin seeking forced divesture of these key assets, which Google did not use to effect any illegal restraints.
Judge Mehta
While many were understandably disappointed that Judge Mehta did not go further in dismantling Google’s Search monopoly, and the underlying goal of the remedies was justified, we were greatly relieved that he did not inadvertently inflict vast harm on the web platform’s funding via these two remedies.
In 2024 the Department of Justice (DOJ) launched a lawsuit against Apple arguing that they have illegally monopolized the US smartphone market. The government claimed Apple broke the law by maintaining a closed ecosystem for the iPhone in pursuit of profits and at the expense of consumers and innovation.
The essence of the DOJ case is that Apple has made iPhones worse for US consumers in order to increase lock-in, reduce interoperability and block competitors from competing. The DOJ also argues that Apple uses security and privacy as a shield to justify its anticompetitive conduct.
Apple wraps itself in a cloak of privacy, security, and consumer preferences to
justify its anticompetitive conduct. Indeed, it spends billions on marketing and branding to promote the self-serving premise that only Apple can safeguard consumers’ privacy and security interests. Apple selectively compromises privacy and security interests when doing so is in Apple’s own financial interest
DOJ vs Apple
The DOJ has a number of examples of how Apple has done this, including discussing Apple's ban on third party browser engines and how lack of visibility for web apps on iOS makes them unviable.
Developers cannot avoid Apple’s control of app distribution and app creation by making web apps—apps created using standard programming languages for web-based content and available over the internet—as an alternative to native apps. Many iPhone users do not look for or know how to find web apps, causing web apps to constitute only a small fraction of app usage. Apple recognizes that web apps are not a good alternative to native apps for developers. As one Apple executive acknowledged, “[d]evelopers can’t make much money on the web.” Regardless, Apple can still control the functionality of web apps because Apple requires all web browsers on the iPhone to use WebKit, Apple’s browser engine—the key software components that third-party browsers use to display web content.
DOJ vs Apple (emphasis added)
One of the reasons that many users on iOS are unaware of how to install web apps is Apple has for years refused to implement install prompts and hidden away the mechanism for installing them on the share menu. At the same time, Apple has gone to great lengths to make it easy to link to and install Apple’s on iOS app store native apps from Safari.
The code of conduct for mobile OS services could require Designated Digital Platforms to allow third-party browser engines to be used on their mobile OS. This could allow third-party providers of browsers and web apps to compete on their merits.
We also consider that the additional competition measures should include the ability to provide third-party providers of apps and services with reasonable and equivalent access to hardware, software and functionality through their mobile OS.
Digital platform Services Inquiry - Interim Report No. 5
Essentially Australia is planning to implement a cross between the UK’s DMCC and the EU’s DMA with the aim of ensuring that Australian consumers and businesses can benefit from the increased competition in digital services.
A lack of competition in Australia’s digital markets can stifle productivity and innovation, reduce choices, and lead to higher prices for Australian consumers and small businesses.
Australians need mandatory codes for the most powerful digital platforms to prevent harms from a lack of competition
This lack of competition can limit growth opportunities for other firms, stifle innovation, reduce consumer choice and lead to higher prices. Examples include self-preferencing of their own products and services, exclusivity agreements, and conduct that makes it unnecessarily harder for consumers to switch to a competitor’s service.
Mandatory codes of conduct offer a flexible, targeted solution to address these harms in particular digital markets where intervention is most needed. App marketplaces / mobile operating systems and ad tech services should be prioritised.
Key findings from the Digital Platform Services Inquiry Final Report
The ACCC have directly highlighted ended Apple’s ban on third-party browser engines:
The ACCC’s Regulatory Reform Report noted that Apple requires all browsers on iOS to be built using its WebKit browser engine. Further, Apple prevents WebKit from accessing certain APIs and iOS functionality, which restricts the functionality of web apps compared to native apps. As a result, the Regulatory Reform Report noted that Apple iOS users do not have the option to use browsers that can offer a wider range of innovative features and functionality. Instead, they are limited to using browsers built using Apple’s WebKit browser engine. The ACCC noted its concern that this limits the ability for web apps (which are accessible through browsers rather than through the Apple App Store) to impose a competitive constraint on native apps.
Digital Platform Services Inquiry Final Report
The Australian Competition and Consumer Commission (ACCC) will gain powers to designate platforms, monitor compliance, and enforce obligations. Penalties are substantial: up to AUD$50 million, three times the benefit gained, or 30% of turnover during the breach period – whichever is greatest. App marketplaces and advertising technology will be first in line and social media may follow. [...]
The ACCC won’t wait for complaints. It will monitor designated platforms proactively, with powers to compel documents, conduct inquiries, and investigate suspected breaches. If the regulator finds non-compliance and the penalty calls for a portion of turnover during the breach period, it’s a value that scales with the size of the violation and the size of the firm.
The Modern Regulator
The new law is expected to be put before the Australian parliament in early 2026.
# Tim Berners Lee Supports Ending Apple’s Browser Engine Ban
In a recent interview with The Verge, Sir Tim Berners-Lee, inventor of the World Wide Web and HTML, has expressed support for compelling Apple to allow other browser engines on iOS, as more competition leads to more innovation and bright ideas. He also states that having a powerful browser on iOS would "change the dynamic" with respect to web app's viability on mobile.
Do you think that Apple being made to allow Chromium to run on the iPhone, for example, will actually lead to new browser innovation?
Nilay Patel - The Verge
When you have a competition between different sections of the layer, it tends to increase innovation. You get more bright ideas out there.
Sir Tim Berners-Lee
The UK’s CMA is going to conduct two investigations into Apple under the DMCC. One is into browser engines on iOS, the other is into the potential of web apps on iOS. These investigations will likely result in the CMA imposing bespoke rules on Apple to fix competition issues related to these topics such as prohibiting Apple ban on third-party browser engines, allowing API access for browsers and allowing browsers to install and manage web apps using their own engine.
As discussed above, we do not believe that Apple’s current solution with Japan’s new Smartphone law is compliant nor will it lead to fair browser competition on iOS in Japan. This will be a key area of focus of OWA in 2026, stay tuned for more updates.
Our aim is that either Apple will make changes to be in compliance or Japan's regulator will step in and open an investigation.
Australia will likely be putting their version of the DMCC and DMA before the Australian parliament. This will likely add Australia to the 28 countries that now explicitly prohibit Apple’s ban on third-party browser engines.
As with other countries, a law being passed is only the first step. Regulators will then need to proceed through the formal process of designation, code of conducts and investigations.
At the start of the year, we published a paper outlining how Apple was not in effective compliance with Article 5(7) of the DMA. It is now twenty one months since the DMA came into force, no browser vendor has successfully ported a competing engine to iOS. The financial, technical, and contractual barriers Apple has put in place remain insurmountable. These restrictions are not grounded in strictly necessary or proportionate security justifications.
We have outlined in detail why we believe Apple is not in effective compliance and is required under the DMA to make further changes. The EU commission has the power to fix this in 2026 by opening a proceeding into Apple and compelling them to make changes or face significant fines.
2026 promises to be a pivotal year, making it more important than ever for both developers and consumers to have strong advocacy for browser and web app competition. We sincerely thank everyone who generously contributed their time and expertise, whether through drafting or reviewing regulatory submissions, enhancing and building our website, engaging in detailed discussions, providing invaluable feedback, or participating in conferences and meetings; and those who helped provide financial support. You made the web a fairer, more competitive and more exciting platform.
OWA has so much more work to do advocating for the web all over the globe. We will always need your support, and you can do that in many ways:
Respond to regulator requests for comments. Where this is available we will share the details in both articles and social media posts.
If you have the opportunity, please join us in 2026!
]]>
Tim Berners-Lee On Apple’s Browser Engine Ban and Web Apps2025-11-13T00:00:00Zhttps://open-web-advocacy.org/blog/tim-berners-lee-on-apples-browser-engine-ban-and-web-apps/TL;DR: Sir Tim Berners-Lee, inventor of the World Wide Web and HTML, has expressed support for compelling Apple to allow other browser engines on iOS, as more competition leads to more innovation and bright ideas. He also states that having a powerful browser on iOS would "change the dynamic" with respect to web app's viability on mobile.
So there is one other one of note: it's WebKit, which is what Apple uses in Safari on the iPhone. It is dominant in its way. Building for WebKit is a thing that every mobile developer has to think about all the time because it is dominant on the iPhone.
Apple doesn't allow other browser engines on the iPhone. It certainly doesn't allow Chromium. Now, thanks to some EU regulation, it might have to. Depending on how some antitrust litigation in the United States goes, it might have to.
But up until now, Apple has not allowed anything but WebKit on the iPhone. Even Chrome on the iPhone is a skin over the top of the core browser engine, WebKit. Do you think that Apple being made to allow Chromium to run on the iPhone, for example, will actually lead to new browser innovation?Nilay Patel - The Verge (emphasis added)
When you have a competition between different sections of the layer, it tends to increase innovation. You get more bright ideas out there.Sir Tim Berners-Lee (emphasis added)
One of the arguments I've heard for why Apple will not allow other browser engines is that they can artificially restrict WebKit. So, it's not as good of a competitor to the native apps on the iPhone as web apps on the desktop are to native apps on the Mac or Windows or whatever.
If you had true web apps being able to run in Chromium on the iPhone, if you had that browser competition, there was a much more capable browser, do you think that would displace how the native apps work?
This is where we began the conversation, right? Is this push to apps because they're more capable on the iPhone? But if you had a browser that was as capable as a desktop browser on the iPhone, do you think that would change the dynamic?
Nilay Patel - The Verge (emphasis added)
We’ve been chatting to a bunch of experts on tests to find out to what extent this is true. Yes, I’ve heard rumors, but I can’t substantiate them on whether Apple is deliberately slowing down WebKit on the phone, so as not to compete with Apple native apps.
Sir Tim Berners-Lee
By the way, just for the record, Apple would tell you as loudly as they can that WebKit on the phone is as good as any other browser. And I think most users would tell you that it is not. And that gap is where I think the theories about Apple's development priorities come from. But I'm just asking more hypothetically. We've discussed the web as an application at an all-time high. Right? On desktop, if you have a Mac or a Windows PC or Linux, you are using web apps. Like mostly what you're using is applications expressed through web technology. Even if they appear to be native, right? Electron and other wrappers are just presenting web apps to you in ways that feel native. That is not true on mobile. It just really is not. Even for Google's efforts on Android, right? Progressive web apps on Android have not taken the world by storm.
Do you think a more powerful browser on the iPhone would ever change that dynamic or do you think people just want apps on phones?Nilay Patel - The Verge (emphasis added)
I think a more powerful browser on the iPhone would change that dynamicSir Tim Berners-Lee (emphasis added)
Because that, to me, feels like for all of the things we've talked about the future of the web has to happen on mobile, right? I mean, that is where the people are, that is the device that everyone carries around every day, and right now Apple's decisions about what the web cannot do on mobile are actually the gatekeeper right? In real ways, for most people's experience of the web. And so, it's if you introduce some competition, can you break that or do you need to just switch to Android where Google wants you to use the web?Nilay Patel - The Verge (emphasis added)
We 100% agree with both Sir Tim Berners-Lee and Nilay Patel and would like to thank them for taking the time to discuss the issue so clearly.
For new readers, Open Web Advocacy was founded in March 2021 specifically to ensure that browsers and web apps could compete fairly on all operating systems. At the heart of that goal is ending Apple’s ban on third-party browser engines on iOS. For the last four years we have worked with regulators in the EU, UK, Japan, USA and Australia to fix the Web on mobile, which we believe is fundamentally being held back by anti-competitive behaviour.
For the last 16 years, Apple has banned browser vendors from porting their own browser engines to iOS. They have done this via App Store Rule 2.5.6:
2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript.
In practice, 2.5.6 is a requirement that, on iOS, browsers from Google, Microsoft, Mozilla, Samsung, Vivaldi, Brave, Opera and others cannot use their own engines the way they do everywhere else. These engines take hundreds of thousands of engineer hours to develop, and are prohibited from running on Apple’s most successful consumer operating system. Competing browser vendors are only allowed to produce shells around a very specific, unaltered version of Safari’s WebView; a component whose features Apple dictates.
Apple has a browser monopoly on iOS, which is something Microsoft was never able to achieve with IE
Scott Gilbertson - The Register (emphasis added)
All of this is compounded by yet another Apple policy: no third-party browser engines. You can install apps like Chrome, Firefox, Brave, DuckDuckGo, and others on the iPhone — but fundamentally they’re all just skins on top of Apple’s WebKit engine. That means that Apple’s decisions on what web features to support on Safari are final. If Apple were to find a way to be comfortable letting competing web browsers run their own browser engines, a lot of this tension would dissipate.
Dieter Bohn and Tom Warren - The Verge (emphasis added)
So it’s not just one browser that falls behind. It’s all browsers on iOS. The whole web on iOS falls behind. And iOS has become so important that the entire web platform is being held back as a result.Niels Leenheer - HTML5test (emphasis added)
…because WebKit has literally zero competition on iOS, because Apple doesn’t allow competition, the incentive to make Safari better is much lighter than it could (should) be.
Chris Coyier - CSS Tricks (emphasis added)
What Gruber conveniently failed to mention is that Apple’s banning of third-party browser engines on iOS is repressing innovation in web apps.Richard MacManus - The New Stack (emphasis added)
Safari faces no effective competition on iOS as it has no genuine fear of losing users to other browsers which cannot compete using their own engines. As a thought experiment, imagine Microsoft had locked Firefox and Chrome to Trident in the early 2000s, would they have ever lost that browser war, and how much damage would that have inflicted on the Web? This lack of fear of losing market share removes a powerful incentive to invest.
The UK’s Competition and Markets Authority (CMA) in their latest report note that innovations have been held back due to a lack of competition, directly citing Apple’s WebKit Restriction:
As set out in Appendix B, we note that Apple’s revenue mix has been increasingly shifting away from devices and towards services. Furthermore, there is evidence that innovations have been held back in mobile ecosystems due to a lack of competition.
454 The CMA’s previous work has identified a range of areas where innovations have been held back in Mobile Ecosystems due to a lack of competition. For example, the MBCG MI found that Apple’s ban on alternative browser engines in its Mobile Platform, and therefore the lack of competition faced by Apple’s WebKit browser engine, had materially limited the capabilities of mobile browsers and web apps.CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
This matters, as competition is the primary driver of growth and innovation. Companies that, due to anti-competitive behaviour or some structural reason, do not face sufficient competition, are likely to raise prices and minimize expenditure beyond what is necessary to retain existing customers.
The CMA highlight that Apple can and does profitably forego innovation without fear of losing customers to competitors:
Apple’s vice president of iPhone marketing who explained in February 2020:‘In looking at it with hindsight, I think going forward we need to set a stake in the ground for what features we think are ‘good enough’ for the consumer. I would argue were [sic] already doing *more* than what would have been good enough.’ After identifying old features that ‘would have been good enough today if we hadn’t introduced [updated features] already’, she explained, ‘anything new and especially expensive needs to be rigorously challenged before it’s allowed into the consumer phone.’
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
The CMA highlighted two incentives for Apple’s browser engine ban in their market study:
Apple receives significant revenue from Google by setting Google Search as the default search engine on Safari, and therefore benefits financially from high usage of Safari. [...] The WebKit restriction may help to entrench this position by limiting the scope for other browsers on iOS to differentiate themselves from Safari [...] As a result, it is less likely that users will choose other browsers over Safari, which in turn secures Apple’s revenues from Google. [...] Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
UK CMA - Interim Report into Mobile Ecosystems (emphasis added)
First, losing browser market share on iOS to other browsers would mean losing valuable Google search revenue. Allowing browsers to use their own engines would enable them to effectively compete against Safari. Safari is the highest margin product Apple has ever made, accounts for 14-16% of Apple's annual operating profit and brings in $20 billion per year in search engine revenue from Google. For each 1% browser market share that Apple loses for Safari, Apple would lose $200 million in revenue per year.
Second, more powerful support for web apps could eat into Apple’s app store revenue. In 2024, Apple is estimated to have collected $27.4 billion from $91.3 billion in sales on its app store, underscoring its role as a critical and expanding source of profit. By contrast, the macOS App Store, where Apple does not exercise the same gatekeeping power over browsers or app distribution, remains a much smaller operation, with revenue that Apple chooses not to report.
Web apps, which already have a dominant 70% share on desktop, could (with effective competition and support) replace most of the apps on your phone. Even a far more modest 20% shift towards web apps would represent a $5.5 billion annual loss in revenue for Apple.
# Why Users and Developers Can’t “Just Switch to Android”
The CMA also found that there are substantial barriers to users switching phone brands.
We have found substantial evidence from our consumer survey, internal documents (from both Apple and Google) and third-party responses of material perceived barriers to switching related to:
(i) learning costs associated with switching;
(ii) transferring data and apps across Mobile Devices; and
This is important, and lines up with a common argument about browser engines, which is “switch to Android if you wish to use other browser engines”. This of course misses the point in three important ways:
Consumers, in general, have low awareness of browsers, browser engines and web functionality, and are unaware how anti-competitive constraints on them are making the apps they use more expensive, of lower quality and of lower security.
Businesses cannot choose where their customers are, and must support iOS, regardless of any lack of web functionality or browser competition.
Businesses who may wish to use web apps as a powerful and interoperable means of delivering apps to their customers are constrained from doing so due to a lack of critical features and significant bugs in iOS Safari. iOS Safari faces no effective competition. This constraint can even extend to Android, due to the loss of an effective cross platform interoperable web solution that also works on iOS. Even consumers who are acutely aware of Apple’s browser engine ban, face substantial and significant barriers to switching.
# Will Apple have to Allow Other Browser Engines on iOS?
Apple's proposals fail to give consumers viable choices by making it as painful as possible for others to provide competitive alternatives to Safari [...] This is another example of Apple creating barriers to prevent true browser competition on iOS.
Damiano DeMonte - Mozilla
In the EU, the landmark Digital Markets Act came into force on 7th March 2024.
It contained 3 incredibly important passages for browsers and web apps.
First, prohibiting browser engines is banned:
Article 5(7) The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services.
Digital Markets Act - Article 5(7) (emphasis added)
Second, the DMA explicitly states why gatekeepers cannot ban third-party browser engines: Gatekeepers should not be able to dictate the functionality of web apps:
When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsersand, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users.
Digital Markets Act - Recital 43 (emphasis added)
Third, gatekeepers must provide access to all the same APIs that are available to the gatekeeper’s own apps and services. This access may be subject to strictly necessary, proportionate and justified security conditions:
Article 6(7) The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services.
The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.
Digital Markets Act - Article 6(7) (emphasis added)
Finally the DMA comes with real teeth. It grants the Commission the power to fine gatekeepers found not to be in compliance up to 10% of global revenue, which in Apple’s case would be up to $39 billion USD per offence.
In 2024 the Department of Justice (DOJ) launched a lawsuit against Apple arguing that they have illegally monopolized the US smartphone market. The government claimed Apple broke the law by maintaining a closed ecosystem for the iPhone in pursuit of profits and at the expense of consumers and innovation.
The essence of the DOJ case is that Apple has made iPhones worse for US consumers in order to increase lock-in, reduce interoperability, and block competitors from competing. The DOJ also argues that Apple uses security and privacy as a shield to justify its anticompetitive conduct.
Apple wraps itself in a cloak of privacy, security, and consumer preferences to justify its anticompetitive conduct. Indeed, it spends billions on marketing and branding to promote the self-serving premise that only Apple can safeguard consumers’ privacy and security interests. Apple selectively compromises privacy and security interests when doing so is in Apple’s own financial interest
DOJ vs Apple
The DOJ has a number of examples of how Apple has done this, including discussing Apple's ban on third party browser engines and how lack of visibility for web apps on iOS makes them unviable.
Developers cannot avoid Apple’s control of app distribution and app creation by making web apps—apps created using standard programming languages for web-based content and available over the internet—as an alternative to native apps. Many iPhone users do not look for or know how to find web apps, causing web apps to constitute only a small fraction of app usage. Apple recognizes that web apps are not a good alternative to native apps for developers. As one Apple executive acknowledged, “[d]evelopers can’t make much money on the web.” Regardless, Apple can still control the functionality of web apps because Apple requires all web browsers on the iPhone to use WebKit, Apple’s browser engine—the key software components that third-party browsers use to display web content.
DOJ vs Apple (emphasis added)
It is worth noting that one of the reasons that many users are unaware of how to install web apps on iOS, is that Apple has for years refused to implement install prompts and hidden away the mechanism for installing them on the share menu. At the same time, Apple has gone to great lengths to make it easy to link to and install native apps via Apple’s own iOS app store, right from Safari.
This case is in its early stages and will likely run for several years.
David Pierce of The Verge hits upon this idea of Apple making its iPad actively worse for consumers by blocking competing browser engines in his most recent piece:
The iPad’sdraconian security policies, underpowered browser, and minuscule ideas about multitasking made the device feel like less than the sum of its parts. Users wanted a new laptop, and Apple told them to kick rocks. The iPad was something else, it said, and if you wanted a laptop you should buy a Mac. [...]
Which makes it all the more annoying every time you run into some totally unnecessary system limitation. There are still a lot of those. Apple’s laptops are allowed to run any app, not just the ones in the App Store. They can interact with more accessories. They can access virtually everything about the system through the Terminal. They can run better browsers. Utility apps I rely on to make my computing life easier, like Raycast and Better Touch Tool, just don’t exist the same way on the iPad. There’s almost nothing the Mac straight-up won’t let you do, but the iPad is full of limitations.They’ve been there for so long, and are so glaring, that we’ve been mad about them in reviews since at least 2018. Apple saw them as a feature, not a bug. [...]
Now that Apple has embraced the iPad’s computerness, the project over the next decade is to start shedding those limitations. If not all of them, then most of them. Apps need more power to run in the background, and to interact with one another. System-level apps should get more access to actually interact with the system. The iPad deserves a desktop-class browser.David Pierce - The Verge
The bill aims to promote fair and free competition on smartphones by preventing large tech companies from abusing their position as providers of platforms to block or advantage their own services.
Violators will face fines equivalent to 20% of the domestic revenue of the service that violated the law. The rate of the fine can be increased to 30% for repeated violations.
The final bill contains a number of interesting articles relevant to browsers and web apps:
Banning browser engines is prohibited.
Must share APIs and services of the operating system to the same level as the services used by the designated providers. Justifiable measures may be applied.
Designated providers shall make it easy to change the default settings of the operating system.
Designated providers shall provide a choice screen for browsers.
When a designated business operator sets or changes the specifications, sets or changes the conditions for use, it must take necessary measures, such as securing a period for the business operator specified in each item to smoothly respond to the measure, disclosing information, and establishing a necessary system, as specified by the Fair Trade Commission rules.
This bill gave the UK Regulator the Competition and Markets Authority (CMA) the ability to designate a firm as having Strategic Market Status (SMS) in a digital activity linked to the UK. Once a firm has been designated the CMA is able to create a bespoke code of conduct for that company, or apply pro-competition interventions to fix particular issues related to the digital activity.
“A requirement for Apple to provide equivalent access to functionality for browsers using alternative browser engines.”
“A requirement mandating Apple to provide equivalent WebKit access for all WebKit-based browsers on iOS.”
“A requirement for Apple in respect of in-app browsing to provide interoperability with bundled engines for in-app browsing and allow sufficient cross-app functionality to enable third-party browsers to provide in-app browsing in native apps.”
“A requirement for Apple not to enter into agreements with Google where it receives search advertising revenues connected to the use of Chrome on iOS.”
“A requirement for Apple and Google to make changes to choice architecture for browsers.”
“A requirement that prevents Google from making payments to OEMs and its licensing of its first-party apps and proprietary APIs conditional upon the prominent display and specific default-settings for Google Chrome on Android devices.”
“A number of the above requirements would need to be complemented by ensuring Apple: (i) permits browser apps to use alternative browser engines; and (ii) enables browser vendors using alternative browser engines to install and manage progressive web apps.”
According to the CMA these interventions could lead to greater browser and web app competition:
These types of potential interventions could lead to greater competition for developing browser features related to performance, privacy and/or security which support user needs. They could also encourage greater use of web apps as an alternative to native apps accessed through a mobile app store, which could lead to lower development costs and lower barriers to entry and expansion for app developers and greater accessibility of apps by users.
CMA - SMS Investigation Request for Comment (emphasis added)
The CMA’s Final Decision finds that Apple’s ban of third-party browser engines harms both browser and web app competition on iOS:
We find that the WebKit restriction restricts the ability of rival mobile browsers to innovate and develop features, and increases their costs. It therefore creates a barrier to entry and expansion for rival mobile browsers on Apple’s Mobile Ecosystem and limits the competitive constraint on Safari.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
The CMA also found that web apps are not currently a viable competitor to Apple’s App Store:
The evidence indicates that for content providers, at present, web apps are not a viable substitute for native apps downloaded from the App Store. This is despite web apps in principle being an attractive option for content providers because they involve lower development and maintenance costs compared to native apps.
Specifically, a range of content providers we gathered evidence from indicated that web apps are not viable substitutes to native apps, and a number of these content providers indicated that substitutability is particularly limited in terms of functionality and discoverability, which are important factors for app developers’ distribution choices. Several content providers further submitted that functionality issues with web apps are due to restrictions that Apple has imposed on web browsers within its Mobile Ecosystem.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Worse, these problems on iOS dampen web app viability across the entire mobile ecosystem:
Several content providers further submitted that functionality issues with web apps are due to restrictions that Apple has imposed on web browsers within its Mobile Ecosystem, whichcarry over to Google’s Mobile Ecosystem due to the platform-agnostic nature of web apps (ie because web developers build their web apps using functionalities available across all major browsers).
CMA - SMS Investigation into Google’s Mobile Platform - Final Decision (emphasis added)
In the first half of next year the CMA will be conducting an investigation into both third-party browser engines and web apps as part of a code of conduct that they will impose on Apple under the DMCC.
The code of conduct for mobile OS services could require Designated Digital Platforms to allow third-party browser engines to be used on their mobile OS. This could allow third-party providers of browsers and web apps to compete on their merits.
We also consider that the additional competition measures should include the ability to provide third-party providers of apps and services with reasonable and equivalent access to hardware, software and functionality through their mobile OS.
A global end to Apple’s ban on third-party browser engines on iOS would be profound. The first consequence is that Safari would come under intense pressure to compete. Given that Safari is Apple’s highest margin product, Apple will not abandon it. Its current budget is a minute fraction of the revenue it pulls in, doubling or tripling its budget would be the obvious response. We have already seen a significant increase in budget and activity in response to the threat of regulators allowing other browser vendors to use their own engines.
The next consequence, that Nilay and Tim discuss, is that more powerful browsers on iOS would be available to power web apps. Features such as install prompts, working and feature complete push notifications and higher stability would be game changing for web apps viability. Suddenly, developers would have a viable and interoperable alternative to Apple’s app store. The web could become as dominant on mobile as it is on desktop.
For everything else there is always the open Internet.If the App Store model and guidelines or alternative distribution and Notarization for iOS and iPadOS apps are not best for your app or business idea that’s okay, we provide Safari for a great web experience too.Apple App Store Rules (emphasis added)
This change will make web apps a genuine and powerful alternative.
While legal experts expect the EU to challenge Apple's insincere compliance with the DMA, developers should take this opportunity to rethink their native app serfdom. They should push web apps to their limits and then demand further platform improvement. The web doesn't require commission payments, technology fees based on usage, or permission from platform rentseekers. The web can set the iPhone free, even if Apple won't.Thomas Claburn - The Register
]]>
What Apple’s UK Strategic Market Status Designation means for Browsers and Web Apps2025-11-04T00:00:00Zhttps://open-web-advocacy.org/blog/what-apples-uk-strategic-market-status-designation-means-for-browsers-and-web-apps/TL;DR: The UK’s Competition and Markets Authority (CMA) has officially designated Apple as having Strategic Market Status (SMS). After four years investigating Apple’s restrictions on browser engines and web apps, the CMA now has statutory authority to enforce remedies proposed in its Market Investigation Reference completed this year.
The most important outcomes being:
Apple can be compelled to allow third-party browsers on iOS to use their own engines.
Apple can be compelled to provide equivalent access to functionality for browsers using their own browser engines.
Apple can be compelled to let third-party browsers install and manage web apps using their own engines.
Apple can be compelled to remove barriers to web app adoption, such as implementing a web app equivalent to smart banners or install prompts in iOS Safari.
# What does being designated Strategic Market Status mean?
This bill gave the UK Regulator the Competition and Markets Authority (CMA) the ability to designate a firm as having Strategic Market Status (SMS) in a digital activity linked to the UK. Once a firm has been designated the CMA is able to create a bespoke code of conduct for that company, or apply pro-competition interventions to fix particular issues related to the digital activity.
Importantly, and the CMA stress this in their report, a designation of having Strategic Market Status is not in itself an indication of wrongdoing. It simply means that the company has substantial and entrenched market power and a position of strategic significance.
Only the largest companies can be designated: those with turnover greater than £1 billion in the UK or £25 billion globally, thresholds introduced ‘to make clear that smaller firms will not be in scope’.
The DMCC is quite different from the EU’s Digital Markets Act (DMA), in that the bill itself does not specifically spell out the obligations, unlike the DMA whose articles explain the obligations in significant detail. This means the CMA has more flexibility in what obligations it can impose and how they will work.
That is, the CMA now has the power to impose separate, tailor-made codes of conduct on each of Apple and Google in order to boost competition in digital markets.
“A requirement for Apple to provide equivalent access to functionality for browsers using alternative browser engines.”
“A requirement mandating Apple to provide equivalent WebKit access for all WebKit-based browsers on iOS.”
“A requirement for Apple in respect of in-app browsing to provide interoperability with bundled engines for in-app browsing and allow sufficient cross-app functionality to enable third-party browsers to provide in-app browsing in native apps.”
“A requirement for Apple not to enter into agreements with Google where it receives search advertising revenues connected to the use of Chrome on iOS.”
“A requirement for Apple and Google to make changes to choice architecture for browsers.”
“A requirement that prevents Google from making payments to OEMs and its licensing of its first-party apps and proprietary APIs conditional upon the prominent display and specific default-settings for Google Chrome on Android devices.”
“A number of the above requirements would need to be complemented by ensuring Apple: (i) permits browser apps to use alternative browser engines; and (ii) enables browser vendors using alternative browser engines to install and manage progressive web apps.”
According to the CMA these interventions could lead to greater browser and web app competition:
These types of potential interventions could lead to greater competition for developing browser features related to performance, privacy and/or security which support user needs. They could also encourage greater use of web apps as an alternative to native apps accessed through a mobile app store, which could lead to lower development costs and lower barriers to entry and expansion for app developers and greater accessibility of apps by users.
CMA - SMS Investigation Request for Comment (emphasis added)
In their current roadmap, the CMA will begin consulting on the following interventions at these times:
Late 2025
Requiring Apple to fairly and objectively consider requests from third parties for interoperable access to functionality in its operating systems.
First half of 2026
Requiring Apple to allow third-party browsers and app developers to use alternative browser engines on iOS and iPadOS.
Requiring that Apple’s choice architecture in relation to digital wallets and browsers supports active user choice and does not give Apple’s own products and services an advantage over those of third parties.
The CMA will further work to explore the potential for Progressive Web Apps.
Later
Requiring Apple to provide third-party browsers using WebKit with access to equivalent functionality as that used by Safari.
Under Consideration
Action to address the impact on competition arising from the revenue share agreement between Apple and Google.
On Apple Mobile Devices, all mobile browsers are required to use Apple’s WebKit browser engine, as specified in Apple’s App Store Review guidelines. Apple therefore does not face competition from rival mobile browser engines within its Mobile Ecosystem. This position will not change unless Apple lifts its prohibition on the use of alternative browser engines within its Mobile Ecosystem.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
WebKit is the engine that powers Safari and several smaller browsers on Linux and macOS.
In practice, 2.5.6 is a requirement that on iOS, browsers from Google, Microsoft, Mozilla, Samsung, Vivaldi, Brave, Opera and others cannot use their own engines the way they do everywhere else. These engines take hundreds of thousands of engineer hours to develop, and are excluded from Apple’s most successful consumer operating system. Competing browser vendors are only allowed to produce shells around a very specific, unaltered version of Safari’s WebView; a component whose features Apple dictates.
Apple has a browser monopoly on iOS, which is something Microsoft was never able to achieve with IE
Scott Gilbertson - The Register (emphasis added)
All of this is compounded by yet another Apple policy: no third-party browser engines. You can install apps like Chrome, Firefox, Brave, DuckDuckGo, and others on the iPhone — but fundamentally they’re all just skins on top of Apple’s WebKit engine. That means that Apple’s decisions on what web features to support on Safari are final. If Apple were to find a way to be comfortable letting competing web browsers run their own browser engines, a lot of this tension would dissipate.
Dieter Bohn and Tom Warren - The Verge (emphasis added)
So it’s not just one browser that falls behind. It’s all browsers on iOS. The whole web on iOS falls behind. And iOS has become so important that the entire web platform is being held back as a result.Niels Leenheer - HTML5test (emphasis added)
…because WebKit has literally zero competition on iOS, because Apple doesn’t allow competition, the incentive to make Safari better is much lighter than it could (should) be.
Chris Coyier - CSS Tricks (emphasis added)
What Gruber conveniently failed to mention is that Apple’s banning of third-party browser engines on iOS is repressing innovation in web apps.Richard MacManus - NewsStack (emphasis added)
No other major operating system imposes such a ban. Microsoft Windows, Android, Linux, and Apple’s own macOS all enable browser vendors to choose and modify their own engines. All rival iOS browsers are essentially Safari under the hood. This browser ban is unique to Apple’s iOS.
The CMA’s Final Decision finds that Apple’s ban of third party browser engines harms both browser and web app competition on iOS:
We find that Apple’s Safari has held an extremely high and stable share of supply over a substantial period which suggests that it is subject to limited competition within Apple’s Mobile Ecosystem.The WebKit restriction means that Apple’s browser engine does not face competition within Apple’s Mobile Ecosystem.
[...]
We find that the WebKit restriction restricts the ability of rival mobile browsers to innovate and develop features, and increases their costs. It therefore creates a barrier to entry and expansion for rival mobile browsers on Apple’s Mobile Ecosystem and limits the competitive constraint on Safari.
[...] substantial evidence from third-party browser developers shows that the WebKit restriction creates barriers to entry and expansion for mobile browsers on Apple’s Mobile Ecosystem:
(a) It restricts their ability to innovate and develop features for their mobile browsers on Apple’s Mobile Ecosystem. Several browser developers provided examples of features that they were unable to implement, or had more difficulty in implementing, on Apple’s Mobile Ecosystem, as a result of their inability to use an alternative browser engine or to modify WebKit. This includes features for web apps, which could provide an alternative to native apps for content providers.
(b) It means that app developers are prevented from developing their own in-app browsing implementations using their own browser engines. One app developer [✄] submitted that this prevents both mobile browsers and in-app browsing on iOS from competing more effectively with Safari. This app developer submitted that [✄].
(c) It increases their costs by requiring them to develop a WebKit-based version of their browser to enter as a mobile browser on Apple’s Mobile Ecosystem, as opposed to being able to use the same browser engine that they use on other platforms. This means they sometimes have to rebuild features in a different way for Apple’s Mobile Ecosystem, incurring additional costs. A few browser developers submitted that this delayed their entry on Apple’s Mobile Ecosystem.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Somewhat surprisingly, Apple submitted evidencearguing that web apps were an effective competitor to native apps on their app store, despite the significant barriers that Apple has placed in their way, and the fact they attempted to remove the functionality altogether in the EU rather than share it with third-party browsers using their own engines.
(a) On iOS and iPadOS, app developers have multiple web-based distribution options, including web apps and web browsers and that the App Store is ‘constrained by these alternatives’.
(b) Web apps and PWAs often have a similar appearance, user experience and functionality as a native app and app developers can sell the same or very similar content via a traditional website as through a native app. Apple highlighted several examples of apps that are available both as web apps and on the App Store, and noted that cloud gaming services allow video games to be streamed via web apps.
(c) There are no factors that cause users to face difficulties in switching between using native apps and web apps or home-screen web apps on iOS or using a combination of these distribution methods.
However the CMA found that web apps are not currently a viable competitor to Apple’s App Store:
The evidence indicates that for content providers, at present, web apps are not a viable substitute for native apps downloaded from the App Store. This is despite web apps in principle being an attractive option for content providers because they involve lower development and maintenance costs compared to native apps.
Specifically, a range of content providers we gathered evidence from indicated that web apps are not viable substitutes to native apps, and a number of these content providers indicated that substitutability is particularly limited in terms of functionality and discoverability, which are important factors for app developers’ distribution choices. Several content providers further submitted that functionality issues with web apps are due to restrictions that Apple has imposed on web browsers within its Mobile Ecosystem.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Worse, these problems on iOS dampen web app viability across the entire mobile ecosystem:
Several content providers further submitted that functionality issues with web apps are due to restrictions that Apple has imposed on web browsers within its Mobile Ecosystem, whichcarry over to Google’s Mobile Ecosystem due to the platform-agnostic nature of web apps (ie because web developers build their web apps using functionalities available across all major browsers).
CMA - SMS Investigation into Google’s Mobile Platform - Final Decision (emphasis added)
The final decision lays out substantial barriers to third-party browsers competing fairly on iOS.
First, the WebKit restriction that prevents browsers from using their own engine:
We find that the WebKit restriction restricts the ability of rival mobile browsers to innovate and develop features, and increases their costs. It therefore creates a barrier to entry and expansion for rival mobile browsers on Apple’s Mobile Ecosystem and limits the competitive constraint on Safari.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Apple has also been found to withhold or delay providing functionalities to rival browsers:
We find that greater and/or more immediate access to certain functionalities on Apple’s Mobile Ecosystem has provided Safari with a competitive advantage relative to third-party mobile browsers, by allowing Safari to implement features that are not available to rival mobile browsers, and therefore limiting the competitive constraint on Safari.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
The CMA also have found that Apple’s pre-installation and choice architecture dampens third-party browsers’ ability to compete:
…althoughit is possible for users to switch to an alternative mobile browser to Safari, there are barriers to doing so, given Safari’s position as the pre-installed and default mobile browser on many new Mobile Devices. We find that this, combined with behavioural biases, and general low user awareness and engagement with mobile browsers (see above), provides Safari with a competitive advantage and therefore limits the competitive constraints on it within Apple’s Mobile Ecosystem.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Next, the CMA directly criticises the Apple-Google Search Deal (officially called ISA). In particular, a clause where Google also pays Apple a share of revenue for Chrome’s traffic on iOS.
We find that the ISA materially limits Apple’s and Google’s incentives to compete, and this dampens the extent of competition between Apple’s Mobile Ecosystem and Google’s Mobile Ecosystem.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Finally, all of these issues combined lead the CMA to conclude that the competitive constraint applied to Safari by third-party browsers on iOS is limited.
We conclude that Apple’s Safari browser faces limited competitive constraints on Apple’s Mobile Ecosystem and the evidence indicates that this is unlikely to change significantly over the next five years.
Although other mobile browsers are available, these face barriers to entry and expansion, in particular those related to the WebKit restriction, Safari’s superior access to functionality, and choice architecture and Safari’s consistently high share of supply indicates that these are a limited competitive constraint.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Importantly these are all issues that the CMA can directly address in their code of conduct for Apple.
Apple tried to avoid regulation in the European Union by making a surprising claim – that it offers not one but three distinct web browsers, all coincidentally named Safari.
Cupertino also claimed it maintains five app stores and five operating systems, and that these core platform services, apart from iOS, fell below the usage threshold European rules set for regulating large platform services and ensuring competition.
Thomas Claburn - The Register
Apple made this attempt despite the Digital Markets Act containing specific clauses to address this exact behavior:
Article 13(1): An undertaking providing core platform services shall not segment, divide, subdivide, fragment or split those services through contractual, commercial, technical or any other means in order to circumvent the quantitative thresholds laid down in Article 3(2). No such practice of an undertaking shall prevent the Commission from designating it as a gatekeeper pursuant to Article 3(4).
Digital Markets Act
The EU Commission rejected Apple’s argument noting:
Safari appears to serve the same purpose from both an end user and a business user perspective across all devices on which it is available, which is to allow users to offer, access and interact with web content. [...]
while certain features of Safari may be adapted to the type of device (e.g., due to the devices’ different screen sizes), the principal functionalities that allow end users to access and interact with web content on Safari are common to all Apple devices on which that service is available. [...]
The differences in certain features of Safari on iPhones, iPads and Mac, which according to Apple cater for Safari’s different use cases depending on the device type, appear to concern essentially the nature, function and usage of the different devices on which Safari is available, rather than the web browser Safari. [...]
As Apple explains on its website, all these features allow Safari to work seamlessly across devices: “Same Safari. Different device: Safari works seamlessly and syncs your passwords, bookmarks, history,tabs, and more across Mac, iPad, iPhone, and Apple Watch.
EU Commission Decision (emphasis added)
In this UK’s 2025 SMS investigation, Apple once again attempted to claim that Safari on iOS and Safari on iPadOS were distinct separate digital activities.
In response to the Proposed Decision, Apple reiterated points made in its earlier submissions that Safari on iOS and iPadOS are offered and consumed separately, stating that:
(a) Safari on iOS and iPadOS support different user needs and preferences. Specifically, Apple stated that users typically use Safari on iOS when they want to quickly look up something, while Safari on iPadOS supports a larger screen, which lends itself better to in-depth browsing.
(b) Safari for iOS and iPadOS are also offered differently. Safari for iPad brings a Mac-like browsing experience to the iPad, eg loading the desktop versions of websites. Apple pointed to sidebar as a significant feature that is available on iPad but not iPhone, and to functionalities that reflect the diverging use cases for accessing the web through Safari on iOS and iPadOS.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Both OWA and Mozilla supported the CMA in considering it a single digital activity.
Open Web Advocacy supported the CMA’s proposed reasons for considering Safari to be a single browser, adding that Apple’s own marketing presents Safari in this way. Mozilla, similarly, agreed with the CMA’s proposed position, further noting that the underlying code of browsers across both iOS and iPad OS tends to be almost identical, and that, until recently, Apple had a single submission process across both platforms.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
The CMA rejected Apple’s arguments and has found that
...there are many important similarities in how Safari is offered across Apple devices and which reflect the characteristics of the browser rather than being a function of the characteristics of each device: Apple develops and provides one version of the mobile browser as referred to in Apple’s release notes across its devices. For example, Apple’s release note from 31 March 2025 stated that ‘Safari 18.4 is available for iOS 18.4, iPadOS 18.4, visionOS 2.4, macOS 15.4, macOS Sonoma, and macOS Ventura.’ Apple also promotes Safari as a single web browser rather than a browser designed for a specific device; and applies the same policies across iOS and iPadOS: for example the WebKit restriction applies to browsing on both iOS and iPadOS. Apple often does not distinguish between iOS and iPadOS features for WebKit [...]
Apple was the only party to submit that Safari for iOS and iPadOS should be treated as separate digital activities. The two third parties who commented on this (Open Web Advocacy and Mozilla) both agreed with the approach of treating Safari across iOS and iPadOS as a single digital activity, with Mozilla (a browser developer) pointing out that the underlying code of browsers across both iOS and iPadOS tends to be almost identical. [...]
Considering the above evidence in the round, our view is that the Mobile Browser and Browser Engine on iOS and iPadOS is sufficiently similar in how it is offered by Apple and consumed by end-users and browser developers to fall under the provision of a single digital activity. The fact that there may be some differences in use cases and particular features between these devices does not undermine this view.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
# Combined Digital Activity: Apple’s Mobile Platform
Under the digital markets competition regime, an SMS designation applies to a ‘relevant digital activity’, rather than an entire firm. This ensures that we take a targeted approach, focusing on the areas where a firm has substantial and entrenched market power (SEMP) and a position of strategic significance (POSS). [...]
The Act allows the CMA to treat two or more digital activities carried out by a firm as a single digital activity – to ‘group’ what would otherwise qualify as separate activities – where they share a common purpose or can be carried out together to fulfil a specific purpose.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision
The DMCC allows the CMA to group digital activities together where they share a common purpose. The CMA has chosen to combine iOS, iPadOS, Apple’s App Store, Safari and WebKit as a single digital activity called “Apple’s Mobile Platform”.
1.14 We define the scope of these activities as follows:
(a) Smartphone Operating System – the provision of an operating system or equivalent, which acts as an intermediary between hardware and software on a smartphone, enabling software applications and services to run on the smartphone.
(b) Tablet Operating System – the provision of an operating system or equivalent, which acts as an intermediary between hardware and software on a tablet, enabling software applications and services to run on the tablet.
(c) Native App Distribution – the provision of a service which enables the installation, distribution and operation of native apps on Mobile Devices, which are apps written to run on the Smartphone Operating System and/or the Tablet Operating System.
(d) Mobile Browser and Browser Engine – the provision of a mobile browser and mobile browser engine, which comprises:
(i) the provision of a software application that enables users of Mobile Devices to access and search the internet and interact with web content; and
(ii) the provision of a mobile browser engine, which is the underlying technology which native apps on Mobile Devices use to transform web page source code into content with which users can engage.
The component digital activities of Apple’s Mobile Platform together facilitate interactions between users and providers of digital content and services on Mobile Devices in order to allow users to access, view and engage with such content and services on their Mobile Devices. These individual digital activities together form an integrated package of complementary services and content. Accordingly, it is appropriate, for the purposes of arriving at an assessment of SMS under the Act, to consider them together, reflecting their interlinkages**. The grouping of these activities as the Mobile Platform provides the framework necessary to reflect the real-world operation of these services and content, taking account of how they are offered and consumed.**
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
This is important as it allows the CMA to create remedies that cross these overlapping activities and to avoid circumvention. It also allows the CMA to consider whether interlinkages between these may contribute to market power which is relevant to if Apple gets designated with respect to each of these digital activities.
...whether and how any interlinkages between these may contribute to market power across the digital activity; for example, whether the firm’s position in one activity in the group reinforces its position in another. CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Apple unsurprisingly disagreed:
4.126 In relation to the application of section 3(3)(b) specifically, Apple submitted that:
(a) Apple’s digital activities are not carried out ‘in combination’ with each other, but are commonly carried out separately; and
(b) Apple’s digital activities are not used to fulfil a ‘specific’ purpose.
4.127 Apple also submitted that the CMA’s approach to considering whether the digital activities have the same or similar purpose under section 3(3)(a) of the Act is too broad and without merit.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
The CMA helpfully provided Apple with many of their past statements where they claim the opposite:
In practice, and consistent with our prior work in respect of mobile ecosystems, the evidence shows that Apple’s operating systems, app store and browser and browser engine across its Mobile Devices are provided (or ‘carried out’) in a tightly integrated manner:
(a) In as early as 2010, Apple’s then-CEO Steve Jobs set out Apple’s vision to ‘tie all of our products together, so we further lock customers into our ecosystem’ and ‘make Apple ecosystem even more sticky’. In 2013, Apple’s senior executives (in an internal email exchange involving now-CEO Tim Cook) reiterated this goal to ‘get people hooked to the ecosystem’.
(b) Apple’s submissions in this investigation further support the tightly integrated nature of the individual digital activities. For example:
(i) In its ITC response, Apple explained that it offers integrated products that combine hardware and software to create a highly differentiated user experience; iPhone and iPad include an operating system, the App Store, apps, and hardware components that Apple designed from scratch to maximise performance, usability, privacy, and security.
(ii) Apple further noted that it does not consider its operating systems, the App Store, browser, and browser engine to be distinct products. Instead, these are all aspects of iPhone, iPad, and other integrated Apple products.
(c) In its public filing, Apple similarly stated that it ‘designs and develops nearly the entire solution for its products, including the hardware, operating system, numerous software applications and related services’.CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
The CMA goes on to explain the many ways that Apple devices and services are bound together:
On a webpage with the headline ‘All your devices. One seamless experience’, Apple describes how users ‘can do so much more’ when using Apple’s devices together. It gives examples of that ‘seamless experience’, including: (i) a feature enabling a user to take and make iPhone calls on their iPad; (ii) a feature called ‘Handoff’ enabling a user to write an email on their iPhone and continuing on their iPad; and (iii) a feature called ‘Universal Clipboard’ enabling a user to copy images, video or text from an app on their iPhone or iPad and paste into an app on another device.
(b) Apple’s cloud storage solution iCloud ‘is built into every Apple device’, which Apple characterises as providing ‘one powerfully connected experience’. Among other things, iCloud enables a user to access files and folders from the Files App on both iOS and iPadOS and keeps data on their iPhone and iPad automatically backed up.
(c) Each Apple device user has an Apple Account (formerly Apple ID) that gives them ‘access to all Apple services and makes all of [their] devices work seamlessly’. Apple specifically calls out iCloud and the App Store as services that users can access with their Apple Account.
4.150 Apple also markets iOS and iPadOS as tightly integrated with each other to app developers. Specifically, Apple recommends that developers building apps for iPadOS should ‘consider adding support for iOS at the same time’, noting that ‘iOS and iPadOS share many of the same technologies, making it easy to support both with the same executable.’
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Other responders, including OWA, were broadly supportive of grouping these activities into a single Mobile Platform activity.
The majority of third parties who commentedon the CMA’s proposal to group Apple’s digital activities into a single Mobile Platform activity were supportive, with several noting that a holistic approach is necessary to reflect the reality of Apple’s business model as an ecosystem. [...]
a consumer association (Which?) stated that, from a consumer perspective, although the digital activities may be ‘individually recognisable’ to users, it is only by using all of the digital activities in combination that users can make full use of their devices; [...]
similarly, a browser vendor (Mozilla) noted that if the activities were not grouped together as one digital activity, there is a danger of an enforcement gap, eg where the operation of Apple’s app store and/or the iOS operating system has an effect on mobile browsers.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
The CMA’s report also digs into Apple’s revenue and notes that increasing service revenue and service gross profit is growing in importance. Service revenue was a surprising 40% of gross profit in 2024.
While the majority of Apple’s revenue has historically come from device sales, the contribution and importance of Apple’s services business, which includes App Store and Safari, has been increasing steadily in recent years. Services accountedfor almost 25% of revenue in 2024, and almost 40% of gross profits. Apple’s services revenues include the fees earned by Apple from what Apple refers to as Third Party Licensing Arrangements, which is predominantly made up of its share of revenue from Google under the ISA as considered in Chapter 6; and the App Store, which is monetised through commission fees and advertising revenues.
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
This is important as the CMA’s mobile ecosystem market study identified competition in browsers reducing Apple’s Google ad revenue and competition from web apps reducing Apple’s app store revenue as powerful incentives for Apple’s restrictions on third-party browsers and web apps.
Apple receives significant revenue from Google by setting Google Search as the default search engine on Safari, and therefore benefits financially from high usage of Safari. [...] The WebKit restriction may help to entrench this position by limiting the scope for other browsers on iOS to differentiate themselves from Safari [...] As a result, it is less likely that users will choose other browsers over Safari, which in turn secures Apple’s revenues from Google. [...] Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
UK CMA - Interim Report into Mobile Ecosystems (emphasis added)
The CMA in their latest report note that innovations have been held back due to a lack of competition, directly citing Apple’s WebKit Restriction:
As set out in Appendix B, we note that Apple’s revenue mix has been increasingly shifting away from devices and towards services. Furthermore, there is evidence that innovations have been held back in mobile ecosystems due to a lack of competition.
454 The CMA’s previous work has identified a range of areas where innovations have been held back in Mobile Ecosystems due to a lack of competition. For example, the MBCG MI found that Apple’s ban on alternative browser engines in its Mobile Platform, and therefore the lack of competition faced by Apple’s WebKit browser engine, had materially limited the capabilities of mobile browsers and web apps.CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
This matters as competition is the primary driver of growth and innovation. Companies that, due to anti-competitive behaviour or some structural reason, do not face sufficient competition, are likely to raise prices and minimize expenditure beyond what is necessary to retain existing customers.
The CMA highlight that Apple can and does profitably forego innovation without fear of losing customers to competitors with this quote:
Apple’s vice president of iPhone marketing who explained in February 2020:‘In looking at it with hindsight, I think going forward we need to set a stake in the ground for what features we think are ‘good enough’ for the consumer. I would argue were [sic] already doing *more* than what would have been good enough.’ After identifying old features that ‘would have been good enough today if we hadn’t introduced [updated features] already’, she explained, ‘anything new and especially expensive needs to be rigorously challenged before it’s allowed into the consumer phone.’
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
The CMA has found that there are substantial barriers to users switching phone brands.
We have found substantial evidence from our consumer survey, internal documents (from both Apple and Google) and third-party responses of material perceived barriers to switching related to:
(i) learning costs associated with switching;
(ii) transferring data and apps across Mobile Devices; and
This is important, and lines up with a common argument about browser engines, which is “switch to Android if you wish to use other browser engines”. This of course misses the point in three important ways:
Consumers, in general, have low awareness of browsers, browser engines and web functionality, and are unaware how anti-competitive constraints on them are making the apps they use more expensive, of lower quality and of lower security. Even consumers who are acutely aware of Apple’s browser engine ban, face substantial and significant barriers to switching.
Businesses cannot choose where their customers are, and must support iOS, regardless of any lack of web functionality or browser competition.
Businesses who may wish to use web apps as a powerful and interoperable means of delivering apps to their customers are constrained from doing so due to a lack of critical features and significant bugs in iOS Safari. iOS Safari faces no effective competition. This constraint can even extend to Android, due to the loss of an effective cross platform interoperable web solution that also works on iOS.
Apple, while not denying the switching costs, argued that this does not imply weak competitive constraint on Apple’s Mobile Platform via alternatives:
Apple submitted that switching costs do not imply weak competitive constraints. The presence of switching costs may in some circumstances benefit customers by intensifying competition for new customers. However, this is much less likely to be the case in mature markets with large established players. In the case of mobile platforms, as already highlighted above, the vast majority of users are buying a replacement device and hence the pool of ‘new’ customers is relatively small compared to the pool of existing customers. Both Apple’s and Google’s strategies will therefore be largely driven by what is profitable in relation to the customers who are already within their mobile ecosystems. [...]
CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
Ultimately, and correctly in our opinion, the CMA concludes that: “Apple’s Mobile Platform faces only a limited constraint from other mobile platforms when competing for mobile end-users as a whole.”.
The CMA’s decision also notes a number of other competition authorities are looking into Apple’s mobile platform:
The CMA is far from the only authority considering these issues. Several competition authorities globally have taken action in relation to Apple’s Mobile Platform in recent years (including the US Department of Justice (DoJ), European Commission, Japan Fair Trade Commission (JFTC) and Australian Competition and Consumer Commission (ACCC)). Although our SMS investigation is focused on Apple’s activities in the UK, Apple’s Mobile Platform operates globally, and we have sought to learn from international findings in conducting our own investigation.CMA - SMS Investigation into Apple’s Mobile Platform - Final Decision (emphasis added)
We highlighted this in our response to the proposed decision:
We agree with the CMA’s assessment that the numerous court cases, antitrust investigations, and regulatory proceedings Apple faces in the EU, Japan, the USA, and Brazil do not indicate that Apple will voluntarily address these issues in the UK. On the contrary, they underscore the need for a code of conduct to govern Apple’s behaviour for at least the next five years.
We also concur that Apple’s exceptionally high profitability is unlikely to decline to a level that would call into question its designation as holding both entrenched market power (SEMP) and a position of strategic significance (POSS) in respect of its mobile platform. There is no evidence to suggest that its financial strength and overall control of its mobile platform within the UK will materially weaken to that degree within this period.
OWA - SMS Proposed Decision - Response (emphasis added)
# Mobile Ecosystems Study and Market Investigation Reference
The CMA has been investigating Apple’s restrictions on browsers and web apps for 4 years. This started on the 15th June 2021, when the UK’s Competition and Markets Authority (CMA) launched a market study into mobile ecosystems. This study correctly identified that Apple was undermining browser and web app competition via its ban on third-party browser engines.
Market Investigation References (MIRs) are only started when the CMA has “reasonable grounds for suspecting that a feature or combination of features of a market or markets in the UK prevents, restricts, or distorts competition”. They are a significant and expensive undertaking:
Full market investigation references tend to be used only in cases where competition problems are considered to be particularly significant and/or warrant further detailed investigation, and where the stronger and more wide ranging powers available to the CMA are considered to be more appropriate.
Ashurst - Guide to the use of market studies in UK competition law (emphasis added)
Upon having confirmed the adverse impact on competition, MIRs are intended to fix the issue:
Following a market investigation, the CMA can take remedial action itself through exercising its order - making powers or by accepting undertakings from relevant parties. Alternatively, it can recommend (but not require) that remedial action should be taken by others such as government, regulators and public authorities. Section 134(6) of the EA02 requires the CC [Competition Commission] to take into account the following in considering potential remedial action: "the need to achieve as comprehensive a solution as is reasonable and practicable to the adverse effect on competition and any detrimental effects on customers so far as resulting from the adverse effect on competition".Ashurst - Guide to the use of market studies in UK competition law (emphasis added)
(a) allow the use of alternative browser engines on iOS – by removing current clause 2.5.6 from Apple’s App Review Guidelines, which requires third-party browsers to use WebKit, and refraining from introducing any guidelines with similar effect in the future; and (b) provide ‘equivalent access’ to iOS as that which WebKit, Safari or third-party applications have to iOS on fair, reasonable and non-discriminatory (FRAND) terms to browser vendors choosing to use browser engines other than WebKit (‘alternative browser engines’).
High-level parameters that could be used to assess equivalence of access to functionality include:
(a) enabling access in a way which respects the technical architecture of alternative browser engines;
(b) enabling access to all of the current operating system-level features and functionalities that WebKit and Safari currently use;
(c) enabling access to all other current operating system-level features and functionalities that exist on iOS and are available for use by third-party applications, but which WebKit and Safari currently do not use;
(d) enabling access to future operating system-level features and functionalities available to WebKit, Safari, or third-party applications, whether or not WebKit and Safari choose to use them;
(e) enabling access to the required iOS functionality to allow browser vendors using alternative browser engines to install and manage progressive web apps (PWAs) using alternative browser engines; and
(f) enabling access to the required functionality to allow browser vendors using alternative browser engines to check whether their mobile browser has been set as default.
MIR - Final Decision - Appendix D
The MIR team also explained in extensive detail that they decided that deferring these remedies to be implemented under the DMCC was the fastest and legally safest path forward.
...we remain of the view that a recommendation to the CMA Board to use the new DMCC Act powers is an effective and comprehensive remedy to address the AECs [Adverse Effect on Competition] we have identified. [...]
In any event, we do not consider that interventions which the CMA may decide to impose under the DMCC Act powers would necessarily take significantly longer to implement than the remedies which could be imposed via the EA02 remedy-making powers. [...]
We consider that the likelihood of the CMA Board acting on our recommendation
in a timely manner is high. [...]
Taking all the above considerations into account, we conclude that a recommendation to the CMA Board in the manner expressed in the Our remedy sub-section above is the most appropriate way to address effectively and comprehensively the AECs we have identified.MIR - Final Decision (emphasis added)
This matters, as it means that the SMS investigation is not happening in a vacuum. The UK government has spent considerable effort investigating Apple on this topic over the past four years. These investigations have consistently identified anti-competitive behaviour by Apple that is suppressing both browser and web app competition on iOS, and now the CMA has the power under this designation to fix the wrongs that both the mobile ecosystem investigation and the mobile browsers and cloud gaming market investigation reference identified.
Fortunately, the SMS investigation team appears to be moving decisively in that direction. They directly included a number of these already identified remedies in their SMS investigation. However, as a competition regulator, the CMA must follow a formal process of consultation before enforcing such remedies. According to the CMA’s roadmap, the consultation covering browsers, browser engines and web apps is expected to begin in the first half of 2026.
Allowing browsers and web apps to compete fairly on all operating systems will bring some significant advantages to consumers and businesses:
The web could offer a true alternative to today’s mobile app stores as it has on desktop for the last two decades. It is open, interoperable, and free from proprietary fees or a 30% cut for the operating system. This interoperability lowers costs for developers, raises quality, reduces barriers to entry for smaller teams and fuels greater innovation across the industry.
When developers have real alternatives, app stores must work harder to retain their users and developers. This could lead to lower fees, faster reviews, fairer terms and better overall service for both developers and consumers.
Competition would push Safari to improve its stability, compatibility, and features. With multiple browsers able to compete freely with their own engines, users benefit from faster innovation, higher quality, better security and higher stability. Currently Safari faces no effective competition on iOS.
Lowering the barriers to web-based apps could finally make it viable for a third mobile operating system to emerge, breaking the current duopoly.
When the web thrives, everyone benefits. Regulators have the power to make this a reality, but they need strong evidence and support from developers and companies that depend on the web.
Stay tuned for updates on the CMA’s upcoming investigation into browsers and web apps, starting in the first half of next year. We’ll share more details as they become available.
]]>
OWA at the EU Parliament DMA Working Group2025-10-10T00:00:00Zhttps://open-web-advocacy.org/blog/owa-at-the-eu-parliament-dma-working-group/
Last week, OWA was invited to attend and give a short speech on our views of Apple’s compliance with the Digital Markets Act (DMA) at a meeting with the Working Group on the Implementation of the Digital Markets Act.
The Working Group on the Implementation of the Digital Markets Act is a body within the European Parliament that monitors, scrutinises, and reports on how the DMA is being put into practice. It is currently chaired by Member of the European Parliament Andreas Schwab.
Hi all, pleasure to be here, I’m Alex Moore, the Executive Director of Open Web Advocacy.
Open Web Advocacy is a global non-profit, made up of software engineers, that works to make sure the Web can compete fairly on all platforms.
The open web is essential to a free European society. It enables every EU consumer and business to connect and transact without living under the thumb of tech giants. Its strength is that it is ubiquitous, built on open standards and free from gatekeeper control. If you want to reach users on every device without gatekeepers telling you how to run your business, the web is your only choice.
Luckily, the EU already has the answer: the Digital Markets Act. Article 5(7) of the Act clearly and explicitly prohibits Apple’s browser engine ban with the aim of preventing Apple from artificially limiting web software applications speed, performance and functionality.
That is, the DMA explicitly aims to allow the Web to compete fairly.
Apple, however, is taking a belligerent and obstructionist approach to the DMA. With a three trillion dollar market value and over 1 billion dollars a year in legal spending, Apple has legal power that outstrips that of small nations. It is also not afraid to step as close to the line of non-compliance as possible. As Apple’s former general counsel Bruce Sewell explained, the strategy when he was at Apple was to steer as close to the line as possible because “that’s where the competitive advantage occurs”, and even large fines are seen as acceptable costs.
This means that EU consumers and EU businesses lose. They lose by having lower quality, less interoperable browsers with poorer support for web apps. This in turn denies a competitor to both Apple’s and Google’s app stores, which raises costs and lowers quality, and damages security and privacy across the entire mobile app ecosystem.
Apple may claim that competition laws block innovation, but most innovation comes from small tech, not the monopolists. At one point Apple was an incredible innovator, but that time is long past. Apple hasn't had a hit new product in over a decade.
They now extract additional revenue from devices they have already sold to consumers at incredibly profitable margins, not by merit, but by the ability to block any form of installation that does not go via their app store, in some cases blocking competitors altogether.
Their fastest growing revenue source is services, that they either self-preference or simply block others from competing with.
Apple has threatened to withhold functionality, such as Apple Intelligence or AirPods Live Translate. Regardless of what they ship, Apple must not be allowed to prevent other companies from filling the demand.
Interoperability is the key to allowing this. If Apple is unable or unwilling to ship a new feature or service in the EU, then European companies must be allowed to fill that gap.
In reality this is a bluff. Some features Apple claims to be holding back, like Apple Intelligence, have beenwidely criticizedas notactually working. And while Apple may sometimes delay the occasional token feature in order to suggest that competition laws create problems for EU users, Apple is not going to give up its strong position to competitors, nor will it seriously risk damaging its profitable iPhone sales in the EU.
To ensure the Digital Markets Act delivers on its promise, the EU should:
Keep supporting and enforcing the DMA.
Prioritize competition and interoperability as the main drivers of growth and innovation.
Significantly increase the DMA enforcement budget to allow more open cases.
Investigate the deliberate slow-walking and delays in compliance and update the DMA to deter these tactics.
And finally, don't be afraid to fine these tech giants when they blatantly circumvent EU law.
These fines must be meaningful, not just a manageable business expense for the world’s largest companies. The DMA will succeed only when it's clear to these gatekeepers that true lasting compliance is the best and only path to their achieving their goal of profit maximization.
Alongside many other civil society organisations, OWA stands firmly behind the DMA and behind the fair, open digital future it represents.
Apple’s representatives have argued that browser vendors can port their own engines to iOS in the EU and at a highly superficial and technical level this is true. However, what Apple does not acknowledge is that the conditions it imposes make doing so financially unviable in practice. Does this really count as compliance?
To answer that, we need to examine the DMA itself. The primary relevant article in the Digital Markets Act is Article 5(7):
The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services.Article 5(7) - Digital Markets Act (emphasis added)
At face value, Apple appears to have complied with the letter of Article 5(7). It technically allows third-party engines, but only under technical platform constraints and contractual conditions that render porting non-viable. But the DMA demands more than surface-level compliance
The gatekeeper shall ensure and demonstrate compliance with the obligations laid down in Articles 5, 6 and 7 of this Regulation. The measures implemented by the gatekeeper to ensure compliance with those Articles shall be effective in achieving the objectives of this Regulation and of the relevant obligation.
Article 8(1) - Digital Markets Act (emphasis added)
The gatekeeper shall not engage in any behaviour that undermines effective compliance with the obligations of Articles 5, 6 and 7 regardless of whether that behaviour is of a contractual, commercial or technical nature, or of any other nature, or consists in the use of behavioural techniques or interface design.
Article 13(4) - Digital Markets Act (emphasis added)
These two articles clarify that it is not enough for Apple to simply allow alternative engines in theory. The measures must be effective in achieving the article’s objectives, and Apple must not undermine those objectives by technical or contractual means.
The intent of Article 5(7) is laid out clearly in the recitals of the DMA:
In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users.
Recital 43 - Digital Markets Act (emphasis added)
In other words, Apple should not be in a position to dictate what features, performance, or standards in competing browsers and web apps they power. That is, the intent is to guarantee that browser vendors have the freedom to implement their own engines, thereby removing Apple’s ability to control the performance, features, and standards of competing browsers and the web apps built on them.
So is Apple complying in practice?
Fifteen months since the DMA came into force, no browser vendor has successfully ported a competing engine to iOS. The financial, technical, and contractual barriers Apple has put in place remain insurmountable. These restrictions are not grounded in strictly necessary or proportionate security justifications.
This is not what effective compliance looks like. Article 5(7)’s goals, enabling engine-level competition and freeing web apps from Apple’s ceiling on functionality and stability, have not been met. Under Article 8(1) and Article 13(4), that makes Apple non-compliant.
The EU Commission has imposed an interoperability process on Apple due to a repeated failure by Apple to both share reserved functionality and a slow-walking of existing requests.
Apple informed the Commission that it has moved some of the aforementioned requests to 'the next phase of the interoperability process.' (11) (12) At the same time, Apple is 'still undertaking an assessment' of other interoperability requests made pursuant to Article 6(7) of Regulation (EU) 2022/1925 and has not yet moved these to the 'next phase' of Apple’s own review process.
Decision to a Specification Proceeding into Apple for Connected Devices (emphasis added)
For example, in relation to interoperability for third-party devices, Apple slow-walked their request process for over 9 months. The requests mentioned date back as far as March 2024, yet Apple neither implemented nor formally rejected them.
Under the new process, third parties have the right to file interoperability requests with Apple under Article 6(7) of the DMA. These requests can be for any software or hardware feature available on iOS and iPadOS. This includes even subsets of features, i.e. if Apple is reserving a better version for its own apps, services or devices, as well as, third-party devices interoperating with iOS or iPadOS.
Phase I – Eligibility phase: Apple assesses the eligibility request to ensure that the requests fit within the scope. Must be completed within 20 days.
Phase II – Project Plan: The Project Plan should be completed by Apple within 40 working days, starting from the end of phase I. Apple should communicate the project plan to the developer who will have the opportunity to provide its feedback on it.
Phase III – Development: to establish a predictable and reliable timeline for the development phase. Apple should develop interoperability solutions that require minor, mild, and significant efforts within 6, 12, or 18 months from the submission of the interoperability request, respectively.
Under the DMA, Apple can attach security measures when it opens up access to a particular feature in order to protect the integrity of the operating system. However, these must be justified by Apple and must be objective. This document has a lot of discussion as to exactly what this means.
If you are a third-party company or developer that requires functionality that Apple currently reserves for itself in the EU to make your apps or devices better (or possible), then you can follow this process and make an interop request. All of these requests can be done at a non-legal technical level, as just polite technical requests for required functionality. Apple is not allowed to ignore these requests and must respond in writing within the above time limits.
With 128 million affected users and 2,500 compromised apps, it qualifies as both successful and widespread.
It is impossible to believe that the authors and reviewers of Apple’s statement were unaware of what is likely the largest and most significant malware attack in iOS history.
Even if Apple were to claim this was an honest error, which they have not, they have known about this for at least a week and have yet to correct their article.
XcodeGhost iOS malware, discovered in September 2015, spread through altered copies of Apple’s Xcode development environment, and, when iOS apps were compiled, third-party code was injected into those apps. Users downloaded infected apps from the iOS app store.
Documents revealed during the 2021 Epic Games v. Apple trial (still ongoing) show that 128 million users downloaded the more than 2,500 infected apps, about two thirds of these in China. Popular apps such as WeChat, Didi Chuxing, and Angry Birds 2, among others, were infected by XcodeGhost. These are some of the largest native apps in the world, being the equivalents of Facebook and Uber in China. WeChat, for example, has 1.36 billion users.
Apple's app review process failed spectacularly in the case of the XcodeGhost malware. This highlights the inherent limitations of app review as it's impractical for human reviewers (reportedly only 500 reviewers to review 130,000 apps per week, with only a few minutes spent per app ) to scrutinize the vast amounts of code submitted for each app and these reviewers likely did not even attempt to do so.
Even with the assistance of automated code scanning tools, which can be circumvented by various obfuscation techniques, complex malware like XcodeGhost, injected during the compilation process, can easily slip through contributing to ongoing unresolved issues with malware, phishing apps, and fleeceware in both Apple and Google’s app stores over the past 16 years.
Apple internal email considering informing users of breach.
Apple discussed contacting users and briefly made an announcement on their China website. To our knowledge, Apple never contacted users to inform them of the breach.
this decision to not notify more than 100 million users about potential security issues seems to have more to do with protecting the platform’s reputation than helping users stay safe
Kirk McElhearn - Intego (emphasis added)
Alas, all appearances are that Apple never followed through on its plans. An Apple representative could point to no evidence that such an email was ever sent. Statements the representative sent on background—meaning I’m not permitted to quote them—noted that Apple instead published only this now-deleted post.
Dan Goodin - ArsTechnica
What makes this example particularly egregious is the failure to notify users. Every company will have a security breach at some point in its history, but how those breaches are handled and whether the company considers customer safety or company reputation to be more important is an interesting peek into that company's psychology when it comes to security.
the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines.
[...]
Overall, the evidence we have received to date does not suggest that Apple's WebKit restriction allows for quicker and more effective response to security threats for dedicated browser apps on iOS
CMA - Commenting upon Apple’s Arguments
Apple self-preferences itself by exempting itself from its own privacy rules, by arguing that its tracking for the purpose of advertising, is not tracking, as Apple is “first-party”. The UK’s competition and markets authority cover this extensively in their reports:
Apple offered the following definition of ‘tracking’ which it said was consistent with that of the World Wide Web Consortium (W3C): ‘Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers.’ As detailed in Appendix J, Apple does not consider the processing activities it undertakes in terms of personalised advertising (ie use of first-party data from different Apple apps and services) as ‘tracking’, particularly as it does not link information collected by apps from different companies, and therefore its apps are not required to show the ATT prompt. This is factually correct, given that, as detailed above, Apple uses data it collects from its own services which it operates under a single corporate ownership for personalised advertising purposes.
However, as further discussed in Appendix J, based on our consideration of the ICO’s definition of online tracking, which does not distinguish between first-party and third-party data, we consider Apple’s own use of its users’ personal data no less consistent with this description of ‘tracking’ than that of third-party developers.
CMA - Mobile ecosystems - Market Study Final Report
Apple does, however, use its first-party data from across multiple Apple apps for advertising purposes. For instance, Apple processes a user’s App Store purchase history, together with other demographics, to personalise App Store Search Ads and advertising displayed in the News and Stocks apps.
CMA - Appendix I: considering the design and impacts on competition of Apple’s ATT changes
With regards to targeting, Apple’s advertising services are advantaged by the distinction made between first-party and third-party data sharing in the ATT framework which gives Apple licence to use a wide range of data that it treats as ‘first-party’, potentially coming from a range of Apple’s different apps and services as well as from user activity within third-party apps. Moreover, the differences between the ATT prompt and the Personalised Ads prompt discussed above make it in principle easier for Apple to be able to access user data to target its ads, relative to third parties. CMA - Mobile ecosystems - Market Study Final Report
Apple pulls in an astonishing amount from advertising. From non-Google ad revenue alone, Apple is estimated to have earned $10.34 billion in 2024.
While the iPhone maker does not disclose its advertising revenue separately, analytics firm eMarketer estimates Apple's ad revenues could total $10.34 billion in 2024.
Arsheeya Bajwa, Harshita Mary Varghese - Reuters
Lastly, the Autorité found an asymmetry in how Apple treated itself and how publishers were treated. While publishers were required to obtain double consent from users for tracking on third-party sites and applications, Apple did not ask for consent from users of its own applications (until the implementation of iOS 15). Due to this asymmetry, the CNIL fined Apple for infringing Article 82 of the French Data Protection Act, which transposes the ePrivacy Directive.
[...]
In view of the seriousness of the facts, the duration of the infringement (between 26 April 2021 and 25 July 2023) and Apple’s economic power, the Autorité has decided to impose a fine of €150,000,000 on Apple Distribution International Limited (ADI) and Apple Inc., as perpetrators, and Apple Operations International Limited and Apple Inc., as parent companies.
Authorite de la Concurrence
Privacy advocate Cory Doctorow, author and special advisor at the Electronic Frontier Foundation (EFF), has been sharply critical of Apple’s approach to privacy.
Meta announced on Wednesday that data collected from user interactions with its AI products will soon be used to sell targeted ads across its social media platforms.
The company will update its privacy policy by December 16 to reflect the change and will notify users in the coming days. The new policy applies globally, except for users in South Korea, the United Kingdom, and the European Union, where privacy laws prevent this type of data collection.
Maxwell Zeff - TechCrunch
Apple is highly unlikely to risk harming its bottom line by undermining its lucrative European iPhone sales. EU consumers should be commended for recognizing these tactics for what they are: a calculated attempt by a major tech company to portray competition regulation as harmful to consumers. In reality, Apple’s resistance stems from its desire to avoid interoperability and competition rules that could weaken its long-term strategy of ecosystem lock-in and open the door to fair competition.
With fewer groundbreaking innovations each year, Apple has increasingly relied on pre-announcing ambitious products that are often incomplete or unavailable at launch. This shift has drawn criticism from longtime Apple observers who note the company’s growing disconnect from its once product-driven ethos. As John Gruber of Daring Fireball put it:
The Apple of the Jobs exile years — the Sculley / Spindler / Amelio Apple of 1987–1997 — promoted all sorts of amazing concepts that were no more real than the dinosaurs of Jurassic Park, and promised all sorts of hardware and (especially) software that never saw the light of day. Promoting what you hope to be able to someday ship is way easier and more exciting than promoting what you know is actually ready to ship. [...]
Tim Cook should have already held a meeting like that to address and rectify this Siri and Apple Intelligence debacle. If such a meeting hasn’t yet occurred or doesn’t happen soon, then, I fear, that’s all she wrote. The ride is over. When mediocrity, excuses, and bullshit take root, they take over. A culture of excellence, accountability, and integrity cannot abide the acceptance of any of those things, and will quickly collapse upon itself with the acceptance of all three.
John Gruber - Daring Fireball (emphasis added)
The problem for Apple, however, is not simply that “Apple Intelligence” is unavailable in the EU, it’s that it doesn’t work very well. Despite being marketed as the headline feature of the iPhone 16, the system has failed to meet even modest expectations.
The complaints, consolidated in the US District Court for the Northern District of California, alleged that Apple tricked consumers into buying new iPhone 16s by touting state-of-the-art artificial intelligence features the company knew it couldn’t deliver.
The company promoted new features under its “Apple Intelligence” suite to be unveiled with the iPhone 16 line, including an enhanced Siri function that was the centerpiece of Apple’s annual Worldwide Developers Conference in June 2024, the complaint said.
Shweta Watwe - Bloomberg Law
Beyond legal troubles, Apple Intelligence has also failed spectacularly on several occasions for features meant to summarize news or notifications.
Or more disturbingly in December 2024, Apple’s AI-powered summary falsely made it appear that BBC News had published an article claiming Mangione, the man accused of the murder of healthcare insurance CEO Brian Thompson in New York, had shot himself. He had not.
Incorrect Apple Intelligence Summary of BBC News
The EU thankfully was spared these issues due to Apple deciding not to roll out the product in the region.
EU policymakers should not fear being left behind without Apple’s newest features and services. What should truly concern EU policy makers is that European consumers and developers remain deprived of third-party innovations, apps and services that Apple continues to block from competing fairly on iOS.
The DMA already provides the tools to fix this. Interoperability is the key. What’s needed now is the determination, resources, and political will to enforce it fully.
]]>
Can Perplexity Afford to Fund the Web? The $34.5 Billion-Dollar Question2025-08-13T00:00:00Zhttps://open-web-advocacy.org/blog/can-perplexity-afford-to-fund-the-web/TL;DR: AI startup Perplexity has made a $34.5 billion bid to acquire Chrome, despite previously opposing its divestiture from Google and arguing no other company could run it effectively. We are concerned that this sale could lead to a 70% plunge in web platform investmentand that Perplexity has neither the means nor incentive to fund the web platform to the same level as Google. This outcome would further strengthen the anti-competitive grip of Apple and Google’s native platforms at the expense of the open web.
This is also at odds with statements made by Perplexity earlier this year where they essentially said the opposite, stating that Chrome should not be sold as no other party would be able to run the browser at that scale without a hit on quality, nor would they have the business model:
Google should not be broken up. Chrome should remain within and continue to be run by Google. Google deserves a lot of credit for open-sourcing Chromium, which powers Microsoft's Edge and will also power Perplexity's Comet. Chrome has become the dominant browser due to incredible execution quality at the scale of billions of users.
The DOJ is pushing for Chrome to be divested from Google. We don't believe anyone else can run a browser at that scale without a hit on quality, nor the business model to be able to serve that many users profitably by keeping the browser free. Chromium is open source, and others can build using that. Evidence: Microsoft Edge and Perplexity's upcoming Comet browser. [...]
The remedy that is right in our opinion is not a breakup of Google; but rather offering consumers the choice to pick their defaults on Android without feeling the risk of a loss in revenue. That's what we will be proposing.
So why has Perplexity changed their mind and why do they want to buy Chrome and Chromium now?
# Why does Perplexity want to buy Chrome and Chromium?
The most obvious motivation is user acquisition. Chrome has over a 1000x the user base of Perplexity. Perplexity reportedly has fewer than 3 million daily users, compared to Chrome’s 3.45 billion. Even capturing a small percentage of that user base through this acquisition would represent a massive boost, something they could show to investors.
While Perplexity has a steadily growing userbase, this acquisition would catapult them to be the largest AI company by active users on the planet.
Even Perplexity’s earlier statement shows that they shared our concern.
Our primary concern is whether Perplexity would have both the means and the incentiveto continue funding Chromium, the browser engine that powers Chrome, Edge, Opera, Vivaldi, Brave, and numerous smaller browsers. Beyond browsers, Chromium and its underlying technologies power a wide range of native apps and are critical to the server-side infrastructure of many of the world’s highest-traffic applications.
Given that Perplexity would need to borrow heavily to finance such an acquisition, and given they would gain access to Chrome’s user base regardless of their level of web platform investment, it’s unclear whether they would be willing or able to sustain the current ~$1 billion USD annual investment in web platform development that Google is doing.
Since the primary justification for these remedies is to prevent actions that would inadvertently dismantle the funding that sustains the web platform, it is both logical and essential that they include concrete safeguards to ensure that goal is actually met. For this reason, we have proposed measures such as minimum reinvestment requirements for any revenue derived from Google search deals, so that these remedies not only avoid harm, but actively support the long-term health of the web platform.
Our goal is not to weaken the DOJ’s case or shield Google. The anticompetitive behavior must be addressed, but the remedies must not destroy the very ecosystem that Google itself indexes.
We appreciate that the DOJ have listened to us and other concerned parties, and made this small change in its Revised Final Judgment Proposal , which now requires an evaluation of the buyer’s business and investment plans, including those for the open-source Chromium project:
The evaluation of any potential buyer shall include the potential buyer’s proposed business and investment plans (including those for open-source project Chromium), the United States’ evaluation, at its sole discretion, of any potential risks to national security, the potential buyer’s plans for sharing and protecting user data included in the acquisition, and any other issues a potential buyer may present.
Plaintiffs’ Revised Proposed Final Judgment (emphasis added)
However, while this is a step in the right direction, it still falls short. If the DOJ is serious about ensuring a viable sale, it should require a minimum annual funding commitment of at least 50% of Google's average annual investment in Chromium over the past five years. Anything less would tacitly admit that a significant drop in web platform funding is expected and that no viable buyer who will adequately fund the web platform exists.
Open Web Advocacy (OWA) is an independent non-profit dedicated to promoting fair competition in both browsers and web apps. We receive no funding from browser vendors, search engine providers, or any companies involved in this case, nor do we advocate on their behalf. Our work is focused entirely on defending the interests of consumers, developers, and the open web.
Our interest in this case is driven by concern over the potential unintended consequences of some of the DOJ’s proposed remedies, and the broader impact these measures could have on the health of the web and the millions of developers and billions of consumers who rely upon it.
]]>
Japan: Apple Must Lift Browser Engine Ban by December2025-08-06T00:00:00Zhttps://open-web-advocacy.org/blog/japan-apple-must-lift-engine-ban-by-december/
Readers may recall that Japan recently passed the Smartphone Act, officially the Bill on the Promotion of Competition for Specified Software Used in Smartphones. Among its most important reforms is a direct prohibition on Apple’s long-standing ban on third-party browser engines on iOS.
This ban has functioned as an effective ban on browsers like Firefox, Chrome, Edge, Opera, Brave & Vivaldi, by forcing them to use Apple’s WebKit engine, which they cannot modify or control. This results in no effective browser competition on iOS, and web apps being deprived of the APIs and performance they need to compete with native apps.
Last week, Japan published the Mobile Software Competition Act (MSCA) Guidelines. These subordinate rules clarify how the Act will be interpreted and enforced. Here's what they mean for browser competition.
# Ban on Blocking or Hindering Alternative Browser Engines
The guidelines explicitly prohibit any measures that would prevent or hinder the adoption of third-party browser engines:
Actions that "Prevent" the Adoption of Alternative Browser Engines"
Such actions may include: imposing unreasonable technical restrictions on individual app providers while allowing them to adopt alternative browser engines, placing excessive financial burdens on individual app providers for adopting alternative browser engines, and steering smartphone users away from using individual software that incorporates alternative browser engines.
The determination of whether a designated provider's action constitutes "preventing" the adoption of alternative browser engines does not require that it be completely impossible for individual app providers to adopt alternative browser engines. Instead, the determination is made based on the degree of likelihood that such a result will occur. Mobile Software Competition Act Guidelines
(emphasis added)
This clause is crucial. It means that designated providers (i.e. Apple) must not only eliminate outright bans (like App Store Guideline 2.5.6), but must also refrain from practices that, while technically permitting browser engines, render their use impractical or commercially unviable.
The MSCA also mandates fair access to OS APIs, mirroring Article 6(7) of the EU DMA. For browsers this is particularly critical as they need extensive access to a broad range of APIs typically reserved for Safari and WebKit.
Article 7, Item 2 of this Act prohibits designated providers of basic operation software from preventing other businesses (businesses other than designated providers, etc.) from using OS functions with equivalent performance for the provision of individual software, when such OS functions are used by the designated provider, etc., to provide individual software. By prohibiting actions that prevent other businesses from using OS functions with equivalent performance as utilized by designated providers, etc., for the provision of individual software, this Item aims to promote competition regarding individual software. Mobile Software Competition Act Guidelines
(emphasis added)
The act does specify that alternative APIs are allowed. However it clarifies that they may not be materially inferior.
However, for example, if other businesses are allowed to use that OS function for individual software provision using a technical method different from that used by designated providers, etc., but the performance is materially inferior to that when designated providers, etc., use that OS function for individual software provision, it does not constitute "other businesses using the equivalent performance to provide individual software". Mobile Software Competition Act Guidelines
(emphasis added)
The act also mandates choice screens for browsers among other items. Importantly it specifies that the choice screen must display “Promptly after the first activation", an important improvement on the EU’s Digital Markets Act.
that smartphone users must be made to select a specific individual software from the options displayed on the choice screen promptly after the first activation of the smartphone by the user. "Promptly after the first activation" refers to, for example, displaying the choice screen at the time of initial setup after the first activation of the smartphone, or displaying the choice screen at the time of the first launch of the individual software subject to the choice screen, and making users select a specific individual software from the options. Mobile Software Competition Act Guidelines
(emphasis added)
The Mobile Software Competition Act is expected to come into force by December 2025. With Japan joining the EU and UK, there are now three jurisdictions where Apple will be required to permit browsers to run their own engines. As Japan prepares for enforcement, it is likely studying the regulatory approaches and challenges already unfolding in Europe and the UK.
Now that Japan, the EU, and the UK all require Apple to support third-party browser engines, 2026 may become the decisive year in restoring browser competition on iOS. But much depends on regulators’ resolve, and on Apple’s willingness to comply in substance, not just form.
We’d like to extend our gratitude to the extensive work over many years by the HDMC, JFTC and others in improving browser, browser engine and web app competition.
]]>
UK Regulator Flags Apple’s iOS Browser Engine Ban in Draft SMS Designation2025-07-23T00:00:00Zhttps://open-web-advocacy.org/blog/uk-regulator-flags-apples-ios-browser-engine-ban-in-draft-sms-designation/TL;DR: The UK regulator has provisionally found that Apple and Google meet the threshold for Strategic Market Status (SMS) under the DMCC. In Apple’s case, the decision highlights its ban on competing browser engines and its actions to suppress competition from web apps.
A proportionate, pro-innovation approach*
The UK’s new digital markets competition regime can help unlock opportunities for innovation and growth, by promoting competition in digital markets while protecting UK consumers and businesses from unfair or harmful practices. To support pace and provide greater predictability for Apple and Google and other market participants, the CMA has published roadmaps outlining how it would prioritise actions taken during the first half of any designation period.
UK CMA
The report highlights the lack of competition for Apple’s WebKit on iOS:
On Apple mobile devices, all mobile browsers are required to use Apple’s WebKit browser engine (ie as a result of the WebKit restriction), as specified in Apple’s App Store Review guidelines. Apple therefore does not face competition from rival mobile browser engines on its Mobile Ecosystem. This position will not change unless Apple lifts its total prohibition on the use of alternative browser engines on its Mobile Ecosystem.SMS Investigation into Apple’s Mobile Platform - Proposed Decision
The report also highlighted that web apps are not a competitive substitute due to Apple’s restrictions:
Specifically, 58 of 108 content providers we gathered evidence from indicated that web apps are not a viable substitute to the native apps, and a number of these content providers indicated that substitutability is particularly limited in terms of functionality and discoverability, which are important factors for app developers’ distribution choices. Several content providers further submitted that functionality issues with web apps are due to restrictions that Apple has imposed on web browsers within its Mobile Ecosystem.
SMS Investigation into Apple’s Mobile Platform - Proposed Decision
# Will Strong Enforcement of Pro-Competition Laws Help or Hinder Startups?
Recent calls for the Competition and Markets Authority (CMA) to be “more pro-business” appear to suggest that the UK should ease up on enforcing rules against some of the world’s most powerful companies. Former Chancellor Jeremy Hunt went so far as to publicly admonish the CMA, urging regulators to “understand their wider responsibilities for economic growth”.
But this framing is backwards. Weakening enforcement of competition rules does not drive growth, quite the opposite. Economists overwhelmingly agree that turning a blind eye to anti-competitive behaviour entrenches monopolies, stifles innovation, and ultimately harms consumers and startups alike.
It seems like the UK now welcomes monopolies provided they have an investment story. There’s something really topsy-turvy about this.
Former CMA Regulator
The idea that easing pressure on gatekeepers will help startups is fundamentally flawed. In reality, failing to curb the control dominant firms exert over their platforms, especially through blocking competition, actively harms smaller players and undermines the interests of the UK public.
This is not about targeting American companies. Enforcing competition rules helps American firms just as much as it helps British and European ones:
For US negotiators to carve out exemptions for American companies now would defang the DMA and stall its pro-competition benefits just as they begin to be felt. [...] The victims of a DMA pause would be America's most innovative upstarts — especially AI start-ups. The DMA's interoperability and fairness rules were designed to pry open closed platforms and give smaller companies a fighting chance. [...] Big Tech lobbyists portray the DMA as anti-American. In reality, the DMA's goals align with American ideals of fair competition. This isn't Europe versus America; it's open markets versus closed ones.
Luther Lowe - Y Combinator - Head of Public Policy (emphasis added)
In fact, the three major companies leading efforts to bring competing browser engines to iOS, Google, Mozilla, and Microsoft, are themselves American. Many of the smaller browser vendors relying on those efforts are American too. Apple's restrictive policies don't just harm consumers and developers, they harm other US tech firms as well. These policies benefit no one but Apple, which makes billions annually by locking down browser and web app competition on iOS.
Let’s be clear: Apple stands alone in banning competing browser engines and suppressing web app innovation on its platform. No other gatekeeper in the market enforces such a blanket restriction.
If the UK government is serious about supporting business, it must back the CMA in enforcing pro-competition rules decisively, especially when those rules are essential to giving startups and smaller companies a fair shot at innovation and growth.
The web, as the world’s most open and widely used platform, is central to that opportunity. But its future depends on real competition at the engine level, across every operating system.
Being pro-growth means being pro-competition. Undermining enforcement does nothing but shield entrenched incumbents and stifle the very innovation the UK claims to champion.
The CMA is consulting on these provisional designations ahead of final decisions in October. Should Apple or Google be designated, they expect to begin consulting on a first set of interventions from autumn 2025.
]]>
Apple's Browser Engine Ban Persists, Even Under the DMA2025-07-14T00:00:00Zhttps://open-web-advocacy.org/blog/apples-browser-engine-ban-persists-even-under-the-dma/TL;DR: Apple's rules and technical restrictions are blocking other browser vendors from successfully offering their own engines to users in the EU.
At the recent Digital Markets Act (DMA) workshop, Apple claimed it didn't know why no browser vendor has ported their engine to iOS over the past 15 months. But the reality is Apple knows exactly what the barriers are, and has chosen not to remove them.
Safari is the highest margin product Apple has ever made, accounts for 14-16% of Apple's annual operating profit and brings in $20 billion per year in search engine revenue from Google. For each 1% browser market share that Apple loses for Safari, Apple is set to lose $200 million in revenue per year.
Ensuring other browsers are not able to compete fairly is critical to Apple's best and easiest revenue stream, and allows Apple to retain full control over the maximum capabilities of web apps, limiting their performance and utility to prevent them from meaningfully competing with native apps distributed through their app store. Consumers and developers (native or web) then suffer due to a lack of competition.
This browser engine ban is unique to Apple and no other gatekeeper imposes such a restriction. Until Apple lifts these barriers they are not in effective compliance with the DMA.
We had the opportunity to question Apple directly on this at the 2025 DMA workshop. Here's how they responded:
As a quick background to new readers, we (Open Web Advocacy) are a non-profit dedicated to improving browser and web app competition on all operating systems. We receive no funding from any gatekeeper, nor any of the browser vendors. We have engaged with multiple regulators including in the EU, UK, Japan, Australia and the United States.
We engaged extensively with the UK's CMA and the EU on this topic and to our delight specific text was added to the EU's Digital Markets Act explicitly prohibiting the banning of third-party browser engines, and stating that the purpose was to prevent gatekeepers from determining the performance, stability and functionality of third-party browsers and the web apps they power.
The first batch of designated gatekeepers Apple, Google, Meta, Amazon, ByteDance, Microsoft were required to be in compliance with the DMA by March 7th, 2024.
Both Google and Mozilla began porting their browser engines Blink and Gecko respectively to iOS. Other browser vendors are dependent on these ports to bring their own engines to their browsers on iOS, as their products are typically soft forks (copies with modifications) of Blink or Gecko.
However there were significant issues with Apple's contract and technical restrictions that made porting browser engines to iOS "as painful as possible" for browser vendors:
Apple's proposals fail to give consumers viable choices by making it as painful as possible for others to provide competitive alternatives to Safari [...] This is another example of Apple creating barriers to prevent true browser competition on iOS.
Damiano DeMonte - Mozilla
Many of Apple's barriers rely on vague security and privacy grounds for which Apple has published no detailed technical justification for both their necessity and proportionality. As the US's Department of Justice wrote in their complaint:
In the end, Apple deploys privacy and security justifications as an elastic shield that can stretch or contract to serve Apple's financial and business interests.
DOJ Complaint against Apple
We recognize under the DMA that we've been forced to change. And we have created a program that keeps security and privacy in mind, that keeps the integrity of the operating system in mind, and allows third parties to bring their browser engine, Google, Mozilla, to the platform. And for whatever reason, they have chosen not to do so.Kyle Andeer - Apple - Vice President Apple Legal (emphasis added)
At the DMA workshop last week, we directly raised with Apple the primary blocker preventing third-party browser engines from shipping on iOS. Apple claimed that vendors like Google and Mozilla have "everything they need" to ship a browser engine in the EU and simply "have chosen not to do so".
Apple has been fully aware of these barriers since at least June 2024, when we covered them in exhaustive detail. Multiple browser vendors have also discussed these same issues with Apple directly. The suggestion that Apple is unaware of the problems is not just ridiculous, it's demonstrably false. Apple knows exactly what the issues are. It is simply refusing to address them.
The most critical barriers that continue to block third-party engines on iOS include:
Loss of existing EU users: Apple forces browser vendors to create entirely new apps to use their own engine, meaning they must abandon all current EU users and start from scratch.
Web developer testing: Apple allows native app developers outside the EU to test EU-specific functionality, but offers no equivalent for web developers to test their software using third-party browser engines on iOS. Apple stated during the conference to expect updates here but provided no details.
No updates on long trips outside EU: Apple has not confirmed they will not disable browser updates (including security patches) if an EU user travels outside the EU for more than 30 days. This, far from being a security measure, actively lowers users' security by depriving them of security updates.
Hostile legal terms: The contractual conditions Apple imposes are harsh, one-sided, and incompatible with the DMA's requirement that rules for API access can only be strictly necessary, proportionate security measures.
Dual engine support: Apple now allows browsers to include both WebKit and their own engine in the same app. This is essential for introducing a new engine to the platform while maintaining fallback compatibility.
However, the most critical barrier remains firmly in place: Apple still forces browser vendors to abandon all their existing EU users if they want to ship a non-WebKit engine. This single requirement destroys the business case for porting an engine to iOS. Building and maintaining a full browser engine is a major undertaking. Requiring vendors to start from scratch in one region (even a region as large as the EU), with zero users, makes the investment commercially nonviable.
Instead, transaction and overhead costs for developers will be higher, rather than lower, since they must develop a version of their apps for the EU and another for the rest of the world. On top of that, if and when they exercise the possibility to, for instance, incorporate their own browser engines into their browsers (they formerly worked on Apple's proprietary WebKit), they must submit a separate binary to Apple for its approval. What does that mean exactly? That developers must ship a new version of their app to its customers, and 'reacquire' them from zero.Alba Ribera Martínez - Lecturer in Competition Law and Digital Markets (emphasis added)
Those are the major blockers to browser vendors porting their own engines to iOS. The list of changes that we believe Apple needs to make to be compliant with the DMA with respect to browsers and web apps on iOS is far larger, and we outline them in detail at the end of the article.
Perhaps the most important of these is the ability for browsers to install and manage web apps with their own engines. Something that has been directly recommended by both the UK's MIR investigation and the UK's SMS investigations.
Gatekeepers can hamper the ability of end users to access online content and services, including software applications. Therefore, rules should be established to ensure that the rights of end users to access an open internet are not compromised by the conduct of gatekeepers.
Recital 54 - Digital Markets Act (emphasis added)
What sets the web apart is that it was never designed to confine users within closed ecosystems. It is the world's only truly open and interoperable platform, requiring no contracts with OS gatekeepers, no revenue sharing with intermediaries, and no approval from dominant platform owners. Anyone can publish a website or build a web app without permission. There are no built-in lock-in mechanisms keeping users tied to a single company's hardware or services. Users can switch browsers, move between devices, and across ecosystems, all without losing access to their data, tools, or digital lives.
This kind of freedom simply doesn't exist in app store-controlled environments, where every app update, transaction, and user interaction is subject to centralized control, censorship, or a mandatory financial cut. The web's architecture prioritizes user autonomy, developer freedom, and cross-platform compatibility.
Apple's justification for its gatekeeping is security. Its position is that only Apple can be trusted to decide what software users are allowed to install. Every third party must submit to its review and approval process, no exceptions.
But the secure, interoperable, and capable alternative already exists, and it's thriving. That solution is the Web, and more specifically, web apps. On open platforms like desktop, web technologies already account for over 70% of user activity, and that figure is only growing.
Web apps offer the key properties needed to solve the cross-platform problem. They run inside the browser sandbox, which even Apple admits is "orders of magnitude more stringent than the sandbox for native iOS apps". They are fully interoperable across operating systems. They don't require contracts with OS vendors. And they're highly capable: if there was effective competition, around 90% of the apps on your phone could be delivered as web apps.
However, this promise only holds if browser vendors are allowed to compete, using their own engines, on every platform. Without that, Apple can unilaterally limit what the web is capable of, not just on iOS, but everywhere. If a feature can't be used on a platform as critical as iOS, then for many developers, it may as well not exist.
That's why enforcement of the Digital Markets Act on this issue is so vital, not just for the EU, but for the world.
The web is the world's only truly interoperable check against operating system platform monopolies. It must be allowed to compete fairly.
A key question is whether Apple is required to fix this under the Digital Markets Act. Apple's representatives argue that browser vendors can port their own engines to iOS in the EU and at a highly superficial and technical level this is true. However, what Apple does not acknowledge is that the conditions it imposes make doing so financially unviable in practice. Does this really count as compliance?
To answer that, we need to examine the DMA itself.
The primary relevant article in the Digital Markets Act is Article 5(7):
The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper's core platform services.Article 5(7) - Digital Markets Act (emphasis added)
At face value, Apple appears to have complied with the letter of Article 5(7). It technically allows third-party engines, but only under technical platform constraints and contractual conditions that render porting non-viable.
# But the DMA Demands More Than Surface-Level Compliance
The gatekeeper shall ensure and demonstrate compliance with the obligations laid down in Articles 5, 6 and 7 of this Regulation. The measures implemented by the gatekeeper to ensure compliance with those Articles shall be effective in achieving the objectives of this Regulation and of the relevant obligation.
Article 8(1) - Digital Markets Act (emphasis added)
The gatekeeper shall not engage in any behaviour that undermines effective compliance with the obligations of Articles 5, 6 and 7 regardless of whether that behaviour is of a contractual, commercial or technical nature, or of any other nature, or consists in the use of behavioural techniques or interface design.
Article 13(4) - Digital Markets Act (emphasis added)
These two articles clarify that it is not enough for Apple to simply allow alternative engines in theory. The measures must be effective in achieving the article's objectives, and Apple must not undermine those objectives by technical or contractual means.
The intent of this provision is laid out clearly in the recitals of the DMA:
In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users.
Recital 43 - Digital Markets Act (emphasis added)
In other words, Apple should not be in a position to dictate what features, performance, or standards in competing browsers and the web apps they power. That is, the intent is to guarantee that browser vendors have the freedom to implement their own engines, thereby removing Apple's ability to control the performance, features, and standards of competing browsers and the web apps built on them.
Fifteen months since the DMA came into force, no browser vendor has successfully ported a competing engine to iOS. The financial, technical, and contractual barriers Apple has put in place remain insurmountable. These restrictions are not grounded in strictly necessary or proportionate security justifications.
This is not what effective compliance looks like. Article 5(7)'s goals, enabling engine-level competition and freeing web apps from Apple's ceiling on functionality and stability, have not been met. Under Article 8(1) and Article 13(4), that makes Apple non-compliant.
Apple has a clear legal obligation to fix this. But will it act without pressure?
# Why Apple is right to fear a successful DMA solution
With growing international momentum, and continued advocacy pushing for aligned global enforcement, Apple's browser engine ban is facing sustained and mounting pressure. If the EU succeeds in forcing meaningful compliance under the DMA, it will set a global precedent. What regulator or government would tolerate such an obvious restriction on competition in their own market once the EU has shown it can be dismantled?
So why is Apple resisting this change so hard? They've already fought, and lost, a high court battle over it. Is this just a matter of being litigious? Hardly. Apple is acting rationally, if unethically. At the end of the day, it's all about protecting revenue.
The UK regulator cites two incentives: protecting their app store revenue from competition from web apps, and protecting their Google search deal from competition from third-party browsers.
Apple receives significant revenue from Google by setting Google Search as the default search engine on Safari, and therefore benefits financially from high usage of Safari. [...] The WebKit restriction may help to entrench this position by limiting the scope for other browsers on iOS to differentiate themselves from Safari [...] As a result, it is less likely that users will choose other browsers over Safari, which in turn secures Apple's revenues from Google. [...] Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple's App Store revenues.
UK CMA - Interim Report into Mobile Ecosystems (emphasis added)
A third and interesting incentive which the US's Department of Justice cites, is that this behavior greatly weakens the interoperability of Apple's devices, making it harder for consumers to switch or multi-home. It also greatly raises the barriers of entry for new mobile operating system entrants by depriving them of a library of interoperable apps.
Apple has long understood how middleware can help promote competition and its myriad benefits, including increased innovation and output, by increasing scale and interoperability. [...] In the context of smartphones, examples of middleware include internet browsers, internet or cloud-based apps, super apps, and smartwatches, among other products and services. [...] Apple has limited the capabilities of third-party iOS web browsers, including by requiring that they use Apple's browser engine, WebKit. [...] Apple has sole discretion to review and approve all apps and app updates. Apple selectively exercises that discretion to its own benefit, deviating from or changing its guidelines when it suits Apple's interests and allowing Apple executives to control app reviews and decide whether to approve individual apps or updates. Apple often enforces its App Store rules arbitrarily. And it frequently uses App Store rules and restrictions to penalize and restrict developers that take advantage of technologies that threaten to disrupt, disintermediate, compete with, or erode Apple's monopoly power.
DOJ Complaint against Apple (emphasis added)
Interoperability via middleware would reduce lock-in for Apple's devices. Lock-in is a clear reason for Apple to block interoperability, as can be seen in this email exchange where Apple executives dismiss the idea of bringing iMessage to Android.
The #1 most difficult [reason] to leave the Apple universe app is iMessage ... iMessage amounts to serious lock-in
Unnamed Apple Employee
Apple has also long been concerned that the web could be a threat to its app store. In 2011, Philip Schiller internally sent an email to Eddie Cue to discuss the threat of HTML5 to the Apple App Store titled "HTML5 poses a threat to both Flash and the App Store".
Food for thought: Do we think our 30/70% split will last forever? While I am a staunch supporter of the 30/70% split and keeping it simple and consistent across our stores, I don't think 30/70 will last unchanged forever. I think someday we will see a challenge from another platform or a web based solution to want to adjust our model
Internal Apple Emails (emphasis added)
It is crucial that readers and regulators understand that this is not some trivial matter for Apple. Allowing both browsers and the web to compete fairly on iOS will seriously harm Apple's margins and revenue.
Apple gets an astonishing $20 billion a year from Google to set its search engine as the default in Safari, accounting for 14-16 percent of Apple's annual operating profits. Safari's budget is a mere fraction of this, likely in the order of $300-400 million per year. This means that Safari is one of Apple's most financially successful products and the highest margin product Apple has ever made. For each 1% browser market share that Apple loses for Safari, Apple is set to lose $200 million in revenue per year.
In 2024, Apple is estimated to have collected $27.4 billion from $91.3 billion in sales on its app store, underscoring its role as a critical and expanding source of profit. By contrast, the macOS App Store, where Apple does not exercise the same gatekeeping power over browsers or app distribution, remains a much smaller operation, with revenue that Apple chooses not to report.
Web apps, which already have a dominant 70% share on desktop, can replace most of the apps on your phone. Even a far more modest 20% shift towards web apps would represent a $5.5 billion annual loss in revenue.
This is important because it explains why Apple will not voluntarily make these changes. No rational actor with such a tight monopolistic grip on a market (the market for browsers and the market for apps on iOS) would give that up if they could plausibly hang onto it by subtly or explicitly undermining attempts to open it up. Apple's statements about engaging or making changes are meaningless, it is only the concrete actions that they have taken to date that must be measured.
These changes, and the competition and interoperability they bring, will literally cost Apple billions if not tens of billions per year. On the flip side, these are savings that developers and consumers are missing out on, both in terms of quality of apps and services, and direct costs. This is money that Apple is extracting out the market via their control of iOS on high-cost and high-margin devices, sold to consumers at full price.
With a market value of $3 trillion, Apple has a legal budget of over $1 billion a year, giving it legal power that outstrips that of small nations. It is also not afraid to step as close to the line of non-compliance as possible, as Apple's former general counsel explains:
work out how to get closer to a particular risk but be prepared to manage it if it does go nuclear, … steer the ship as close as you can to that line because that's where the competitive advantage occurs. … Apple had to pay a large fine, Tim [Cook]'s reaction was that's the right choice, don't let that scare you, I don't want you to stop pushing the envelope.
Bruce Sewell, Apple's former General Counsel (emphasis added)
This, unfortunately, means that regulation is the only answer. Even Open Web Advocacy was only formed after we had exhausted every possible avenue at trying to convince Apple to develop critical web functionality.
Many other parties have attempted to negotiate with Apple on these topics over the last 15 years and all have come to naught, the power imbalance and the incentives for Apple not to do this is simply too strong.
Some have tried to frame the DMA as a clash between the EU and the US, with the DMA unfairly targeting American tech giants, but that is not the case.
For US negotiators to carve out exemptions for American companies now would defang the DMA and stall its pro-competition benefits just as they begin to be felt. [...] The victims of a DMA pause would be America's most innovative upstarts — especially AI start-ups. The DMA's interoperability and fairness rules were designed to pry open closed platforms and give smaller companies a fighting chance. [...] Big Tech lobbyists portray the DMA as anti-American. In reality, the DMA's goals align with American ideals of fair competition. This isn't Europe versus America; it's open markets versus closed ones.Luther Lowe - Y Combinator - Head of Public Policy (emphasis added)
The reality is this: Apple stands alone in enforcing a ban on competing browser engines and suppressing web app competition on iOS. No other gatekeeper imposes such a restriction.
In fact, the three major organizations working to port alternative browser engines to iOS, Google, Mozilla, and Microsoft are themselves American. Smaller browser vendors, many of whom are also based in the US, are depending on these efforts. Apple's restrictions don't serve consumers, startups, web developers, native app creators, or even other American tech companies. They serve only Apple, who makes billions per year from undermining both browser and web app competition on iOS.
Through front groups like ACT, which Apple primarily funds, the company may attempt to reframe this issue as the EU targeting successful US firms. But that's a distraction. This isn't Europe versus America, it's Apple versus the World.
At the DMA workshop last Monday, we had a chance to ask some of these questions, and to chat with Apple's ever-charming Gary Davis (Senior Director, Apple Legal) on the sidelines. While we are strongly opposed to Apple's ongoing anti-competitive conduct, we do deeply appreciate that Gary and Kyle were willing to come over and participate in person.
# No Browser Vendor has been able to bring their own engine to iOS
To kick off the first of OWA's questions on browser engines, Roderick Gadellaa asked the key question: Why has no browser vendor been able to bring their own engine to iOS, even after 15 months of the DMA being in force?
The DMA has been in force now for 15 months. Despite this, not a single browser vendor has been able to port their browser using its own engine to iOS. It's not because they're incapable or they don't want to, it's because Apple's strange policies are making this nearly impossible.
One of the key issues slowing progress is that Apple is not allowing browser vendors to update their existing browser app to use their own engine in the EU, and Apple's WebKit engine elsewhere. This means that browser vendors have to ship a whole new app just for the EU and tell their existing EU customers to download their new app and start building the user base from scratch.
Now, we would love for Apple to allow competing browsers to ship their own engines globally. But if they insist on allowing this only in the EU, Apple can easily resolve this problem. Here's how:
They can allow browsers to ship two separate versions of their existing browser to the App Store, one version for the EU and one for the rest of the world. Something which is currently possible in other App Stores. This would allow existing European users to get the European version of the app without having to download a separate app simply by receiving a software update. But it seems Apple doesn't want that, and they make this very clear in their browser engine entitlement contract.
Given that, Apple can easily resolve this problem simply by allowing browsers to ship a separate version of the app to the EU under the same bundle ID. Why is Apple still insisting that browser vendors lose all their existing EU customers in order to take advantage of the rights granted under the DMA? Thank you.
Roderick Gadellaa - Open Web Advocacy (emphasis added)
Coalition for Open Digital Ecosystems (an European advocacy group with members including Google, Meta, Qualcomm and Opera) also asked about the difficulty in porting browser engines:
Apple has made some changes to its rule governing third-party browsers and the ability to use other browsers engines in the EU. However, as was already mentioned, they have various restrictions, including having two different versions of the app, limitations on testing, cumbersome contract requirements, still making it onerous to meaningfully take advantage of the browser engine interoperability. Which is why no one has really successfully launched on iOS using an alternative browser engine. What is Apple going to do to enable the third parties to launch a browser on iOS via an alternative engine?
Emre Kursat Kaya - Coalition for Open Digital Ecosystems (emphasis added)
Gary Davis (Senior Director Apple Legal) and Kyle Andeer (Vice President Apple Legal) were there to answer the questions:
Let me take the browser engine first. I know this is all just conversation is supposed to be about browser choice screens and defaults, but I know some of you, many of you with the same group, have traveled very far to have this conversation. And so I'll take a question on that, which is, listen: as everyone knows, when we designed and released iOS and iPadOS over 15 years, we were hyper focused on how do we create the most secure computing platform in the world. We built it from the ground up with security and privacy in mind. The browser engine was a critical aspect of that design. Webkit was that aspect of the design. And that has worked for 18 years. We recognize under the DMA that we've been forced to change And we have created a program that keeps security and privacy in mind, that keeps the integrity of the operating system in mind, and allows third parties to bring their browser engine, Google, Mozilla, to the platform. And for whatever reason, they've chosen not to do so. And so we remain open. We remain open to engagement. We have had conversations, constructive conversations with Mozilla, less constructive engagement from the other party, but we are working to resolve that, those differences, and bring them to iOS in a way that we feel comfortable with in terms of security, privacy, and integrity perspective.
Kyle Andeer - Apple - Vice President Apple Legal (emphasis added)
Kyle began by incorrectly asserting that the session was focused solely on browser choice screens and defaults, despite the session being explicitly titled "Browsers". This appeared to suggest that our question on browser engines was somehow out of scope.
DMA Apple Workshop Agenda 2025
He acknowledged that under the DMA, Apple is now required to allow third-party browser engines on iOS. He then reiterated Apple's long standing talking points: that iOS was built from the ground up with security and privacy in mind, that WebKit is a core part of that design, and that any changes must preserve what Apple deems the "integrity" of the platform.
However, the fact that Safari heavily reuses iOS code and components is unlikely to be a genuine security feature and is almost certainly a cost-saving measure. By reusing code and libraries between iOS components, Apple can save significant amounts on staffing. This comes with two significant downsides: First it worsens security by locking Safari updates to iOS updates, increasing the time it takes security patches to reach users. Second, this tight coupling harms Safari itself by making it difficult for Apple to port its browser to other operating systems, ultimately weakening its competitiveness and reach. It also means that Apple can't offer beta versions of Safari to iOS users without them installing an entire beta version of the operating system, a limitation that other browsers do not have.
According to Kyle, Apple has created a program that allows third-party engines "in a way we feel comfortable with in terms of security, privacy, and integrity" but offered no specifics. He then shifted blame onto browser vendors, stating that Mozilla and Google have simply "chosen not to" bring their engines to iOS, omitting the fact that Apple's technical and contractual constraints make doing so unviable.
There's a lot of OWA people here in the rooms so well done on that. I also half the questions at least were about browser engines, which is obviously an Article 5(7) as opposed to a 6(3) issue. More than happy as Kyle already did to address the question, but I think it would be a shame that a session that is about choice screens and uninstallation and the defaults become a browser engine discussion. I was pleased that Kush was nodding when Kyle was pointing out the ongoing engagements with Google and Mozilla, which are continuing right up even to last week, and I think just some more this week. There was a bottom line issue, however, which is that both Google and Mozilla have everything they need to build their engines and ship them on iOS today. We heard some other issues mentioned. We are happy to engage on those issues. We are engaging on those issues, but everything is in place to ship here in the EU today. I think that's an extremely important point to take away from this.
Gary Davis - Apple - Senior Director Apple Legal (emphasis added)
Gary reiterated Kyle's suggestion that the questions on browser engines were out of scope and that browser vendors have everything they need to ship a browser engine on iOS today.
I think one other point I wanna make sure I address as I reflected upon the end, there was a question about why we don't do this on a global basis. And I think we've always approached the DMA as to the European law that relates to Europe. And we are not going to export European law to the United States, and we're not going to export European law to other jurisdictions. Each jurisdiction should have the freedom and decision making to make its own decisions. And so we're going to abide by that.
Kyle Andeer - Apple - Vice President Apple Legal (emphasis added)
While we would prefer that Apple enable browser competition globally on iOS, we recognize that the DMA does not require it to do so. We highlight these globally adopted changes simply to point out that Apple could choose to take the same pro-competetive approach here. This restriction not only undermines global interoperability, but also weakens the effectiveness of the solution for EU users themselves.
Earlier in the day, in a response to a question on reporting malicious apps, Kyle had finished with a quip suggesting that OWA gets its talking points from Spotify.
In response, OWA volunteer James Heppell addressed the insinuation directly before asking a question about web developer testing and third-party engines:
So I'd like to return to a browser engine for a second. But if it's OK, I'd like to quickly clear up my kind of connections to this. Because I think, Kyle, you were suggesting that I'm a front for Spotify and that OWA is. That's what I heard. I'm just a student. I volunteer because I truly believe in the open web. I don't get paid. I don't receive any compensation. I paid for myself to be here because I want to be. And the organization does not receive any money either. It's just donations. So if that's OK, and all clear. I'd like to carry on to the question.
When Apple does, eventually, hopefully, allow other browser engines on iOS, it will be adding a new phase of competition.
These engines will be unique on iOS, acting as an intermediary platform between the OS and the web. But having been blocked from iOS for over 15 years, when they arrive, there will inevitably be any unique bugs which need to be identified and resolved. And I think if I remember correctly, you said earlier that the new EU iOS will experience, I quote, "vulnerabilities and problems that will be unique here".
However, these restrictions, which are unique to Apple, creates a new problem. Most web developers like us, but not like us, are all around the world: in the US, where you're from, in Asia, in Africa, and the rest of the Americas,all over, and they still will serve EU users, but they're going to be unable to install or test these new browsers with their third-party engines on their devices. This means that these developers will be able to test Safari, but not Firefox's Gecko or Chromium, putting these competing browsers, web developers, businesses, and users at a significant disadvantage.
Apple faced the same issue with native app developers earlier, and ultimately resolved it by allowing testing versions of EU-only apps to be downloaded outside of the EU for developmental purposes.
The same principle should apply here. Web developers globally must be able to test their sites in the new competing browsers on iOS regardless of where they're located. We understand that Apple may not wish to allow these browsers to ship to consumers, that's their choice, I suppose, but that is a completely separate issue to allowing developers to test it.
So my question is, what solution does Apple propose to ensure that web developers outside of the EU can install and test these browsers and maintain compatibility and interoperability for users in the EU?James Heppell - Open Web Advocacy (emphasis added)
Kyle Andeer responded:
We're in a period of transition where we built an operating system, a set of operating systems that was designed to be the most secure in the world, and that is what we have built. A critical aspect of that was our integration of WebKit into our operating systems. And we've continued to maintain that as the most secure way to ensure that we have the very best operating system possible. We've also introduced flexibility and APIs for third-party browser engines to take advantage of these new opportunities under the DMA. We're also engaged in ongoing conversations with Mozilla and with the other company in terms of bringing them to iOS.
In terms of earlier, I don't think I referenced that you were getting funding from Spotify. I don't know where you're getting funding from. My reference is more to the code representative who does get a lot of funding from Google and Meta and Qualcomm and Spotify and others, but not yourself. I understand that, and I actually really […] respect the way that your team has approached this.I don't question your motives. I don't question your funding. We disagree, right? I think that's clear. In forums like this, our place is to disagree. We think we have developed a compliant solution. I appreciate hearing your feedback, and your feedback, and your colleagues' feedback. We'll take that into account. We've read your papers. We've read your advocacy. There are points where we disagree and we'll probably continue to disagree going forward. But I am not in any way disparaging where you're coming from. I understand you're a well-meaning person who believes that he understands how to best design our operating system. I get that.
Kyle Andeer - Apple - Vice President Apple Legal (emphasis added)
We appreciate Kyle's acknowledgment that we are sincere and not a front for any tech giant. We are also glad that Apple is reading and considering our papers and advocacy.
That said, Kyle slightly undercuts his otherwise polite tone by remarking, "I understand you're a well-meaning person who believes that he understands how to best design our operating system". While we welcome the recognition of good intentions, it's important to clarify that OWA's volunteer base includes experts in web development, browser engine design, security, and even operating system design.
When it comes to designing an operating system that enables fair competition and complies with the DMA, we would genuinely prefer that Apple take the lead. OWA's contributions are only necessary because Apple has chosen not to.
James, maybe I'll just take yours first in terms of what we'd call the testing entitlement. I think as we've been going along, we have learnt a lot as to how to facilitate that kind of testing outside of the EU, even in relation to browser engines. I think that's a subjective, active discussion. I think we've been discussing it with Mozilla and Google also. And the commission, I would expect to see some updates there.
Gary Davis - Apple - Senior Director Apple Legal (emphasis added)
As far as we're aware, none of the browser vendors have been informed about this. That said, if Apple is actively working on a solution, that's great. However, without published details, it's difficult to properly evaluate. Note, Apple has been aware of this issue since June 2024, over a year ago.
Our proposed solution is straightforward: web developers outside the EU should be able to download and install test versions of third-party browsers on iOS, using their own engines, directly onto their devices for the purpose of testing web apps and websites for EU users. This is strengthened by the fact that Apple has already implemented an equivalent solution for native app developers outside to test EU only features for their EU users.
Yeah, just to your last point, Gary, my first question about user testing would be great to get a response to that. And then just to Kyle's point about two separate binaries and security being the reason for the BrowserEngineKit restrictions, we'd love to understand how you see those things connected and why security is the reason for that restriction.
Kush Amlani - Mozilla - Director, Global Competition & Regulation
Kush's question is crucial because it challenges Apple to prove that its separate binary rule is truly connected to security, privacy, or platform integrity. Apple has provided no technical analysis showing that a single binary approach, or any alternative, pose a genuine security risk. Under the DMA Apple carries the full burden of demonstrating that such a restriction is both necessary and proportionate. So far Apple has neither satisfied that burden nor even attempted to meet it.
I think you raise an issue in relation to security. The reality is, and everybody knows this, and this is why it's taken a while to work through the issues, that browser engines are a security vector. I know it's not agreed by everybody that they have a similar security profile, but they do. I could sit here now and read a list of, I don't know, 100 actual vulnerabilities associated with browser engines. They are a known vulnerability. So therefore, we want to move forward in a way that takes account of those vulnerabilities and does not put our users at risk on the platform. And I think that is something which everybody should want as an outcome here.
Gary Davis - Apple - Senior Director Apple Legal
Apple has previously asserted to the UK regulator that its WebKit engine was more secure than Blink and Gecko. However, when asked to substantiate this claim, Apple failed to provide compelling evidence. The UK Competition and Markets Authority (CMA) concluded:
... in Apple's opinion, WebKit offers a better level of security protection than Blink and Gecko.
... the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines.
Overall, the evidence we have received to date does not suggest that Apple's WebKit restriction allows for quicker and more effective response to security threats for dedicated browser apps on iOS
Another key issue is that, due to how performance and sandboxing are implemented in browser engines, Apple will inevitably need to entrust significant responsibility for user security to the browser vendors themselves. Given that these browser vendors have security track records that are arguably superior to Apple's, this will, in fact, improve security on iOS. Apple is well within its rights under the DMA to impose reasonable baseline requirements such as regular security updates to all browsers on iOS, including Safari, and few would object to that. What needs to be avoided though is security rules that restrict utility to Apple's native app ecosystem or that undermine competition.
So last year, after we made a lot of noise to get Apple to reinstate homescreen web apps in the EU. Apple announced that homescreen web apps continue to be built directly on WebKit and its security architecture. However, under Article 5(7) of the DMA, Apple is not allowed to impose a browser engine on either users or third-party browsers. Can Apple update us on the progress made for allowing third-party browser engines to install and manage homescreen web apps on iOS once third-party browser engines arrive on iOS? Thank you.
John Ozbay - Open Web Advocacy
Under Article 6(7), Apple is prohibited from reserving such functionality for its own use, and Recital 43 makes clear that this is precisely the type of self-preferencing that the DMA's browser engine provision in Article 5(7) is meant to prevent. It is therefore unclear how Apple can lawfully justify denying third-party browsers the ability to install and manage web apps, particularly in browser vendor development environments where no user-facing concerns could be invoked during this development phase.
Finally, Apple has not published any detailed technical justification for why reserving these functionalities exclusively for itself is the only proportionate and strictly necessary security measure. In our view, no credible case can be made for such a blanket restriction, but tellingly, Apple has not even attempted to present one.
I think on homescreen web apps, obviously these are available today here and around the world. We have nothing to announce in terms of what we will do if and when a third-party browser engine comes to iOS. Certainly I can say from a high level perspective, our focus will continue to be, as I've said several times, on ensuring that anything that's operating on our platform is as secure and as private as possible, and it does not damage the operating system. Browsers and home screen web apps are different than other things. They have other access to the operating system that we will have to manage and control. And so we have not settled out on any of those issues. As I've said again, we've engaged with Mozilla, we've engaged with Google. We're figuring out the solution that works best for all parties.
Kyle Andeer - Apple - Vice President Apple Legal (emphasis added)
First, it is concerning that even Kyle, Apple's lead executive responsible for DMA compliance, expressed uncertainty about whether browser vendors will port their engines to iOS under Apple's current technical and contractual terms, despite vendors doing so on every other major platform. This signals low confidence from Apple that their compliance measures will be successful in achieving the aims of Article 5(7).
Kyle's statements in relation to security are also misleading. While he is correct in that, as covered in the previous section, Apple will need to give significantly greater access and delegate more security to browsers than a typical native app, the same is not true for web apps.
Web apps are extremely tightly sandboxed. According to Apple, this sandboxing is "orders of magnitude" stronger:
Apple's statement suggests that browser vendors aren't ready to support this functionality, but in reality, vendors have already taken steps to gain access to the ability to install and manage web apps, including at least one formal request under Article 6(7), made over a year ago, which was flatly rejected outright by Apple's legal team.
Rejecting requests to share the ability to install and manage web apps, without offering any detailed technical justification, is not meaningful engagement. Apple has not, to our knowledge, acknowledged that they have this obligation, nor have they begun detailed technical discussions on how to effectively comply.
Again, and this is critical, while it is encouraging that Apple has not explicitly denied its obligation to make this functionality available, compliance must be measured by actions, not words.
To comply with the aims of Article 5(7) of the DMA, and as outlined by Recital 43, Apple must stop imposing the use of its own browser engine on users, developers, and browser vendors within the EU. It must also no longer use such restrictions to control the functionality, performance, or stability of web applications installed and managed by third-party browsers.
Under Article 8(1), Apple is required to make changes that ensure this obligation is effective in achieving its objectives. Furthermore, under Article 13(4) Apple may not undermine compliance through contractual, commercial, or technical means.
So what must Apple change to meet these requirements?
Below is a brief summary of the most critical outstanding issues. You can follow the links to find out more detail about each individual fix. The vast majority of these remain unchanged from our June 2024 Apple DMA Review paper.
Web Developer Testing:
Allow non-EU web developers to be able to test web software for the purpose of supporting their EU users.
SFSafariViewController:
Update SFSafariViewController to respect the users choice of default browser and to provide meaningful benefit from the browser choice screen. The solution already works for Android via Android Custom Tabs.
Interoperability and Hardware Access:
Ensure browser vendors have access to all relevant hardware related functionality like on other operating systems for the purposes of developing web APIs such as WebUSB, WebBluetooth, WebNFC and ensure functionality extends to web apps installed by these browsers.
BrowserEngineKit:
Improve the stability and functionality of BrowserEngineKit. Ensure Apple has a transition strategy to migrate Safari to use their own framework.
Grant Equivalent Access to Content Filtering APIs:
Currently, iOS content filtering settings, used by parents to restrict access to harmful or adult material, only apply to Safari and apps using WKWebView. Third-party browsers with their own engines cannot integrate with these system-level protections, meaning they can not respect parental controls configured by users. Apple has stated that adding support is a "mild engineering effort" and has promised a beta release in March 2026. Likely, no browser vendor will be willing to ship a consumer product without this API given its importance to online safety and parental controls.
Apple Should Not Break Updates for EU Residents Traveling Outside The EU:
Apple has stated that it will prevent all updates for apps downloaded from third-party app stores that are outside the EU for more than 30 days. Apple has not released any explicit statement on what will happen to browsers using their own engine downloaded from Apple's app store if the user (an EU resident) leaves the EU for greater than 30 days. Given Apple attempted to block even browser vendors from testing on their own test devices outside the EU, it seems likely they will attempt to extend a similar policy to third-party browsers which use their own engine even if they are downloaded from Apple's app store. We would like a statement from Apple clarifying that this does not apply to browsers with the browser engine entitlement.
Allow Own Browser Extensions:
Allow third-party browsers to ship their own extensions on iOS (something that Apple currently only allows Safari to do), including separately from Apple's app store if desired. Browser Extensions are a critical part of browser competition.
Web Apps run by Third-Party Engines:
Allow browsers to install and manage Web Apps which then run in the third-party browser's engine. Third-party browsers should be able to manage the web app install process and customize the web apps settings page to support desired features. Browsers should also be able to operate "web app stores".
Direct Browser Installation:
Allow direct browser installation independently from Apple's app store without scare screens.
Automatic Notarization:
Make notarization for browsers with the browser engine entitlement automatic. Browser vendors with the browser engine entitlement have agreed to security conditions such as regular patching and some have arguably better securitythan Apple. The app review team does not contain browser engineers and certainly not on the scale to meaningfully contribute. This means the human review element adds nothing but it does grant Apple the ability to suppress competition and delay compliance via app review as with Spotify and Epic.
Alpha and Beta Versions of Browsers:
Allow Alpha and Beta versions of Browsers in the App Store, currently blocked by App Store rules. Currently Safari can not offer this feature due to being tightly tied to the operating system but that should not stop third-party browser vendors from contesting Safari by doing so. The scale that browsers operate on makes this necessary and other beta testing methods insufficient. Several browser engineers we have spoken to have said that testflights 10k user limit makes it next to useless for applications of this scale.
Age-Restriction Parity:
Ensure equal treatment between Safari and third-party browsers in relation to Age‑Restrictions including accounting for Safari being preinstalled.
System Change Default Browser Prompt:
Make setting the default browser easier, by adding a system prompt to switch default browser. Other operating systems such as Android have such a prompt. Apple may subject this prompt to the usual anti-spamming rules it uses for iOS app permissions such as push notifications.
Hotseat on Setting Default Browser:
When a user manually downloads a browser and sets it as their default the operating system should prompt the user as to whether to place this browser in the hotseat replacing Safari.
Safari Should Not Be Locked to Apple Pay:
Update Safari to allow Apple Pay competitors. Apple is directly obligated to do this under Article 5(7) which stipulates they can not impose a payment provider via a core platform service. Safari is a core platform service.
Default Browser Detection:
Initially, third-party browsers on iOS were unable to detect whether they were set as the default. Apple now permits this check, but only four times per year. This arbitrary limitation prevents browser vendors from creating user experiences similar to Apple's own flow for Safari on macOS, where the browser's internal settings page indicates whether the browser is currently the default. By contrast, Apple imposes no such restrictions on more potentially intrusive APIs, such as push notifications, which can be queried without limit. Apple should apply consistent and non-discriminatory logic, and allow third-party browsers the same flexibility in determining their default status.
Apple is not in compliance with the Digital Markets Act (DMA) regarding browsers and web apps.
While we understand the Commission's measured approach and its willingness to give Apple the opportunity to comply voluntarily, it is now clear that, without firm intervention, Apple will continue to avoid resolving this issue indefinitely.
Due to Apple's current technical limitations and contractual conditions, browser vendors lack a financially viable path to port their own engines to iOS, despite doing so on nearly every other operating system. Unless meaningful changes are enforced, Apple will have effectively circumvented its obligation under Article 5(7), rendering compliance hollow and defeating the purpose laid out in Recital 43.
The result: Safari remains shielded from effective competition on iOS, and Apple's restrictions will continue to prevent the Web from serving as a viable, interoperable alternative to Apple's App Store.
Apple will continue to reap billions per year as a reward for its defiance of the DMA, revenues that are extracted from consumers and businesses via denying them meaningful choice and locking them into Apple's services on Apple's terms.
We call on the Commission to investigate Apple's compliance and to compel Apple to make the necessary changes that would allow browser vendors to port their engines to iOS and, for the first time in 15 years, compete on fair terms.
Such enforcement will benefit EU consumers, EU businesses and ultimately the entire world.
]]>
Google's Hotseat Hypocrisy2025-07-04T00:00:00Zhttps://open-web-advocacy.org/blog/googles-hotseat-hypocrisy/TL;DR: On iOS in the EU, selecting a third-party browser from the choice screen replaces Safari in the hotseat (dock), ensuring the user’s choice is respected. This change has already led to meaningful gains in market share; Mozilla, for example, saw its daily active users double in France and Germany on iOS, where the hotseat change is implemented. DuckDuckGo’s findings suggest that replacing Safari in the hotseat boosted the iOS choice screen’s effectiveness by a factor of nine. Yet Google refuses to make an equivalent change on Android, relying on an unreasonably narrow and, in our view, incorrect interpretation of the Digital Markets Act. Even when users choose a different browser, Chrome remains prominently placed, undermining their decision and steering them back toward Google’s own product.
Multiple browser vendors on Android and BEUC spoke to us about why they believe Google should implement this change:
Alphabet is undermining the browser choice screen if it leaves Chrome in the dock after a user has chosen an alternative browser. The choice the user makes should apply throughout the device and that means it should be the only browser you see in the dock and on the Home Screen.
Sébastien Pant - The European Consumer Organisation (BEUC)
Automatically placing the user's chosen default browser on the dock considerably improved our app's retention on iOS. The same change is likely to cause the same effect on Android, and we see no reason why Android should apply the same obligation differently. Aurélien Mähl - DuckDuckGo - Lead Public Policy Manager
The hotseat is a place for the user's most important apps. It's confusing for users who choose Vivaldi as their default to continue to see Chrome in the hotseat when they've clearly expressed their preference and switched away. It's obviously designed to steer users back to the gatekeeper's own browser.
Bruce Lawson - Vivaldi - Technical Communications Officer
Ecosia has evidence to believe that 50% of users who select an alternative browser in the choice screen do not even open it. They stick with what is easily accessible. "Default" is not just a technical concept. Above all, it refers to the default positions in the User Interface, especially the “hot seat”.
Dr. Wolfgang Oels - Ecosia - Chief Operating Officer
We're disappointed that Google continues to undermine the DMA, which aims to preserve personal choice and market competition. Instead of following the plain intent in the DMA, which aims to make it easy for Android users to use whatever browser they prefer, Google is cynically "playing dumb", and professing narrow, absurd interpretations of the DMA's plain meaning and goal.
If an Android user chooses Brave (or any other browser) to be their "default" browser, that user is (obviously) expressing the desire for Brave to be the primary, easy to access Web browser on the device. That means placing Brave in the "hotseat" just as much as making Brave the browser used to open websites on the device. We hope Google will stop dragging their feet, stop trying to undermine the DMA, and start respecting Android users' preferences, no matter the cost to Google's monopoly business interests.
Pete Snyder - Brave - Principal Privacy Researcher
Some elements of the browser choice screen implementation remain lacking on Android. When a user selects Firefox as their default browser in the choice screen, it does not replace Chrome on the homepage (or "hotseat"). This means that, despite making a clear and specific choice, Chrome still remains the more prominent and easily accessible option on the device.
Moving the selected browser to the hotseat would be a step towards making the DMA browser choice screen work for EU Android users and lead to further growth for independent browsers on Android. On iOS, where Apple made the hotseat change, Firefox saw an uptick of 111% daily active users in France and 99% in Germany in the first 12 months of the DMA - despite initially poor compliance.
Kush Amlani - Mozilla - Director, Global Competition & Regulation
This has long been a concern for Open Web Advocacy, and it was included in our list of recommendations published in our 7 March 2024 article marking the beginning of DMA compliance obligations for gatekeepers:
Reduce the power of default browser with a choice screen
Ensure that both Apple and Google implement effective designs for their browser choice screens. Specifically, the choice screen should not self preference their own browsers, should grant the chosen browser the “hotseat” and should appear on all existing devices once and all new devices (including after backup and restore).
Open Web Advocacy
The hotseat refers to the set of app icons located on the dock at the bottom of the home screen on both iOS and Android devices. They have the advantage of always being shown regardless of which homescreen the user is on. This is prized real-estate for any commonly used app.
On all Apple devices and many Android devices gatekeepers’ browsers are placed in the hotseat via the default setup of the device.
At this year’s DMA Apple workshop on Monday, Apple directly brought up their compliance with Article 6(3) and highlighted that other gatekeepers (i.e. Google) had not yet been compelled to comply to the same degree:
These are changes that go significantly further than the other designated companies who are subject to obligations of Article 6(3), one example is the fact that Apple and Apple alone amongst all designated gatekeepers for browsers, has been required to replace Safari on the dock or in the homescreen for the browser selected on the choice screen.Kyle Andeer - Apple - Vice President Apple Legal (emphasis added)
Only two companies, Apple and Google, have been designated for both browsers and operating systems, and are therefore required to comply with this aspect of Article 6(3). While we actively campaigned for Microsoft Edge to receive a similar designation, through both written submissions and an open letter, those efforts were ultimately unsuccessful.
OWA's Roderick Gadellaa, made the comment:
We agree with Apple: Hotseat should be default on Android as well, and we’ll be raising this tomorrow.
Roderick Gadellaa - Open Web Advocacy (emphasis added)
Last year at their DMA workshop, Google struck a markedly different tone to Apple, offering a complimentary and compliant outlook on the DMA, an approach that stood in welcome contrast to Apple’s overt hostility.
This year, however, while Google’s representatives reiterated their intention to continue complying with the DMA, their messaging shifted noticeably. They were eager to emphasise that the interoperability and competition the DMA introduces across Google’s core platform services, including Search, Play, Android, Chrome, Advertising, YouTube, Maps, and Shopping, is not a benefit to EU users, but is in fact actively harmful. This narrative, though politely framed, represents a significant and troubling pivot: from embracing compliance to attempting to undermine the regulation.
At the Digital Markets Act Google Workshop, our very own James Heppell was on the ground to pose the question directly to Google:
We heard yesterday that Apple’s choice screen implementation now grants the chosen browser the hotseat, meaning it’s prominently placed in the centre of the user’s dock - replacing the gatekeeper's browser Safari. In contrast, Google has not made these changes and continues to use a far less effective design.
We know from our conversations with browser vendors that having the hotseat leads to higher retention rates and reduces the dominance of the operating system gatekeeper and their browser.
By not placing the user’s chosen browser in the hotseat, Google is undermining Article 6(3) and making the choice screen significantly less effective. Just setting the default browser is not enough to nullify the advantage that Google grants their own browser via their control of Android’s default setup.
Given that Google already benefits from the hotseat on iOS, can Google commit to implementing an equivalent hotseat placement for browsers on Android?
And if so, when can we expect that to roll out?
James Heppell - Open Web Advocacy (emphasis added)
The question prompted a brief acknowledgment from Google’s Oliver Bethell:
The last part of your question, will we commit today to do x, y or z? I don't suspect today is going to be the place where we will commit to doing x, y or z. Just to prepare everyone for that, but we will certainly react to the substance and give you an indication of where we are currently in our thinking and then I'll dial up with the Commission.
[...]
and, the hotseat issue which was a hot topic as I understand yesterday. Oliver Bethall - Google - Head of Competition, Regulatory Engagement & Advisory (emphasis added)
Google's formal response came from Clare Kelly, who offered a very narrow interpretation of Article 6(3):
And then the question from Open Web Advocacy on hotseat, again our approach to this is informed by what the DMA says, and Article 6(3) is clearly about defaults, a hotseat is not a default, so a default is a service that will trigger as a result of a generic user action, as I mentioned earlier, and so if the user goes to do something, for example clicks on a url, it would be the browser that is used in order to fulfil that specific user intent. The placement of a particular app on a device has nothing to do with the default. And so that is our view in respect of how the hotseat question fits with what we are talking about, when we are talking about compliance with the DMA.
Clare Kelly - Google - Senior Competition Counsel (emphasis added)
This is an overly narrow interpretation, and it's particularly striking that Google chose to emphasise that the default browser is the one used when a user clicks on a URL, given that this is something Google itself actively undermines on Android. The Android Google Search widget, for instance, doesn’t open links in the user’s chosen default browserbut instead opens them in the Google Chrome in-app browser. Many other popular apps also override the system default browser and silently open links in their own in-app browsers, a practice we’ve documented extensively. As a result, the very concept of a default browser is being steadily eroded on mobile. In this environment, securing a position in the hotseat has become a crucial source of traffic for the user’s selected browser and a key part of respecting the user's choice.
Mozilla’s Kush Amlani then challenged Google’s interpretation in a followup question, pointing to both the text of Article 6(3) and Recital 49:
Coming back to the hotseat and to your response there, I wanted to say that if you select a browser via a choice screen and it downloads to page 13 of your apps, I am not sure that necessarily complies with 6(3) and we would contest your interpretation of that. I mean, Recital 49 of the DMA says that "gatekeepers should allow end users to easily change default settings when those default setting favor their own software applications and services" and Article 6(3) also says that "gatekeepers should allow and technical enable end users to easily change default settings including via prompting by a choice screen" so from our point of view both of those things do require you to place the selected browser in the hotseat and obviously it has already been done by other gatekeepers as well.
Kush Amlani - Mozilla - Director, Global Competition & Regulation (emphasis added)
Despite Mozilla’s intervention, Google doubled down on its position:
In respect of the hotseat, I mean again, I can understand, you know, your perspective on things, but again it has to come back to what is said in the DMA even your reference to the recital reference is a default, a default means a very very specific thing and it hasn't to do the with the placement on a device and in any event on Android it is extremely easy for users to move around where their apps are placed when they are downloaded.
So again, we don't think it gives rise to any questions of non-compliance with the DMA, so as, again here our position is what I stated earlier.
Clare Kelly - Google - Senior Competition Counsel (emphasis added)
Here, again, Google is attempting to shrink the scope of the DMA by changing “default settings” to mean strictly “default apps”. They also repeatedly state that it all comes back to what the DMA actually says… so let us take a look at what it actually says in the act:
The DMA has a far broader interpretation in both Recital 49 and Article 6(3).
[...] The gatekeeper shall allow and technically enable end users to easily change default settings on the operating system, virtual assistant and web browser of the gatekeeper that direct or steer end users to products or services provided by the gatekeeper. That includes prompting end users, at the moment of the end users’ first use of an online search engine, virtual assistant or web browser of the gatekeeper listed in the designation decision pursuant to Article 3(9), to choose, from a list of the main available service providers, the online search engine, virtual assistant or web browserto which the operating system of the gatekeeper directs or steers users by default, and the online search engine to which the virtual assistant and the web browser of the gatekeeper directs or steers users by default.
Article 6(3) - Digital Markets Act (emphasis added)
Again “web browser to which the operating system of the gatekeeper directs or steers users by default” is clearly broader than the narrow definition that Google is trying to impose of simply which browser is the system default.
A default setting is anyconfiguration pre-established by the gatekeeper’s operating system that shapes how users interact with their device and what services they use. These defaults span a wide range of areas. This can include which apps are set as default but also extends to home screen layout, apps’ default position, how notifications or updates behave, hardware preferences and many many more.
Importantly in this context DMA does not apply to every default setting, it only applies to those default settings which “favour its own or third-party services or products on its operating system”or those that impact which “online search engine, virtual assistant or web browser to which the operating system of the gatekeeper directs or steers users by default”.
This is further clarified in Recital 49, as mentioned in Kush Amlani’s question, a competition and regulatory lawyer for Mozilla.
A gatekeeper can use different means to favour its own or third-party services or products on its operating system, virtual assistant or web browser, to the detriment of the same or similar services that end users could obtain through other third parties. This can for instance happen where certain software applications or services are pre-installed by a gatekeeper. To enable end user choice, gatekeepers should not prevent end users from un-installing any software applications on their operating system. It should be possible for the gatekeeper to restrict such un-installation only when such software applications are essential to the functioning of the operating system or the device. Gatekeepers should also allow end users to easily change the default settings on the operating system, virtual assistant and web browser when those default settings favour their own software applications and services. This includes prompting a choice screen, at the moment of the users’ first use of an online search engine, virtual assistant or web browser of the gatekeeper listed in the designation decision, allowing end users to select an alternative default service when the operating system of the gatekeeper directs end users to those online search engine, virtual assistant or web browser and when the virtual assistant or the web browser of the gatekeeper direct the user to the online search engine listed in the designation decision.
Recital 49 - Digital Markets Act (emphasis added)
The intent here, is clearly, to the degree reasonably possible, to nullify the advantage the gatekeeper grants their own products on its operating system by the default setup of the device. In this case on Android devices where the choice screen is shown, the “default settings” that Google has applied are that Chrome is typically both the default browser app for links and is positioned in the hotseat, via a default setting. Obviously users are far more likely to continue to use the browser that is extremely prominently placed in the hotseat, regardless of what browser they pick in the choice screen if that chosen browser is buried on a far later page.
Yes, users could then manually drag that app onto the hotseat, but it is this style of friction that gatekeepers routinely have attempted to use to undermine compliance with the DMA. This was even anticipated by the EU, to the degree they added an entire clause for this type of behaviour:
The gatekeeper shall not engage in any behaviour that undermines effective compliance with the obligations of Articles 5, 6 and 7 regardless of whether that behaviour is of a contractual, commercial or technical nature, or of any other nature, or consists in the use of behavioural techniques or interface design.
Article 13(4) - Digital Markets Act (emphasis added)
The Act also imposes a complementary obligation in Article 8(1): gatekeepers must ensure that their compliance is effective in achieving the objectives of the Regulation. This means not simply following the letter of the law, but faithfully implementing its intent, as clarified in the recitals.
The gatekeeper shall ensure and demonstrate compliance with the obligations laid down in Articles 5, 6 and 7 of this Regulation. The measures implemented by the gatekeeper to ensure compliance with those Articles shall be effective in achieving the objectives of this Regulation and of the relevant obligation.
Article 8(1) - Digital Markets Act (emphasis added)
The intent of Article 6(3) is to eliminate the self-preferencing advantages that gatekeepers grant their own apps through the default configuration of the device. It is not enough for Google to nominally allow a browser choice, it must ensure that the user’s choice is effectively respected. Replacing Chrome in the hotseat with the selected browser is a clear and necessary step toward fulfilling that obligation.
Apple’s lawyers clearly agreed with our interpretation. We believe it is highly unlikely that Apple would have made this change to every iPhone in the EU and re-run the choice screen unless they had a high level of confidence they would lose a legal battle on this point.
(b) A requirement for Apple to ensure the placement of a default browser selected by the user in the ‘application dock’/‘hotseat’ or on the default home screen at device set-up.
[...]
(b) A requirement for Google to ensure the placement of a default browser selected by the user in the ‘dock’/‘hotseat’ or on the default home screen at device set-up.”
UK - Competition and Markets Authority
We stand with the smaller browser vendors who have raised concerns. The impact of proper choice screen implementation is clear, Mozilla, for example, saw its daily active users double in France and Germany on iOS, where the hotseat change is implemented. DuckDuckGo’s analysis found that search retention among choice screen users, a rough proxy for increase in browser usage caused by the choice screen, improved 9 times more among users presented with the iOS 18.2 choice screen, which include the hotseat replacement, compared to those using the iOS 17.4 choice screen, which did not. Google’s refusal to implement a comparable measure on Android, while benefiting from Apple’s compliance on iOS, is unacceptable and undermines the intent of the DMA. Google should update its EU choice screen to place the user’s selected browser in the hotseat and prompt existing users who have already chosen a non-Chrome default browser to move it into the hotseat, displacing Chrome.
If Google does not act promptly, we urge the European Commission to intervene and compel Google to comply through enforcement action.
The DMA is a helpful act to look at as it has been in force the longest and many of these other acts are loosely based on it. The DMA aims to restore contestability, interoperability, choice and fairness back to digital markets in the EU. These fundamental properties of an effectively functioning digital market have been eroded by the extreme power gatekeepers wield via their control of “core platform services”.
Under the DMA gatekeepers are only allowed to have strictly necessary, proportionate and justified security measures to protect the integrity of the operating system.
In order to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, it should be possible for the gatekeeper concerned to implement proportionate technical or contractual measures to achieve that goal if the gatekeeper demonstrates that such measures are necessary and justified and that there are no less-restrictive means to safeguard the integrity of the hardware or operating system.
DMA - Recital 50 (emphasis added)
The gatekeeper shall not be prevented from taking, to the extent that they are strictly necessary and proportionate, measures to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper. DMA - Article 6(4) (emphasis added)
The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper. DMA - Article 6(7) (emphasis added)
Where possible, less-restrictive security measures should be used. There is an understanding by the DMA that some security measures will restrict the ability of third parties to contest gatekeepers but that where possible that restriction should be kept to the minimum "strictly necessary" and only be allowed where it is "proportionate".
Importantly the "duly justified" means that the burden of proof is on the gatekeeper to show that their security measures are "strictly necessary" and "proportionate".
While Apple currently makes an estimated $64 billion a year from its App Store and tells The Verge it has computer automation, proprietary review tools, huge volumes of internal data, and a dedicated “Discovery Fraud team” of humans at its disposal, a single person on a laptop in his living room is finding egregious scams that Apple continues to host, and I was able to use his basic technique to do the same thing. As Apple faces down hearings in Congress and lawsuits in court, its argument that it needs to maintain total control over the iPhone app ecosystem to keep users safe doesn’t mesh with the obvious examples of grift that anyone can easily find.Sean Hollister - The Verge (April 2021) (emphasis added)
We are concerned that in many cases Apple is stretching its rules, many of which lack any legitimate security basis, far beyond the "strictly necessary" and "proportionate" scope allowed by the DMA. Further, Apple has provided no security justification for any of its new rules.
No reasonable party objects to security measures that improve security without giving anti-competitive power to gatekeepers to block third parties from contesting their services via their platform.
In certain cases, in particular browsers, gatekeepers will need to delegate the task of protecting the user and the OS to competent third-party browser vendors. Thus, the primary security measure for browsers is vetting which browser vendors get the relevant access and revoking it if the browser vendor is significantly incompetent or malicious.
In the end, Apple deploys privacy and security justifications as an elastic shield that can stretch or contract to serve Apple’s financial and business interests. DOJ Complaint against Apple
Ultimately, the goal is to strike a balance between genuine security protections and allowing effective competition. The right policy will allow clear rules and security measures that improve security while not allowing these measures to be used as a weapon by the gatekeeper to block competitors.
# 3. Gatekeepers should not have a Presumption of Better Security
Under the Digital Markets Act (DMA), it is both inaccurate and counterproductive to presume that gatekeepers inherently provide superior security compared to third-party providers, despite ample evidence demonstrating otherwise.
Competition drives innovation, including in security. Independent companies continuously improve their security offerings to remain competitive, and many possess expertise and resources that match or exceed those of gatekeepers. For example, Mozilla, Cloudflare, Signal, Let’s Encrypt, and 1Password have all demonstrated world-class security practices.
Gatekeepers are not immune from having security breaches and there are many high-profile examples of gatekeepers having insufficient security or security breaches including:
Between 2012 and 2019 Meta stored passwords for hundreds of millions of users in plain text, exposing them for years to anyone who had internal access to the files. User passwords are typically protected through hashing, a one-way cryptographic process often combined with salting, to prevent them from being recovered or reversed. However, a string of errors led certain Facebook-branded apps to leave passwords accessible to as many as 20,000 company employees. Between 200 million and 600 million Facebook users are believed to have been affected.
Hashing users’ passwords is a well known and straightforward practice with no significant downsides. This should have been a trivial security measure for Meta to have implemented across all of its software products.
The Facebook source said the investigation so far indicates between 200 million and 600 million Facebook users may have had their account passwords stored in plain text and searchable by more than 20,000 Facebook employees. The source said Facebook is still trying to determine how many passwords were exposed and for how long, but so far the inquiry has uncovered archives with plain text user passwords dating back to 2012.
My Facebook insider said access logs showed some 2,000 engineers or developers made approximately nine million internal queries for data elements that contained plain text user passwords. Brian Krebs - Krebs On Security
The cost of implementing proper encryption and security measures is a fraction of what it costs to deal with a data breach involving plaintext passwords. The financial and legal ramifications are severe and long-lasting.
Wendy Nather - Head of Advisory CISOs at Duo Security
In September 2024, Meta was fined 91 million euros ($102 million) for breaking Europe's strict privacy rules. The company hadn't put enough protections in place to secure people's social media passwords.
It is widely accepted that user passwords should not be stored in plaintext, considering the risks of abuse that arise from persons accessing such data. It must be borne in mind, that the passwords the subject of consideration in this case, are particularly sensitive, as they would enable access to users' social media accounts.
Deputy Commissioner Graham Doyle (emphasis added)
The report found that a series of security failures at Microsoft allowed nation-state actors assessed to be affiliated with China to steal hundreds of thousands of emails from cloud customers, including federal agencies. The board concluded that Microsoft's security culture was inadequate and ill-prepared for the increasing sophistication of cyber threats.
The report details Microsoft's missteps before, during, and after the breach, labeling it a "preventable" incident.
The CSRB's conclusion is that Microsoft's security culture is ‘inadequate’ and that a ‘cascade of Microsoft's avoidable errors allowed this intrusion to succeed.’ It cites in particular:
• Lacking security practices of other cloud providers
• Failure to detect a compromise on a laptop from an employee at an acquired company before connecting it to its network
• Letting inaccurate public statements stand for months
• A ‘separate incident’ from January 2024 that, while not in the CSRB's purview, allowed another nation-state actor access to emails, code, and internal systems
• A need to ‘demonstrate the highest standards of security, accountability, and transparency.’
Kevin Purdy - ArsTechnica
XcodeGhost iOS malware, discovered in September 2015, spread through altered copies of Apple’s Xcode development environment, and, when iOS apps were compiled, third-party code was injected into those apps. Users downloaded infected apps from the iOS App Store.
Documents revealed during the 2021 Epic Games v. Apple trial (still ongoing) show that 128 million users downloaded the more than 2,500 infected apps, about two thirds of these in China. Popular apps such as WeChat, Didi Chuxing, and Angry Birds 2, among others, were infected by XcodeGhost. These are some of the largest native apps in the world, being the equivalents of Facebook and Uber in China. WeChat, for example, has 1.36 billion users.
Apple's app review process failed spectacularly in the case of the XcodeGhost malware. This highlights the inherent limitations of app review as it's impractical for human reviewers (reportedly only 500 reviewers to review 130,000 apps per week, with only a few minutes spent per app ) to scrutinize the vast amounts of code submitted for each app and these reviewers likely did not even attempt to do so.
Even with the assistance of automated code scanning tools, which can be circumvented by various obfuscation techniques, complex malware like XcodeGhost, injected during the compilation process, can easily slip through.
Apple discussed contacting users and briefly made an announcement on their China website. Shortly after, it was removed. To our knowledge, Apple never contacted users to inform them of the breach.
this decision to not notify more than 100 million users about potential security issues seems to have more to do with protecting the platform’s reputation than helping users stay safe
Kirk McElhearn - Intego (emphasis added)
What makes this example particularly egregious is the failure to notify users. Every company will have a security breach at some point in its history, but how those breaches are handled and whether the company considers customer safety or company reputation to be more important is an interesting peek into that company's psychology when it comes to security.
In 2018, Google staff discovered a bug in the Google+ API that could have been abused to steal the private data of nearly 52.5 million users.
Google said the bug allowed apps, which were granted permission to view Google+ profile data, to incorrectly receive permission to view profile information that the user had set to "not-public".
Google+ faced its second big breach of 2018 when a November update created an API bug that exposed data from 52.5 million Google+ accounts. Google fixed the bug within six days, and moved up Google+’s burial date from August to April 2019.
Michael X. Heiligenstein - Firewall Times
According to Google, the bug was introduced in November 2018 during a previous platform update and was live for only six days before its engineers discovered the issue. Once fixed, Google notified end users who had been impacted and publicly disclosed the existence of the bug.
Although Google handled this vulnerability well, it illustrates that even well-resourced gatekeepers will have vulnerabilities (and even breaches) from time to time, and the important element to focus on is how they handle them and could they reasonably have prevented them.
In particular:
Did they sufficiently follow good security practices?
Did they promptly fix the vulnerability?
Did they offer a public bug bounty program?
Did they have a healthy non-adversarial relationship with security researchers?
Did they notify end users?
Did they publicly disclose the bug once fixed?
Third-party vendors should not be blocked from competing if they are doing a proportionate and effective job at security, especially if they are doing a better job than the gatekeepers, even if they have the occasional vulnerability or breach. Proportionate security is the aim, not some abstract perfect security that even well-resourced gatekeepers can not obtain.
To be clear, we are not accusing any of these gatekeepers of having poor security relative to the industry. Rather, many gatekeepers, and in particular Apple, project an image of themselves as impenetrable fortresses which is misleading and hinders constructive security discussions.
Requiring gatekeepers to justify their security claims promotes transparency and accountability, ensuring they demonstrate the effectiveness of their measures and exposing any shortcomings. Even better, third-party auditors should be able to verify security claims against cross-industry standards, such as GSMA’s (see Ian Brown’s study commissioned by Meta). By not presuming gatekeeper superiority, the DMA and other regulators can allow contestability, improve interoperability, and ensure a more secure digital marketplace for consumers.
# 4. Can Gatekeepers Be Trusted to Design and Evaluate Their Own Security Measures?
Gatekeepers often invoke security to justify maintaining control over their ecosystems, particularly when faced with regulatory demands to increase interoperability or promote competition.
A notable example is Apple’s response to regulatory pressure to allow competing browser engines on iOS. In submissions to the UK’s Competition and Markets Authority (CMA), Apple argued that its own engine, WebKit, is inherently more secure than Blink or Gecko:
... in Apple's opinion, WebKit offers a better level of security protection than Blink and Gecko.
Apple raised a number of concerns that introducing third-party browser engines, or increasing the interoperability of WebKit, could introduce privacy and security risks. Apple submitted that Webkit offers the best level of security, and has cautioned that ‘mandating use of third-party rendering engines on iOS would break the integrated privacy, security, and performance model of iOS devices’. UK CMA - Interim Report into Mobile Ecosystems
But the CMA found Apple’s claims unconvincing and firmly rejected them:
... the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines.
Overall, the evidence we have received to date does not suggest that Apple's WebKit restriction allows for quicker and more effective response to security threats for dedicated browser apps on iOS. UK CMA - Interim Report into Mobile Ecosystems
The pattern is consistent elsewhere. Both Apple and Google have blocked third-party payment systems under the pretext of security. Yet neither has proposed proportionate alternatives, such as mandating PCI-DSS compliance, using known secure providers (such as Stripe or Adyen) or establishing clear technical standards. Instead, they’ve insisted that only their proprietary systems, through which they extract up to 30% in fees, are secure.
Even longtime Apple defender John Gruber called this rationale outdated:
‘This app does not support the App Store’s private and secure payment system. It uses external purchases.’
[...]
The uncompetitive nature of the App Store — I’m using uncompetitive rather than anticompetitive just to give Apple the benefit of the doubt here — has left at least some top Apple executives hopelessly naive about the state of online payments. It’s like when they still blather on about software being sold on discs inside boxes in physical retail stores. That was true. It was once relevant. It no longer is and hasn’t been for over a decade.
Same with payments. Online payments through, say, Stripe — which zillions of companies use — are completely private and secure today. Amazon payments are completely private and secure.
John Gruber - Tech Writer (emphasis added)
Apple's abuse of the "security" excuse became especially apparent in the aftermath of its legal battle with Epic Games. Though Apple largely prevailed, the court issued an “anti-steering injunction” requiring that apps be allowed to direct users to external payment methods. The ruling left some flexibility in implementation, but Apple chose “an anti-competitive option at every step”.
Apple introduced a 27% commission on web purchases and layered on a deliberately intimidating warning screen for users leaving the app:
Rafael Onak, a user experience writing manager at Apple, instructed an employee to add the phrase “external website” to the screen because it “sounds scary, so execs will love it.” Another employee gave a suggestion on how to make the screen “even worse” by using the developer’s name, rather than the app name. “ooh - keep going,” another Apple employee responded in Slack.
Even Cook got in on the action. When he finally saw the screen for approval, he asked that another warning be added to state that Apple’s privacy and security promises would no longer apply out on the web.
In court, Apple tried to argue that the term “scary” didn’t actually mean it wanted the screen to scare people. “Scary,” it claimed, was a “term of art” — an industry term with a specialized meaning. In fact, the company claimed, “scary” meant “raising awareness and caution.” The court did not buy it, saying the argument strained “common sense.” Jacob Kastrenakes - The Verge
Given the context above, one can conduct a thought experiment: Which of the following was Apple’s primary motivation?
Option 1: Apple was genuinely concerned that the court orders would compromise user security, which could damage its reputation. Accordingly, Apple sought to implement security measures aimed at mitigating those risks in a proportionate manner while still fully complying with the court order.
Option 2: Apple was primarily concerned that the court orders would undermine its control over App Store revenue, particularly its 30% commission, on transactions within an ecosystem worth $406 billion in 2024, and acted to discourage developers from adopting alternative payment methods and to ensure no business would be able to benefit from or attempt to exercise the rights granted under the court’s order.
Unfortunately for Apple, the answer appears painfully obvious, even to a public that is generally sympathetic to the company. Rather than engaging in serious, detailed security reviews and proposing proportionate safeguards, Apple’s internal discussions have included non-security personnel, including current Apple CEO Tim Cook, exploring how to make the alternative user experience deliberately “even worse”.
Apple also attempted to engineer the directive to allow external links in apps by creating new barriers and requirements that would similarly defang those orders. It created full-page “scare screens” (I referred to them as “This App May Kill You” screens), demanded that all links be to static URLs (neutering their utility), and kept editing the warning labels to dissuade users as much as possible from ever agreeing to follow the link. (Cook is specifically credited with amping up the language in the warning screens.)
The company’s internal struggle is fascinating to read about. While Apple Fellow and longtime App Store overseer Phil Schiller doesn’t come across entirely smelling like a rose, he does end up looking far better than literally any other Apple employee in the ruling. Schiller “advocated that Apple comply with the Injunction”—imagine that!—while Tim Cook, CFO Luca Maestri, and the company’s finance team instead decided to concoct a strategy of malicious compliance that led to the poison pill of the 27% commission.
Jason Snell - Six Colors
This approach backfired on Apple when the judge found:
Apple willfully chose not to comply with this Court’s Injunction, It did so with the express intent to create new anticompetitive barriers which would, by design and in effect, maintain a valued revenue stream; a revenue stream previously found to be anticompetitive. That it thought this Court would tolerate such insubordination was a gross miscalculation. As always, the cover-up made it worse. For this Court, there is no second bite at the apple.
Justice Gonzalez Rogers
# 4.1. Gatekeepers Cannot Be Trusted to Set the Terms of Security
Gatekeepers, and Apple in particular, have consistently used “security” as a smokescreen to protect profits and block competition. Their assessments of what is “secure” or “proportionate” cannot be trusted, especially when interoperability threatens their control or revenue.
What Should Regulators Do Instead?
There are several straightforward steps that can be taken by regulators to combat this:
Allow browser vendors to use independent third-party security audits to meet gatekeeper security requirements, rather than requiring audits to be conducted or approved solely by the gatekeeper.
Dismiss unsubstantiated security claims unless backed by credible, technical evidence.
Security claims should be assessed with the assumption that reasonable security measures will be implemented.
Rely on industry bodies and external experts when gatekeepers have shown bad faith or poor judgment.
Rely on industry security standards and certifications.
Browsers are a unique category of app, powering an entire interoperable and open ecosystem that competes with gatekeeper app stores.
Major browser vendors have dedicated security teams and, especially those involved in heavy engine development, need the ability to build their own sandboxes. Apple should allow browser vendors to port their existing sandboxes to iOS.
This is important as it changes the frame of referencing in relation to security. The question becomes not how the OS gatekeeper can protect users from the app but how can the OS gatekeeper restrict delegating this elevated responsibility of protecting the user to only those browser vendors that have the competence and reputation to be able to do it. The process becomes less about sandboxing and more about vetting who gets the browser engine entitlement or equivalents.
For example, in many cases it makes little sense for Apple to sandbox the third-party browser vendor’s (arguably superior) sandbox. Based on Apple's own analysis, this solution is obviously not viable or proportionate as it would require browser vendors to substantially redesign their own engine. Apple has a vast array of less restrictive methods, including contractual, to ensure user security.
...architecting a novel sandbox for third-party browser engines would require ground-up analyses of third-party engines with which Apple is not familiar. Third-party vendors would very likely need to substantially re-design their engines to meet iOS security and privacy requirements.
Apple - Browser Vendors will need to substantially re-design their engines (emphasis added)
That said, where OS gatekeepers can make the system significantly more secure in waysthat do not impede competition, they should have no issue in proving such changes are proportionate and necessary. No reasonable browser vendor would object to such security measures and such measures meeting those conditions are allowed by the DMA. Where a security measure will impede competition, the gatekeeper should have to show extensive evidence as to why it is “strictly necessary” and “proportionate”.
Importantly, gatekeepers should not be able to reserve special setups for their own browser. Safari should be required to use BrowserEngineKit if it is imposed on other browsers. This ensures a level playing field, ensures that BrowserEngineKit is of sufficient quality to support their own browser and prevents Apple from gaining an unfair advantage.
Safari and Chrome on iOS and Android respectively should receive no additional special treatment from the OS. Note, the DMA explicitly allows them to be pre-installed so that form of privilege is allowed.
The app review process has grown in importance as Apple increasingly emphasizes its App Store services as a source of revenue and iPhone security as a key selling point.
In addition, Apple’s platform is drawing new scrutiny as politicians and regulators take a more skeptical look at the power of big tech companies.
[...]
App Review is organized under the marketing umbrella at Apple and always has been, even before Schiller took over the greater App Store marketing and product departments in late 2015. Kif Leswing - CNBC (emphasis added)
In recent years, Apple has more strongly stressed the security of their app store. Bizarrely, according to this CNBC article, Apple's app store review team is under the department of marketing at Apple.
However, it doesn’t even appear to be effective in picking up apps that violate Apple’s payment rules (that grant it a 15-30% stake), something they are likely to want to enforce. In one particularly striking example of app review being ineffective at blocking updates that violate the current rules of the Apple’s app store, Epic managed to slip in an entire third-party payment solution into their app without it being picked up in review.
As Apple’s head of fraud Eric Friedman said regarding review processes:
This suggests that, while Apple outwardly projects confidence in the value of their app store review, some informed insiders view it as worthless.
Browsers use a far more reliable form of security than brief human review upon update.
They lock down the entire environment that the third-party code, that is websites and Web Apps, run in. This environment is called a sandbox and every action a website takes is tightly controlled. Even Apple acknowledges that browser’s sandbox is massively superior to iOS’s sandbox for native apps:
It is critical that any security threat that browsers face be viewed holistically and not in isolation. That is, were the user forced to install a native app to use that same functionality, instead of using a website or Web App, then what would their relative risk be? Would it be significantly better or worse?
One interesting example of this is that various app developers have been accused by Apple of using private APIs that they do not have permission to use. The fact that this must be picked up in review or code scanning, rather than simply not being possible, suggests an architectural flaw in the operating system.
This broader pattern of risky architectural decisions is not limited to an over-reliance on app review and code scanning. As Ian Beer of Project Zero highlights in his analysis of a kernel-level parser vulnerability:
I believe it's still quite possible for a motivated attacker with just one vulnerability to build a sufficiently powerful weird machine to completely, remotely compromise top-of-the-range iPhones.
[...]
Should such a complex parser driving multiple, complex state machines really be running in kernel context against untrusted, remote input? Ideally, no, and this was almost certainly flagged during a design review. But there are tight timing constraints for this particular feature which means isolating the parser is non-trivial. It's certainly possible, but that would be a major engineering challenge far beyond the scope of the feature itself.
Ian Beer - Project Zero (emphasis added)
Beer’s point reinforces the idea that Apple sometimes knowingly accepts unsafe architectures due to performance or engineering tradeoffs, even when the safer route is known.
There have also been many high profile cases of fleeceware or phishing on both the Apple’s iOS App Store and the Google Play Store.
As discussed here, the XcodeGhost iOS malware was introduced through altered copies of Apple’s Xcode development environment and around 128 million users were impacted by more than 2,500 infected apps. Apple failed to publicly disclose the breach in detail and did not notify end users.
Lasspass was a password app masquerading as Lastpass on Apple’s iOS App Store.
As LastPass is used to store very sensitive information, such as authentication secrets and credentials (username/email and password), the app was likely created to act as a phishing app and steal credentials.
Bill Toulas - Bleeping Computer
Apple's App Store review team is notoriously fickle about the software it approves for sale. Some companies have found themselves needing to tweak, change, or even totally remove certain features in order for their app to make it through the process.
Yet, somehow, a fake LastPass app made it past this very review team. Even worse, the fraudulent version of LastPass was available for weeks before it was eventually taken down, and only after it was noticed by the LastPass team themselves.
Matt Binder - Mashable
App Store page for Lass Pass.
It is not hard to imagine why an app impersonating an extremely popular password manager is a security disaster, especially given that end users believe that these apps are carefully reviewed. With perfect ironic timing, this app was approved (and allegedly reviewed) by Apple just as it was railing against the DMA allowing competition for its iOS app store as being detrimental for user security. The core pillar of Apple’s arguments is that only they are able to effectively protect users from such apps.
The new options for processing payments and downloading apps on iOS open new avenues for malware, fraud and scams, illicit and harmful content, and other privacy and security threats,
Apple - Statement on Jan 25th about the DMA
The app was only removed after its existence was reported in the news. Apple has offered no explanation on how they allowed this app to be approved.
Lasspass and malware like it on Apple’s app store are not a recent problem. Problems with the human element of app store review have plagued Apple for over a decade.
What the hell is this??????
[...]
How does an obvious rip off of the super popular Temple Run, with no screen shots, garbage marketing text, and almost all 1-star ratings become the #1 free app on the store?
Can anyone see a rip off of a top selling game? Any anyone see an app that is cheating the system?
Is no one reviewing these apps? Is no one minding the store?
As late as 2015, getting in contact with Tim Cook was a viable method of getting scams removed from Apple’s app store.
Tim received a complaint about this app being a scam (doesn't do what it says, promises bonus features for 5 star reviews, creates fake marketing videos, etc). It is a great example of the stuff we should have automatic tools to find and kick out of the store. I can't believe we still don't. Many 1 star reviews, many mention 'scam' and 'fake'. Then I look at the developers other apps and see the same issue repeated.
Eric Freidman appeared to still have a dim view in 2018 as to the quality and effectiveness of iOS app review:
As much as those guys want to help, their paycheck depends on getting apps in the door and keeping developers happy. They are more like the pretty lady who greets you with a lei at the Hawaiian airport than the drug sniffing dog who, well, never mind. ;)
Eric Friedman - Apple Head of Fraud (Feb 2018)
In 2018, Herve Sibert expressed doubt that app review had improved significantly.
Allow me to express doubts about this 'lot of work'... It's almost one year since we uncovered the I4 app hidden behind a calculator with loads of downloads, and if they've made any progress then it's just not visible.
Sometimes the human element of Apple's app store review can be done very fast. This 2018 email discusses spending a total of 32 seconds to review and approve two school shooting games two weeks after the deadliest mass shooting in US history. It took Apple seven months to realize their mistake.
The app was originally assigned to Armin by the TDP with instructions to reject any apps with egregious, malicious, misleading or objectionable content. So far all evidence points to Armin was going too fast and missed all the signals to reject these apps for 1.1, or at the least escalate. According to DJH it took a total of 32 seconds to approve both apps. In addition, the deadliest mass shooting in US history happened two weeks before these apps were approved on 10/18/17.
Trystan Kosmynka - Apple App Review Chief (May 2018)
The key point here is that Apple has not provided extensive evidence showing that human app review is actually effective at improving security. A striking theme of the emails (by senior Apple employees, published due to the Epic vs Apple court case which unfortunately only go up to 2020) is a sense of despair at how ineffective and hopeless Apple’s app review is, which is a sharp contrast from Apple’s curated public projection of it as an invincible fortress carefully reviewed by a crack team of experts.
This false projection can actually harm security as it lulls users into a false sense of security. Users are likely to be far more trusting of apps if they believe that Apple is carefully reviewing them.
Apple recently released this blog post which states:
From 2020 through 2023, Apple prevented a combined total of over US$7 billion in potentially fraudulent transactions, including more than US$1.8 billion in 2023 alone. In the same period, Apple blocked over 14 million stolen credit cards and more than 3.3 million accounts from transacting again.
As published in its fourth annual fraud prevention analysis released today, Apple found that in 2023, it rejected more than 1.7 million app submissions for failing to meet the App Store’s stringent standards for privacy, security and content. In addition, Apple’s persistent efforts to stop and reduce fraud on the App Store resulted in the termination of nearly 374 million developer and customer accounts, and removal of close to 152 million ratings and reviews over fraud concerns.
Apple - Blog post on App Store Review
This report reads as a press release. While sheer number of apps and comments removed should give some indication of the scale of the issue prior to these changes (i.e. for the first 15 years of the app store’s existence), Apple have not published any data that might give an indication as to what percentage of fraudulent apps they have removed and how long these apps have persisted on the app store.
There is no discussion of refunding consumers that have been duped out of likely hundreds of millions of US dollars, downloading these apps believing Apple has carefully reviewed them and of which Apple has collected a 30% cut.
There is also no discussion of the notable recent failures such as “Lasspass”.
Absent more detailed reporting that included the following, it is very difficult to get a gauge of the degree of app store fraud and how successful Apple's new efforts in combating it have been:
How many malicious apps made it onto Apple’s app store?
A more detailed description of Apple’s app review process (currently Apple has provided no detailed description anywhere).
What was the amount of time each app managed to stay on the app store before it was detected (i.e 5% percentile, 10% percentile … 95% percentile averages)?
How many dollars have Apple’s consumers been duped out of via fleeceware in the year?
What amount of the figure did Apple refund?
Statistics on what mechanisms apps were picked up on. I.e. user/security researcher reporting vs app review vs automated code scanning etc.
The assumption from those considering Apple’s announcement, is that the above figures were not published because they are not favorable to the arguments that Apple is making.
There are similar complaints about the Google Play Store (including by Apple).
In Apple's review team's defense they have been given a near impossible task and Apple has assigned a surprisingly small number of reviewers to the task.
Apple’s App Review team of over 500 experts evaluates every single app submission — from developers around the world — before any app ever reaches users. On average, the team reviews approximately 132,500 apps a week, and in 2023, reviewed nearly 6.9 million app submissions while helping more than 192,000 developers publish their first app onto the App Store.
Apple - Blog post on App Store Review (emphasis added)
Despite Apple's label of "expert", Apple has submitted no evidence as to what this expertise is.
Few reviewers have technical backgrounds, the former employee says, and their decisions are often subjective and vary significantly between reviewers.
Shubham Agarwal - Wired (emphasis added)
This email reveals that app store reviewers are expected to work 10-hour days, five days a week. During peak periods, these hours can extend to 12 hours per day. Phil Schiller acknowledged concerns that such conditions might be perceived as exploitative, similar to a "sweat shop" environment.
The hours might be spun to make it sound like a sweat shop - which would be awful. Everyone at Apple has periods where we get into heavy workloads (myself included). At the same time we have had to cap overtime when the team wanted too much, they wanted the extra income.
Phil Schiller - Apple Senior Vice President Worldwide Marketing (Jun 2019) (emphasis added)
Considering the sheer volume of work, reviewing and responding to 50-100 app updates working 10 hour shifts, appears to be a demanding and potentially unsustainable workload. Given this, it is not surprising that so many blatantly malicious apps are slipping through.
The app store review process also does not have a good reputation among developers (including high profile ones that have been featured on the app store) or tech writers.
There are endless horror stories around curation of the store. Apps are rejected in arbitrary, capricious, irrational and inconsistent ways, often for breaking completely unwritten rules.
Benedict Evans - Technology Writer
There's a lot of talk about the 30% tax that Apple takes from every app on the App Store. The time tax on their developers to deal with this unfriendly behemoth of a system is just as bad if not worse
Samantha John - CEO Hopscotch
Under the DMA, gatekeepers are only allowed strictly necessary, proportionate and justified security measures. If they intend to impede competition from third-parties such as direct download, third-party app stores, third-party browsers and Web Apps via these security measures, then the burden is on them for each measure to prove that it is necessary and proportionate.
Apple has in effect been arguing that only they have the ability to protect users due to their “stringent standards” and “persistent efforts to stop and reduce fraud on the App Store”. But this argument loses all validity if this review is ineffective relative to automated means such as code signing and automated code checks. Further, Apple will need to prove that third-parties are unable to achieve the same or a higher standard of security. This is particularly relevant for Web Apps which rely on “orders of magnitude” superior sandboxing as opposed to a brief human review.
Finally, no reasonable party will object to security measures that improve security but do not place any anti-competitive power in Apple or Google’s hands.
Apps, such as browsers, should be able to prompt users to change their update and distribution source – on a per-app basis, when wanted. Currently, even if other app stores become available, they are locked into continuing to use both Apple’s and Google’s app stores because of the high volume of already installed apps whose updates are distributed by these stores and the extremely high friction in switching the apps from one store to another.
This new distribution source could be either another app store or the developer directly.
Currently, the only way to switch distribution source on both iOS and Android is to delete and reinstall the app, a process that is time-consuming and risky due to potential data loss. This practice helps lock users into Google Play and Apple's app store. Friction can be a powerful barrier to competition. By making it difficult for users to switch, gatekeepers can maintain their dominant market position in the distribution of apps even after the DMA compels them to allow it due to the vast body of native apps that users have already installed from the gatekeeper’s app store.
An example prompt could be: “‘Firefox’ would like to switch its distribution source from ‘Apple App Store’ to ‘Mozilla Inc’. Changing this will mean all updates and app review will be performed by ‘Mozilla Inc’. Would you like to switch distribution source: YES | NO”
To prevent further reinforcing their dependence on the core platform services of gatekeepers, and in order to promote multi-homing, the business users of those gatekeepers should be free to promote and choose the distribution channel that they consider most appropriate for the purpose of interacting with any end users that those business users have already acquired through core platform services provided by the gatekeeper or through other channels.
Digital Markets Act – Recital 40 (emphasis added)
This would lessen the ability of gatekeepers to lock existing users into their ecosystem using the significant friction the current design applies on switching.
This style of remedy is allowed by Recital 40 of the Digital Markets Act. This would help mitigate gatekeeper's ability to lock users into their ecosystem by reducing the friction associated with switching distribution sources.
Browser vendors have the right to distribute their browsers directly to consumers on iOS and Android. This is and should be subject to strictly necessary, proportionate and justified security measures as allowed under the DMA.
We also propose that a more accurate and neutral terminology should be used for alternative software distribution on mobile platforms to the gatekeepers’ app store. The term "sideloading" often evokes a sense of unauthorized or illicit activity. Additionally, the term itself suggests a "side" or "secondary" method of installation, further reinforcing the notion that it is not the standard or approved way to obtain software.
We believe the term “direct install” should be used to describe the process of obtaining native software directly from the developer over the internet. This is the primary method of software distribution on desktop computers.
For third-party app stores, we would recommend the phrase “allowing third-party app stores to compete fairly”.
Web Apps represent a third category of competition. These applications are secured and managed by the browsers that install them.
The Digital Markets Act recognizes the importance of diverse competition in the app market and directly supports, and mandates the allowance of, all three distribution models in the wording of the act. This was confirmed directly by DMA rapporteur Andreas Schwab MEP at an IMCO meeting on the DMA and app stores, responding to a question by panellist Ian Brown. Dr Schwab referred to advice he received directly on this from the European Commission’s lawyer-linguists, who translated the DMA into the official languages of the Member States.
Apple currently notarizes (applies a digital signature to) apps distributed outside its app store, but has stated that this review is strictly limited to security. iOS and iPadOS will not run apps without this digital signature.
Notarization for iOS apps is a baseline review that applies to all apps, regardless of their distribution channel, focused on platform policies for security and privacy and to maintain device integrity. Through a combination of automated checks and human review, Notarization will help ensure apps are free of known malware, viruses, or other security threats, function as promised, and don’t expose users to egregious fraud.
Apple – On Notarization (emphasis added)
It's important to note that this is significantly different from macOS notarization, which is a fast and automated process. macOS notarization verifies that the developer signed the software and that the app is free from known malicious components.
Notarize your macOS software to give users more confidence that the Developer ID-signed software you distribute has been checked by Apple for malicious components. Notarization of macOS software is not App Review. The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly. If there are no issues, the notary service generates a ticket for you to staple to your software; the notary service also publishes that ticket online where Gatekeeper can find it.
Apple – on macOS Notarization (emphasis added)
Were Apple’s proposal simply to apply automatic checks including for code signatures that verify the developer is the same developer with the browser entitlement and apply quick and automated scans for known malicious code, that would be perfectly acceptable and beneficial.
However, Apple's language suggests that it will be used as a disguised form of app store review. We are concerned that not only will this grant them power to block competition, but will in fact worsen security by slowing down browser updates and worsening security. One study already found that the potential for disguised retribution by Apple by slowing approval of new apps and app updates in its App Store led even the very largest firms (designated as DMA gatekeepers) to avoid publicly criticising the company.
It is unclear that Apple’s reviewers will have anything meaningful to add to the work of the dedicated security teams of the browser vendors.
“Patch gap” is the amount of time between a vulnerability being discovered and it being patched on consumers devices. It is a critical aspect of security that this gap is as small as possible.
Apple's past behavior, as evidenced by the DOJ complaint, raises concerns about its potential for arbitrary and significant delays to updates.
Apple suppresses such innovation through a web of contractual restrictions that it selectively enforces through its control of app distribution and its ‘app review’ process
[...]
Apple often claims these rules and restrictions are necessary to protect user privacy or security, but Apple’s documents tell a different story. In reality, Apple imposes certain restrictions to benefit its bottom line by thwarting direct and disruptive competition for its iPhone platform fees and/or for the importance of the iPhone platform itself.
DOJ Complaint against Apple
Browser vendors have their own dedicated security teams which have worked for decades to secure their own browsers. Additionally, Apple has a worse track record than Firefox and Chrome when it comes to the patch gap, as can be shown by evidence from Google Project Zero.
We disagree with the claim that allowing third-party browsers will increase the patch gap for iOS users. Publicly available evidence suggests in fact the opposite is true and will significantly reduce the time it takes for patches to reach users.
Safari updates are tied to the operating system, an antiquated practice. This means to update the browser, users have to update the entire operating system, which further delays patches reaching users. The important metric is the time from when a vulnerability is privately reported – or discovered in the wild – to the date users are protected against a vulnerability. This is known as a “window of vulnerability”.
Google Project Zero - Statistics on Patch Gap.
The above graph shows the number of days from a vulnerability being patched till that patch is actually shipped to consumers for Gecko, WebKit and Blink. WebKit has performed worse than its peers in this important metric.
And that gets us back to the main problem with Apple's security update policy—a lack of transparency, predictability, and communication.
Andrew Cunningham - Ars Technica
For example, Apple took 59 days to land a fix regarding a serious privacy flaw in WebKit’s IndexedDB implementation. Poor communication from Apple caused the FingerprintJS team to disclose the bug before a fix had reached users. Spurred by the public disclosure, Apple quickly developed patches to address the issue, but it took an additional 10 days to package the OS update and ship it.
Leaving the window of vulnerability open this far in the face of publicly disclosed issues does much to draw into question Apple’s claims of protection. If users had credible alternative browsers available to them, they might have been able to better protect their privacy for the week and a half it took Apple to finally fix a long-disclosed issue.
The article titled "Apple’s Poor Patching Policies Potentially Make Users’ Security and Privacy Precarious” goes into more detail.
Under the Digital Markets Act, Apple and Google are required to allow users to uninstall Safari and Chrome on iOS and Android, respectively.
This is important to prevent gatekeepers from positioning their browser to users as “special” and the one that should be used with the operating system. This undermines users' ability to make an unbiased choice. Conversely being able to uninstall the browser however makes it clear that it is simply an app that can be replaced.
Such behaviour includes the design used by the gatekeeper, the presentation of end-user choices in a non-neutral manner, or using the structure, function or manner of operation of a user interface or a part thereof to subvert or impair user autonomy, decision-making, or choice.
Digital Markets Act - Recital 70 (emphasis added)
The AndroidWebView, Android Custom Tabs, WKWebView and SFSafariViewController should be treated as system components, and it should not be possible to uninstall them.
One important condition on that is that both Android Custom Tabs and SFSafariViewController must respect the users choice of default browser and invoke the default browser with handle links clicked in non-browsers. Currently Android Custom Tabs does this in most circumstances but SFSafariViewController is locked to Safari.
We would also support it not being possible to uninstall the default browser until a new default browser has been selected. An appropriate and neutral error message should be displayed if the user attempts to do so.
Additionally it should be possible to reinstall Safari or Chrome if it is uninstalled. This reversibility is important to prevent users from being discouraged from uninstalling the browser.
Apple should be prohibited from having a preferential setup for its own browser. The DMA Article 6(7) mandates that all operating system gatekeepers, including Apple, must share all APIs accessible to their own apps with third-party competitors, subject to strictly necessary, proportionate and justified security measures.
Apple should not be allowed to reserve APIs or API versions exclusively for its browser or engine. All APIs used by WebKit and Safari should be made available to third-party browsers. We are concerned that Browser Engine Kit might require third-party browsers to use different APIs than Safari/WebKit for equivalent features.
It is important that Apple "eats its own dog food" – a common tech industry saying meaning “use its own services every day”, rather than reserve the highest-quality tools for yourself. This will ensure that the APIs in browser engine kit are of sufficient quality and stability to support Webkit/Safari. It will also remove an incentive for Apple to deliberately under-invest in the quality of its open APIs relative to its own private ones.
In some cases third-party browsers may need access to APIs that Safari/WebKit does not use, for example, Safari/WebKit doesn't support the relevant functionality or achieves the same goal using different technical means. In these cases the browsers need to be granted sufficient access to effectively implement the relevant functionality.
(a) enabling access in a way which respects the technical architecture of alternative browser engines;
(b) enabling access to all of the current operating system-level features and functionalities that WebKit and Safari currently use;
(c) enabling access to all other current operating system-level features and functionalities that exist on iOS and are available for use by third-party applications, but which WebKit and Safari currently do not use;
(d) enabling access to future operating system-level features and functionalities available to WebKit, Safari, or third-party applications, whether or not WebKit and Safari choose to use them;
(e) enabling access to the required iOS functionality to allow browser vendors using alternative browser engines to install and manage progressive web apps (PWAs) using alternative browser engines; and
(f) enabling access to the required functionality to allow browser vendors using alternative browser engines to check whether their mobile browser has been set as default
The general concept of a collection of APIs that the browser engine entitlement grants access to in return for agreeing to a set of strictly necessary, proportionate and justified security measures is acceptable and reasonable. However, it is important to note that Apple's current browser engine entitlement contract contains a great many non-security conditions that may not be allowed under the DMA.
Again, giving Apple (rather than a cross-industry body) the power to decide these criteria and to judge competitors’ browser engines against them (rather than an independent auditor working to cross-industry standards, such as GSMA’s plans for mobile phone security) would give the gatekeeper a strong and perverse incentive for under-investment. In addition, any security requirements set out by Apple should also be applied to Safari. If Safari does not meet the same minimum requirements, it would be unreasonable to enforce them on other browsers. Equal enforcement is essential to ensure a level playing field.
Browsers are special as they play a unique role in enabling more easily-developed web apps to compete with the entire native app ecosystem. They are a substitute to the gatekeeper’s app stores and offer a direct consumer-to-business relationship without excessive fees.
From a technical perspective, browsers need privileged operating system access as they power web apps, which are a substitute and competitor to the gatekeeper’s app stores' apps.
In order to allow web apps to effectively contest their native app counterparts, browsers need to provide a wide variety of functionality typically required by native apps, which is interoperable across devices. This requires access to significantly more software and hardware APIs than other applications, including features that may not be exposed by the gatekeeper within an individual ecosystem.
This access is justified by browsers' special role as the world's only truly open and interoperable app development platform, and the high security environment that browsers provide by default. According to Apple: "WebKit's sandbox profile on iOS is orders of magnitude more stringent than the sandbox for native iOS apps".
This is important as it means that Apple does not have any significant unmitigatable security objections to such a change. Apple has also been unable to prove the security of WebKit is superior to that of Blink or Gecko, and there is some evidence to suggest it might in fact be weaker.
Apple had claimed that Safari’s engine’s security was better than that of third-party browsers. This was alluded to in the CMA’s interim report:
the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines.
[...]
Overall, the evidence we have received to date does not suggest that Apple's WebKit restriction allows for quicker and more effective response to security threats for dedicated browser apps on iOS
CMA - Commenting upon Apple’s Arguments
Apple has also argued that Safari's enhanced security was in part a result of its decision to withhold certain security-related APIs from its competitors. The company used this as a justification for limiting the ability of third-party browser vendors to compete on iOS with their own rendering engines. However, Apple's legal team appeared to miss the straightforward solution of sharing these APIs with other browser vendors, which would have addressed this security concern while still allowing fair competition.
WebKit leverages tight integration with iOS hardware. Apple employs a highly effective hardware security extension (APRR) to prevent attackers gaining access to the JIT. Apple also implements Pointer Authentication Codes (PAC) to prevent attackers from gaining code execution outside of the JIT. PACs provide cryptographic signatures and authentication to function pointers and return addresses to protect against the exploitation of memory corruption bugs
[...] third-party vendors’ browser engines would lack important features and security protections that WebKit gains from its tight integration with Apple Silicon and iOS. For example, no third-party engine would offer PACs. More critically, no third-party engine would offer an equivalent to the hardened sandbox profile resulting from WebKit’s integration with iOS to protect against malicious web-based attacks.
Apple’s response to the CMA’s interim report (emphasis added)
Note this was in response to the UK regulator. Under the DMA Apple is required to share hardware and software APIs, subject to strictly necessary, proportionate and justified security measures.
Browsers have dedicated, experienced security teams and should have a presumption of access to necessary software and hardware functionality for the purposes of implementing web specifications – particularly those developed by independent standards organisations (which comply with best practice, such as the EU’s Standardisation Regulation)
Article 6(7) of the DMA obliges Apple and Google to provide access to all software and hardware APIs that are available or used by the gatekeeper’s services or hardware provided by the gatekeeper regardless of whether they are part of the operating system when providing such services:
The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services.
DMA - Article 6(7)
In this instance the primary security measure is vetting to provide the browser entitlement and revoking it when abused. The browser is a trusted party that implements its own very significant sandboxing. This access can be safely provided, and is justified by the benefits to businesses, consumers and competition in general.
Browsers need access to everything that they reasonably need to implement features, stability, performance, functionality, security and privacy. This is needed to allow fair competition.
All major browsers have dedicated security teams. Apple has been unable to prove that Safari or WebKit are actually more secure than its competitors and this claim has been rejected by the UK regulator. They have also claimed that third-parties will be unable to as securely implement JIT due to Apple refusing to share particular security related APIs.
Given this Apple has no “strictly necessary, proportionate and justified” reason to block third-party browsers with the browser engine entitlement from competing in the provision of JIT and to our knowledge and to Apple’s credit, they made no attempt to do so.
Note: Windows, Linux, MacOS, ChromeOS and Android allow JIT for all browsers.
Having multiple competing browsers on iOS will improve security. If a major security issue arises in Safari, consumers could switch to a different browser while waiting for Safari to be patched, which requires a full OS update. This will directly encourage better competition among browsers to improve their security on iOS.
Requiring JIT support by dominant operating systems will make it much easier for developers to write cross-platform apps which can compete on a nearly level playing-field with native apps.
“Certain services provided together with, or in support of, relevant core platform services of the gatekeeper, such as identification services, web browser engines, payment services or technical services that support the provision of payment services, such as payment systems for in-app purchases, are crucial for business users to conduct their business and allow them to optimise services. In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users.”
That is, part of the purpose of Article 5(7) in preventing gatekeepers from imposing browser engines (which only Apple currently does) is to prevent gatekeepers from determining the functionality available to all browsers on the operating system and in turn web software applications.
In order for third-party browsers on iOS to deliver better web app functionality than what Apple supplies via Safari, Apple needs to allow third-party browsers to install and manage Web Apps using their own browser engine.
Web apps are interoperable, open and have no gatekeeper fees attached to them. They fit neatly into the aims of the DMA to encourage interoperability, fairness and contestability. In order to allow businesses and consumers to enjoy the full benefits of their rights under DMA Article 5(7), the European Commission should take the steps we describe in this document, as they fully developed this requirement in relation to Article 6(7), with their first technical specification under the DMA.
For example, ‘equivalence of access’ would need to include enabling third-party browsers using alternative browser engines to install and manage PWAs (rather than relying on WebKit to support parts of this process), including enabling mobile browsers using alternative browser engines to implement installation prompts for PWAs.
MIR - Provisional Decision Report
A number of the above requirements would need to be complemented by ensuring Apple: (i) permits browser apps to use alternative browser engines; and (ii) enables browser vendors using alternative browser engines to install and manage progressive web apps
SMS Investigation into Apple and Google
Fleeceware is a type of malware mobile application that comes with hidden, excessive subscription fees or services that don’t exist or are available for free, i.e. with the operating system.
Phishing apps are apps designed to trick you into providing personal information, typically by impersonating a known company or app.
Both the Google Play Store and the Apple App Store have extensive and persistent problems with both types of malicious apps. These types of apps are illegal under consumer protection laws in many jurisdictions, and are also subject to enforcement under the EU’s Digital Services Act which applies to any platform serving EU residents, regardless of where the app developer or app store is based.
Researchers at Avast have discovered a total of 204 fleeceware applications with over a billion downloads and over $400 million in revenue on the Apple App Store and Google Play Store. The purpose of these applications is to draw users into a free trial to 'test' the app, after which they overcharge them through subscriptions which sometimes run as high as $3,432 per year. These applications generally have no unique functionality and are merely conduits for fleeceware scams. Avast has reported the fleeceware applications to both Apple and Google for review.
The fleeceware applications discovered consist predominantly of musical instrument apps, palm readers, image editors, camera filters, fortune tellers, QR code and PDF readers, and ‘slime simulators’. While the applications generally fulfil their intended purpose, it is unlikely that a user would knowingly want to pay such a significant recurring fee for these applications, especially when there are cheaper or even free alternatives on the market.
Jakub Vávra - Avast
The above reporting would mean that between them Apple and Google directly made $130 million on just the fleeceware apps discovered and reported by Avast. To our knowledge neither company refunds money gained from fleeceware.
This incredible email and pdf is worth a read to understand how fleeceware works on the iOS app store.
A step-by-step guide to a $500k/month scam:
Step 1. Identify things people search and get for free on the internet
Step 2. Never produce any of this content but instead get it for free on the internet
Step 3. Build a cheap, low quality app and add the free content
Step 4. Falsely advertise free stuff though Apple Search Ads
Step 5. Make thousands of users pay $100s without knowing
Step 6. Scam user ratings so you don't get caught (breaking all of Apple's guidelines)
Email to Trystan Kosmynka - Apple App Review Chief
Part of the issue that allows such scams to thrive isn’t just that app review is ineffective, it's also that by design it's easy to sign up for subscriptions for a trial and awkward to unsubscribe.
Internal Apple slide discussing how hard it is to cancel subscriptions.
This is discussed in this email by Eric Friedman (Apple’s Head of Fraud) which mentions “clear paths for managing your subscriptions” and how the confusion interface helps such scams. In particular searching for “cancel subscription” yielded no results and deleting an app should cancel its subscription.
What is particularly striking about fleeceware apps and phishing apps, is that they are one of the few types of malware that human review might actually be potentially helpful as even a brief review (involving clicking around the interface) should reveal them to be scams – but even at this task the human review element of app store review appears to be failing.
There are some very basic steps that Apple and Google could take to help reduce the amount of malware and fraud on the Apple iOS app store and the Google Play Store:
Cancel subscriptions (or at least prompt) upon deleting an app (Apple and Google)
Ask if users would like to convert their free trial to a paying subscription at the end of the trail (Apple and Google)
Allow users to report malware in the app store (Apple)
If an app is found to be malware, investigate other apps by the same developer (Apple)
Refund money lost to obvious fleeceware scams - or at a minimum, refund the 30% cut the gatekeeper takes (Apple and Google)
Even services such as iCloud are not immune to phishing attacks. Most infamous has been the 2014 iCloud phishing attack, when nearly 500 private pictures of various celebrities, mostly women (many containing nudity) were posted online.
Collins allegedly sent e-mails to the victims that appeared to come from Google or Apple, warning the victims that their accounts might be compromised, and asking for their login details. The victims would enter their password information. Having gained access to the e-mail address, Collins was able to download e-mails, and get further access to other files, such as iCloud accounts.
According to the prosecutors, he was able to access more than 120 different Gmail and iCloud accounts, and he is being tried for a felony violation of the Computer Fraud and Abuse Act.
Haje Jan Kamps - TechCrunch
To be clear, this is not to suggest any wrongdoing on Apple’s behalf, but it highlights how difficult it is to protect users from phishing attacks even in relatively secure systems. In this case the users were tricking into emailing their passwords to the attacker:
We wanted to provide an update to our investigation into the theft of photos of certain celebrities. When we learned of the theft, we were outraged and immediately mobilized Apple’s engineers to discover the source. Our customers’ privacy and security are of utmost importance to us. After more than 40 hours of investigation, we have discovered that certain celebrity accounts were compromised by a very targeted attack on user names, passwords and security questions, a practice that has become all too common on the Internet. None of the cases we have investigated has resulted from any breach in any of Apple’s systems including iCloud® or Find my iPhone. We are continuing to work with law enforcement to help identify the criminals involved.
Apple’s Statement on the iCloud Phishing Attack
The most dangerous feature that browsers have are not the device API’s; it is the ability to link to and download native apps.
Niels Leenheer - HTML5test
Finally, if we find that features and web APIs increase fingerprintability and offer no safe way to protect our users, we will not implement them until we or others have found a good way to reduce that fingerprintability.
Apple - Webkit Engineer
Further, via their browser engine ban, they have blocked third-party browsers from being able to safely provide the functionality.
This de-facto forces users to install an equivalent native app over a Web App if that API is a key part of the functionality offered by the app.
As a result an obvious comparison arises as to the level of security and privacy protection that goes into Web APIs vs Native APIs.
The security risks of device APIs, for both Web Apps and Native Apps, are real. Browser vendors go to extreme lengths to mitigate them. Obviously, not having these APIs is safer, in the same sense that it would be safer to entirely remove the functionality from the hardware. For example it is impossible for a phone without a camera to secretly take photos of you.
There is an inherent opposition between utility and security. What is important is to maximise utility while taking all proportionate steps to mitigate security risks.
Browser vendors care deeply about these risks and discuss them, including built-in mitigations, extensively when designing APIs. For example, a number of potential security and privacy issues have been raised by participants in the Working Group developing the Web Bluetooth standard.
In order to mitigate these risks, rigorous analysis led to industry-leading constraints on the use of potentially identifiable information:
Web Apps can not get a list of bluetooth devices.
Sites can only connect to devices that the users explicitly select through browser-controlled UI.
Web Apps cannot bypass user consent.
Ambient indicators (icons) are displayed when in use, allowing users to easily revoke permissions.
Web Apps cannot connect to devices when in the background.
User consent is not guaranteed to be permanent and the users may be occasionally re-prompted to reduce abuse.
Native Bluetooth, by contrast, has incredibly weak protections in iOS. Once initial Bluetooth permission is granted, iOS applications have free rein to do what they will. They can list all nearby devices (without user interaction) and communicate with any nearby Bluetooth device (without user interaction or notice).
Prior to iOS 13 (late 2019) the situation was even worse. Applications did not even need to ask for Bluetooth permission, instead silently granting the ability to track and scan users pervasively to any app that could come up with a plausible cover story for accessing the permission for any use-case. Even now, the warning/consent user interface could be clearer.
Many companies used this misfeature to track users' locations without their consent. Shops placed Bluetooth beacons in their stores to track users' physical location without consent (in the way many others do using Wi-Fi – which Apple previously took significant steps to protect against, with its rotating MAC addresses). This was only possible due to the weak security and privacy implementation on iOS Native CoreBluetooth. This still has not been fixed and this sort of abuse is still possible today, provided an application can convince a user that it has a plausible reason to provide access to Bluetooth (a simple yes/no prompt).
Prompt to enable bluetooth for an app.
This is currently unmitigated except by:
App Store Review, a dubious defense.
Users granting permission to access Bluetooth only once.
App store “review” has been shown time and again to fail to protect users from more obvious attacks, including malware and scams. Trusting overworked, semi-technical reviewers to police the interaction of incremental data collection and iOS’s thicket of “legitimate interest” permissions strains credibility to breaking point. At best, this approach reflects a marketing narrative rather than a credible security strategy.
This is important as sandboxes are a key tool in preventing apps from gaining access to data that the users have not granted them permission to access.
Orders of magnitude, while correct, is also a striking phrase. That is, not slightly better but hundreds to thousands of times stronger.
Web Apps have never provided a high-fidelity unique identifier (AdID/IDFA). This meant that Apple’s “App Tracking Transparency” effort was not a net improvement in privacy relative to Web Apps, but a removal of a bug by comparison.
Up until iOS 10 (2016) there was no way for users to disable AdID. Since iOS 14 (2020) users have been asked via this slightly ambiguous prompt:
Prompt to enable tracking for app.
Even when users do not consent to Apple uniquely identifying them to Native Apps, the privacy and security model of platform-specific apps is permissive relative to the Web. Native Apps facilitates this fingerprintable collection through myriad APIs not available to Web Apps, or only available to Web Apps behind permission prompts:
When it comes to stopping third-party trackers, App Tracking Transparency is a dud. Worse, giving users the option to tap an ‘Ask App Not To Track’ button may even give users a false sense of privacy
Johnny Lin - Lockdown co-founder, Former Apple iCloud engineer
For example, when users did not consent to be tracked via ATT on iOS, platform-specific games such as Subway Surfers ‒ listed as one of the App Store’s “must-play” games ‒ collected and shared with advertisers the following data – in late 2021, years after Apple began advertising under the slogan “Privacy. That’s iPhone.”:
Device Name (e.g., “John’s iPhone X”)
Accessibility Setting: Bold Text
Accessibility Setting: Custom Text Size
Display Setting: Dark Mode
Screen Resolution
Time Zone
Total Storage Space (bytes precision)
Free Storage Space (bytes precision)
Currency (e.g., “USD")
iOS Version
Audio Output (e.g., “Speakerphone”/"Bluetooth")
Audio Input (e.g., “iPhone Microphone”)
Accessibility Setting: Closed Captioning
Country
Cellular Carrier Name (E.g., “AT&T")
Cellular Carrier Country
Last Restart Time (Exact Timestamp, Second Precision)
Our investigation found the iPhone’s tracking protections are nowhere nearly as comprehensive as Apple’s advertising might suggest. We found at least three popular iPhone games share a substantial amount of identifying information with ad companies, even after being asked not to track.
When we flagged our findings to Apple, it said it was reaching out to these companies to understand what information they are collecting and how they are sharing it. After several weeks, nothing appears to have changed.
Geoffrey Fowler And Tatum Hunter - Washington Post
...an analysis of a number of popular iPhone apps found that they were sending a crazy amount of data about your device to an ad company. It seems pretty obvious that the specificity of this data is designed to fingerprint your device.
Ben Lovejoy - 9to5mac
“Fingerprinting” is the ability to uniquely re-identify users silently, based on information available without any consent prompt.
This effort does not meaningfully limit runtime use of APIs or impose data use policies on App Store publishers. Instead, it only requires developers to attest to a “reason” for their data request.
Apple has begun to belatedly introduce unenforced “nutrition labels” that shift the burden of understanding tracking by native apps onto the user:
But this is only the tip of the iceberg. Now the app stores should take the next step: ban SDKs from any data brokers that collect and sell our location information.
There is no good reason for apps to collect and sell location data, especially when users have no way of knowing how that data will be used. We implore Apple and Google to end this seedy industry, and make it clear that location data brokers are not welcome on their app stores
We do not claim that tracking on the web is not a problem, i.e. third-party cookies being the primary example. Restrictions on collection are worthy of continued investment, and Apple’s work to spur improvements in this area are laudable.
However, these developments cannot be assessed in isolation, they must be viewed against the backdrop of pervasive tracking within native app ecosystems.
Users are conditioned to be wary of unknown websites. They're taught to scrutinize the URL, look for suspicious elements, and avoid clicking on links from unfamiliar sources.
However, this same level of scrutiny is rarely applied to app stores. Users often assume that apps available on official platforms like the Apple App Store or Google Play Store have been thoroughly vetted and are safe to download. This false sense of security stems from the perception that these stores are carefully reviewed ensuring the quality and trustworthiness of the apps they host.
Google Safe Browsing helps protect over five billion devices every day by showing warnings to users when they attempt to navigate to dangerous sites or download dangerous files. Safe Browsing also notifies webmasters when their websites are compromised by malicious actors and helps them diagnose and resolve the problem so that their visitors stay safer. Safe Browsing protections work across Google products and power safer browsing experiences across the Internet.
Google Safebrowsing
Google Safe Browsing is a live list of known fraudulent websites made available to all browsers to help display warnings to users. The average lifetime of a phishing website is less than 10 minutes under this system.
Recently Apple has been pointing to this article about cybercriminals attempting to trick Android and iOS users into installing Web Apps masquerading as banking apps.
The fact this is listed as the first (and only) attempt at this type of exploit despite the feature being available for more than 15 years on iOS and 9 years on Android is an indication of the significant barriers this method has to success.
Users are already trained to be suspicious of unknown urls received in text messages. When installing a PWA, the site’s domain is shown in the search bar and in the installation UI, and unlike native apps, PWAs need the user's permission to change their name or logo after installation. The apps are essentially just websites so have no special access once installed. They are not given access to any of the vast array of data that native apps on iOS and Android are provided without permission from the users.
Apple has not been able to produce any evidence that users are more susceptible to phishing attacks via the web, nor have they published detailed statistics on phishing attacks via the iOS app store. Given that users have no false sense of security on the web, are trained to distrust unknown URLs, and there are significant safeguards against phishing built into browsers, Web Apps are at a significant advantage in defending users against phishing.
Fleeceware appears to be significantly more prevalent on app stores than the web and the term is almost exclusively used to refer to mobile apps on app stores. Most malware sites link users to listed fleeceware apps on the app store. In this example below the install button is simply a link to Apple’s app store.
Fake virus scam advert in Safari linking to fleeceware on the iOS App Store.
There are a number of good reasons for this:
App Stores have frictionless payment setups with difficult or hidden options to cancel subscriptions.
Web Apps typically use independent payment processors (e.g. Stripe, PayPal), typically requiring more user intent to subscribe.
Users are lulled into a false sense of security by the marketing of app store review.
Browsers don’t facilitate one-click subscriptions, so friction protects users.
Web Apps are also significantly stronger against other forms of attacks due to their orders of magnitude stronger sandboxing and more stringent permissions.
OWA believes that the Web’s unmatched track record of safely providing frictionless access to information and services has demonstrated that it can enable a more vibrant digital ecosystem. The web’s open, interoperable, standards-based nature creates an inclusive environment that fosters competition, delivering the benefits of technology to users more effectively and reliably than any closed ecosystem.
OWA’s goal is to ensure that browser competition is carried out under fair terms, that user choice in browsers matters, and that web applications are provided equal access and rights necessary to safely contest the market for digital services.
OWA believes competition, not walled gardens, leads to the brightest future for consumers, businesses, and the digital ecosystem.
]]>
Industry Voices Caution Against DOJ’s Plan to Force Sale Of Chrome2025-05-01T00:00:00Zhttps://open-web-advocacy.org/blog/industry-voices-caution-against-dojs-plan-to-force-sale-of-chrome/Share and join the conversation: X/Twitter, Mastodon, LinkedIn and Bluesky.
In late 2020, the U.S. Department of Justice (DOJ), in conjunction with state attorneys general representing 11 states, brought a landmark antitrust case against Google for unlawfully maintaining a monopoly in the general search engine market. In August 2024, Judge Mehta ruled that “Google is a monopolist, and it has acted as one to maintain its monopoly”.
We believe this ruling was correct, necessary, and that the DOJ’s case is compelling.
Last week, the DOJ formally asked Judge Amit P. Mehta to order Google to divest its Chrome web browser. The request came during opening statements in a three-week remedies hearing at the U.S. District Court in Washington, D.C.
David Dahlquist, leading the DOJ’s arguments, stated:
Your honor, we are not here for a Pyrrhic victory. This is the time for the court to tell Google and all other monopolists who are out there listening — and they are listening — that there are consequences when you break the antitrust laws.
David Dahlquist - Justice Department Lawyer
We agree with the DOJ.A hollow win that leaves Google’s monopoly intact is not beneficial to either US consumers or businesses, and Google’s counter-proposals will not fix the underlying problem: that Google held and has abused its monopoly in search.
However, we’re concerned that if the DOJ goes too far, particularly by forcing a sale of Chrome and banning search deals with smaller browser vendors like Mozilla, it will do lasting harm to the web platform. We estimate that such remedies could cause a 70% drop in web platform investment and could potentially bankrupt Mozilla.
Very balanced and well articulated thread and blog post as to why splitting Chrome from Google would be disastrous for the web–and how there are much better measures to fix the monopoly problem. Malte Ubl - Vercel CTO
Google Chrome ending up in the wrong hands due to DOJ intervention could be catastrophic for the open web and backfire entirely.
Few organizations in the world meet the bar of having the web’s best interests in mind, the technical infrastructure and know-how, and the immense required funding.
Working on a browser involves two main areas: the engine and its frontend, like a car’s engine and its chassis & dashboard. Google has done a *phenomenal* job on the engine, which is one of the absolute hardest technical undertakings in the world, and curiously enough is actually fully open source.
Blink, Chrome’s engine, is BSD and LGPL licensed, developed in the open, and powers so many of Google’s competitors, including Microsoft Edge, Brave, Opera, Vivaldi, Browser Company’s Arc/Dia, and dozens of others at no cost. It’s absolutely essential that this work stays uninterrupted, while we continue to invest as a community in engine diversity, including projects like @ladybirdbrowser of which I’m a proud backer.
And Blink is just one piece, in charge of rendering. Google has built and open sourced many other crucial engine components like the V8 JavaScript engine, Skia, PDFium, Cronet, and many others, bundled as part of the open Chromium distribution. The complexity of what makes a modern browser work is truly staggering. Thank you Google.
The DOJ is taking particular issue with the engine’s frontend, the actual thing consumers download and interact with. This is where Google has the unique privilege to package and distribute the open source engine components, and impose arbitrary rules and configurations on top, like search engine defaults, AI assistance models, telemetry capture, login / accounts integration, settings and history sync, Web Store rules (like which ad blockers can be distributed), etc. At the scale Google is operating and the power it confers, scrutiny and caution here is warranted.
I believe, however, that the best path forward will be an incremental one, maintaining the careful balance of a browser frontend that has the everyday internet citizen’s best interests in mind, while not disrupting the investment and support of such crucial open internet infrastructure that benefits us all.
Guillermo Rauch - Vercel CEO
# Ilya Grigorik - Distinguished Engineer at Shopify
Building an app, convincing users to install, and then to engage with it presents an incredibly high bar and massive friction. Major brands with established fans can achieve escape velocity, but the millions of SMBs trying to make their first sale? They stand no chance. They're operating on razor-thin margins, and the online store is the primary and predominant channel of choice because it is a one-tap destination for the potential buyer. It is also the only channel that gives them full creative control, one-tap open and permissionless discovery, and direct relationship with the customer. Continued success of the open web platform is essential to the success of all merchants, and existential for most SMBs. Ilya Grigorik - Distinguished Engineer at Shopify
This was a seriously great, informative and well researched read. Chrome, and Googles huge investments in the browser, are crucial if we want to maintain an open web. I knew that, but never thought of what it would mean for Firefox. Or that it could really harm small eCommerce businesses who don't have an native app.
# Aravind Srinivas - Cofounder & CEO of Perplexity
Perplexity has been asked to testify in the Google DOJ case. Our core points:
1. Google should not be broken up. Chrome should remain within and continue to be run by Google. Google deserves a lot of credit for open-sourcing Chromium, which powers Microsoft's Edge and will also power Perplexity's Comet. Chrome has become the dominant browser due to incredible execution quality at the scale of billions of users.
2. Android should become more open to consumer choice. There shouldn't be a tight coupling to the default apps set by Google, and the permission for OEMs to have the Play Store and Maps. Consumers should have the choice to pick who they want as a default search and default voice assistant, and OEMs should be able to offer consumers this choice without having to be blocked by Google on the ability to have the Play Store and other Google apps (Maps, YouTube).
The DOJ is pushing for Chrome to be divested from Google. We don't believe anyone else can run a browser at that scale without a hit on quality, nor the business model to be able to serve that many users profitably by keeping the browser free. Chromium is open source, and others can build using that. Evidence: Microsoft Edge and Perplexity's upcoming Comet browser.
The thing that is particularly frustrating about Google to us is how hard it is to change anything on Android. OEMs can only use a Google-approved version of Android, if they want to have core Google apps like PlayStore, Maps, etc. And "Google-approved" means keeping Google as the default search and Google/Gemini as the default voice assistants.
OEMs feel threatened about any changes here even outside the defaults, because the magnitude of revenue sharing offered to them by Google to preserve the status quo even when better alternatives are available. Eg: Perplexity's Android Assistant is regarded as superior to Gemini.
The remedy that is right in our opinion is not a breakup of Google; but rather offering consumers the choice to pick their defaults on Android without feeling the risk of a loss in revenue. That's what we will be proposing.
Aravind Srinivas - Cofounder & CEO of Perplexity
# David Heinemeier Hansson - CTO of 37signals and Creator of Ruby on Rails
The web will be far worse off if Google is forced to sell Chrome, even if it's to atone for legitimate ad-market monopoly abuses. Which mean we'll all be worse off as the web would lose ground to actual monopoly platforms, like the iOS App Store and Google's own Play Store.
First, Chrome won the browser war fair and square by building a better surfboard for the internet. This wasn't some opportune acquisition. This was the result of grand investments, great technical prowess, and markets doing what they're supposed to do: rewarding the best. Besides, we have a million alternatives. Firefox still exists, so does Safari, so does the billion Chromium-based browsers like Brave and Edge. And we finally even have new engines on the way with the Ladybird browser.
Look, Google's trillion-dollar business depends on a thriving web that can be searched by Google.com, that can be plastered in AdSense, and that now can feed the wisdom of AI. Thus, Google's incredible work to further the web isn't an act of charity, it's of economic self-interest, and that's why it works. Capitalism doesn't run on benevolence, but incentives.
We want an 800-pound gorilla in the web's corner! Because Apple would love nothing better (despite the admirable work to keep up with Chrome by Team Safari) to see the web's capacity as an application platform diminished. As would every other owner of a proprietary application platform. Microsoft fought the web tooth and nail back in the 90s because they knew that a free, open application platform would undermine lock-in — and it did!
But the vitality of that free and open application platform depends on constant development. If the web stagnates, other platforms will gain. But with Team Chrome pushing the web forward in a million ways — be it import maps, nested CSS, web push, etc. — is therefore essential.
This is a classic wealth vs. riches mistake. Lawyers see Chrome as valuable in a moment's snapshot, but the value is all in the wealth that continued investment brings. A Chrome left to languish with half the investment will evaporate as quickly as a lottery winner's riches. Wealth requires maintenance to endure.
For a long time now, I've been trying to discuss what, to me, is a rather worrying problem: That those default search dollars are, in the end, what funds the whole web ecosystem. Don't forget that it's not just about the web itself, it's about the platform which provides the underlying technology for just about everything else at this point too.
Between years of blog posts, a podcast series, several talks, experiments like Open Prioritization I have been thinking about this a lot. Untangling it all is going to be quite complex.
In the US, the governments proposed remedies touch just about every part of this. I've been trying to think about how I could sum up my feelings and concerns, but it's quite complex. Then, the other day an article on arstechnica contained an illustration which seemed pretty perfect..
This image (credited to Aurich Lawson) kind of hit the nail on its head for me: I deeply hope they will be absolutely surgical about this intervention, because the patient I'm worried about isn't Google, it's the whole Web Platform. Brian Kardell - Developer Advocate at Igalia
There are also two podcasts hosted by Brian Kardell and Eric Meyer that are worth checking out. One features a discussion with us, and the other with Chris Coyier:
It’s hard to come up with a buyer who could afford to pay a high price for Chrome and who would pass regulatory muster as its new owner. And if Chrome is not worth a high price, or simply isn’t sellable at one because there’s no plausible buyer, then why is the DOJ trying to force Google to sell it? They might as well try to force Google to sell the two o’s from its name.
[...]
This is the aspect of the US case against Google that most shows the DOJ has little real idea how anything actually works in tech. The non-Google aspects of Chrome are completely open source. No need for dick quotes around the “open” there. Just go to the Chromium project and download the code, which includes all of Blink, Chromium’s web engine that Google forked from WebKit in 2013. There’s even an open source project called Ungoogled Chromium that delivers a completely Google-free Chromium experience. Everything about Chromium, the browser app, looks and feels like Chrome. Except it doesn’t have any of the integration with Google’s web services and your Google account(s).
There are dozens of for-profit browsers built from the Chromium code base. Microsoft’s Edge. Brave. Vivaldi. Even the venerable Opera — a browser that first debuted in 1994! — became a forked version of Chromium a decade ago.
We know the value of a Google-free version of Chrome. Nothing. Zero. You can install and use that browser today, or even modify and compile its source code, free of charge. And if a commercial entity wants to take that base and build its own proprietary layer on top of that, they can do it. Microsoft and Brave and the others already have. And we know how popular those browsers are — which is not very popular at all.
[...]
The more I think about it, the more it looks to me like a complete fantasy that Google even could sell Chrome. It would be at least a somewhat different situation if Chrome were mostly closed source. But it’s not. In fact, it’s the opposite — it’s almost entirely open source. So what even is there to buy?
John Gruber - Daring Fireball
# Chris Coyier - Co-founder of CodePen, ShopTalk Podcast and Creator of CSSTricks
Google Being Forced To Sell Chrome is Not Good for the Web
[...]
It’s true that Chrome ships with Google as the default search engine, because, ya know, they invested billions in Chrome and that’s how business works. But still, a more direct line from problem to solution is forcing default search engine choice, not a forced sale of Chrome itself.
Why do I care? The sale of Chrome is bad for the web.
[...]
Google, by virtue of having Chrome, invests heavily in the web itself. Not just Chrome-the-browser, but the web standards that power the web. I can’t claim to know every detail of that investment, but I personally know people employed by Google that literally just try to make the web better all day.
[...]
Will Google continue to invest like this if they are forced to sell Chrome? It would be hard to blame them if they did not.
Assuming they find a buyer, that buyer will be scrambling to find a way to make that investment worth it. Will they be choosing to employ people who are just abstractly making the web better? I would think not.
The remedies phase of the trial is expected to last three weeks, during which the U.S. Department of Justice and Google will present arguments, expert testimony, and rebuttals. The central question is not whether Google broke the law, Judge Amit P. Mehta has already ruled that it did, but rather what remedies are appropriate to restore competition in the search market without causing disproportionate harm to consumers or the broader digital ecosystem.
Following the hearings, Judge Mehta will deliberate and is expected to issue a final judgment later this year, likely by August 2025. His ruling will determine which, if any, of the DOJ’s proposed remedies, including the forced divestiture of Chrome and the prohibition of default search deals, will be imposed on Google.
Whatever the outcome, it won’t be the final word. Google has already stated that it intends to appeal any adverse decision, potentially setting the stage for a prolonged legal battle that could reach the D.C. Circuit Court of Appeals and possibly the U.S. Supreme Court.
]]>
Is It Worth Killing Mozilla to Shave Off Less Than 1% From Google’s Market Share?2025-04-28T00:00:00Zhttps://open-web-advocacy.org/blog/is-it-worth-killing-mozilla-to-shave-off-less-than-1-percent-from-googles-market-share/Share and join the conversation: X/Twitter, Mastodon, LinkedIn and Bluesky.
Late last year the DOJ won their long running antitrust case vs Google when Judge Mehta ruled in their favor declaring unequivocally that “Google is a monopolist, and it has acted as one to maintain its monopoly”. Last week the remedies part of the trial started. Among the numerous remedies that the DOJ is asking for, is an effective total ban on revenue sharing deals between Google and browser vendors.
One obvious concern with cancelling these deals is that this will bankrupt Mozilla, the maker of the Firefox browser and the Gecko browser engine, who is heavily reliant on their search deal with Google. This was directly acknowledged by the court:
THE COURT: So I mean, it seems to me Mozilla, in some sense, would have a more compelling argument than you because it's not like Apple is going to go out of business if I don't -- you know, if you can no longer get revenue share.
You've got other sources of revenue; Mozilla hardly has any.
UNITED STATES OF AMERICA vs GOOGLE LLC
Google has agreements with several browser vendors to set Google as the default search engine for users who have not previously made a manual choice. In return, Google shares a portion of the revenue it earns from searches performed through those browsers. Google is estimated to pay Mozilla approximately $410-420 million per year.
During the case, evidence showed that Mozilla reinvested the vast majority of its Google search revenue into Firefox and Gecko. However, its market share, under 3%, was deemed too small to deliver a significant public benefit.
Mozilla plays a uniquely valuable role in the internet ecosystem as a non-profit committed to an open, secure, and user-centric internet. Despite its modest market share, Mozilla has a large influence on web standards, holding equal footing with Google and Apple in governance bodies like the W3C TAG. Mozilla also maintains its own independent engine, Gecko, which ensures diversity in browser implementations. Gecko is one of only three engines left in major usage. Mozilla frequently serves as a crucial third implementor voice in standards discussions, offering a non-profit perspective grounded in the public interest. Removing Mozilla from this equation would do far more harm to the long-term health of the web than any marginal competitive benefit from eliminating its Google deal, especially when other remedies could already push Google’s search engine market share below 50% and the drop in Google’s share from this remedy is so negligible.
One might reasonably ask: couldn’t Mozilla simply sign a deal with another search engine, such as Bing or DuckDuckGo? It’s a fair question and worth examining closely.
Given these dynamics, it is unlikely Microsoft would engage in a major bidding war to secure a deal with Mozilla, especially without Google driving prices up. Crucially, the bargaining power would lie with Microsoft, not Mozilla. After all, Microsoft and Bing are at no risk of bankruptcy were a deal to fall through.
One way to estimate the potential value of a Microsoft-Mozilla search deal is by looking at the ratio of market shares. Microsoft was willing to pay around $4 billion per year to be the default search engine for approximately 33.5% of the U.S. search market (68% impacted by Apple deal × 50% Apple Devices U.S. Search Share). Applying the same ratio, Mozilla’s less than 1.15% share would translate to roughly $130 million per year (4000 ÷ 33.5 × 1.15).
However, even this figure likely overstates the real value. It's highly improbable that Microsoft would offer Mozilla a 90% revenue share, they offered Apple. A more realistic offer would likely resemble the 36% rate that Google agreed upon with Apple.
Finally this 1.15% figure includes all small browsers, not just Mozilla.
Taking that into account, any search deal Microsoft might offer Mozilla would realistically fall between $40 million and $130 million per year, with the upper bound being unlikely. A more plausible figure would be closer to $40 million annually.
Some have argued that Mozilla’s current budget could serve as a baseline for reasonable investment in the web platform. This view is fundamentally flawed.
Firefox is a shrinking browser, struggling to maintain its market share. To thrive, not merely survive, Mozilla needs significantly more funding than it currently receives. Treating its already constrained budget as a benchmark ignores the reality that Firefox is not operating from a position of strength.
Unlike smaller Chromium-based browsers that can rely heavily on Google’s ongoing investment, Mozilla must independently fund and develop both its browser and its engine, Gecko. This independence is both a strength and a burden, requiring substantial ongoing investment to keep pace with evolving web standards and competitive features.
Although Mozilla has strong financial reserves today, losing even three-quarters, or worse, nine-tenths, of its current revenue would be devastating. At a minimum, it would almost certainly cancel its Gecko port to iOS, and force mass layoffs among its browser engineering teams.
While Mozilla might avoid outright bankruptcy, it would quickly fade into irrelevance. Without sufficient ongoing development, Gecko would likely follow the fate of other abandoned browser engines like Trident, EdgeHTML, and Presto.
We propose that smaller browsers, such as Mozilla, be allowed to sell 100% of their default search placement to Google. This carve-out is justified because, while these smaller browsers account for only a minor share of search traffic, they play a vital role in sustaining browser competition and in governing the open web. A healthy browser market depends on preserving these potential future challengers.
Two potential concerns might be raised:
Growth scenario: A smaller browser, such as Firefox, Opera, Vivaldi, or Samsung Internet, could significantly grow in market share over 5–10 years, reaching 20–40% of the browser market. While such growth is highly desirable from a competition standpoint, it could become problematic if Google continued paying for 100% of the default search placement at that scale.
Aggregate deals scenario: Google might strike numerous deals with smaller browsers, which in aggregate could exceed the 50% market share cap.
Both scenarios are solvable and, in our view, unlikely.
For the first case, the 50% cap could be applied progressively as a browser grows. The key is to avoid any disincentive for smaller browsers to expand their market share. Their revenue should increase as their user base grows, not decrease due to a hard threshold. This can be achieved with a tapered formula that gradually reduces the allowable default share Google can purchase, while ensuring that increased market share always results in increased revenue.
For the second concern, Google’s ability to pursue aggregate deals could be limited by enforcing a strict overall cap, e.g., prohibiting it from purchasing more than 50% of total browser defaults. This should be coupled with a ban on bundling or coercive agreements through arrangements like MADA or OEM partnerships that artificially steer distribution.
There are, of course, numerous implementation details to be considered. But the core idea is straightforward: it’s possible to design clear, practical mechanisms that protect the viability of smaller browsers without undermining the broader goals of the DOJ’s remedies.
# If Mozilla Gets to Keep Their Deal, Then Should Apple?
No, in our opinion this deal offers very limited benefit, suppresses rather than promotes competition in the adjacent browser market, is substantial in scale, and appears poised to be highly effective in maintaining Google's dominance. Canceling this deal by our estimate will reduce Google’s U.S. search market share by approximately 21.8% to 30.2%, potentially single-handedly reducing Google’s United States market share to below 60%.
# Do We Really Want a World in Which Mozilla No Longer Exists?
It is true that Mozilla’s management has made missteps, as any long running organization might. However, it is equally true that anti-competitive practices by both Apple and Google, have made it nearly impossible for Mozilla to gain meaningful share in the mobile market. This has limited its ability to generate revenue and denied it the room to recover from mistakes that larger companies can more easily absorb.
The real question for readers is not whether Mozilla is perfect. It is: Do you truly believe the web would be better off in a world where Mozilla no longer exists?
]]>
Break Google’s Search Monopoly without Breaking the Web2025-04-23T00:00:00Zhttps://open-web-advocacy.org/blog/break-googles-search-monopoly-without-breaking-the-web/Share and join the conversation: X/Twitter, Mastodon, LinkedIn and Bluesky.
Web platform (noun): The technology and tools that let websites and web apps work in your browser.
Key Takeaways (TL;DR)
DOJ wants to force Google to sell Chrome and ban search engine revenue share deals with other browser vendors, resulting in a 70% drop in funding for the web platform.
Progress in new web features could stagnate, and the performance, stability of the existing web could deteriorate, risking its viability.
We estimate ending the Apple-Google deal alone could cut Google’s U.S. search share by 23–32%.
Mozilla could go bankrupt, killing Gecko, one of just 3 major browser engines.
Most Chromium-based browsers rely on Google’s funding to function.
The open web supports trillions in economic value and it’s mostly free to use.
The impact will likely fall hardest on small U.S. e-commerce businesses that depend on the open web to compete.
DOJ can reduce Google’s market share below 50% without destroying browser funding.
New Chrome owner is likely to gut web platform funding to hit short-term profit targets.
If the web is dealt this critical blow, users will be pushed over to Apple’s and Google’s closed ecosystems.
In late 2020, the U.S. Department of Justice (DOJ), in conjunction with state attorneys general representing 11 states, brought a landmark antitrust case against Google for unlawfully maintaining a monopoly in the general search engine market. In August 2024, Judge Mehta ruled in favor of the DOJ, declaring unequivocally that “Google is a monopolist, and it has acted as one to maintain its monopoly”.
We believe this ruling was correct, necessary, and that the DOJ’s case is compelling.
The DOJ has proposed an extensive list of remedies aimed at restoring competitive conditions in the market for general search engines in the United States. The vast majority of the numerous remedies the DOJ has proposed seem reasonable and proportionate. But amidst this sweeping package, two key remedies in particular have the potential to cause significant, severe, and sustained collateral damage to the web platform.
They are:
A total ban on search engine revenue sharing deals between browser vendors and Google.
A forced sale of Chrome by Google (and barring Google from re-entering the browser market for 10 years).
We fully understand the rationale behind prohibiting search engine revenue-sharing agreements and support the DOJ's decision to cancel the Apple-Google search deal, which undermines iOS browser competition and, with a possibly 98.5% profit margin, channels only a minimal share of its value into web platform development. However, we are concerned about the unintended consequences this approach may have on smaller browsers, particularly Mozilla. Stripping Google of, at most, an additional 1.15%, and likely only 0.74%, of U.S. search traffic does not justify the risk of bankrupting a key contributor to the open web ecosystem.
Mozilla plays a uniquely valuable role in the internet ecosystem as a non-profit committed to an open, secure, and user-centric internet. Despite its modest market share, Mozilla has a large influence on web standards, holding equal footing with Google and Apple in governance bodies like the W3C TAG. Mozilla also maintains its own independent engine, Gecko, which ensures diversity in browser implementations. Gecko is one of only three engines left in major usage. Mozilla frequently serves as a crucial third implementor voice in standards discussions, offering a non-profit perspective grounded in the public interest. Removing Mozilla from this equation would do far more harm to the long-term health of the web than any marginal competitive benefit from eliminating its Google deal, especially when other remedies are already projected to push Google’s market share below 50% and the drop in Google’s share from this remedy is so negligible.
Even more concerning is the likely collapse in web platform investment if Google is forced to sell Chrome. Google currently funds an estimated 90% of Chromium development. Chromium is the open-source project that powers a number of browsers including Chrome, Edge, Opera, Samsung Internet, Vivaldi, Brave, and many other smaller browsers. If Google is forced to divest Chrome and can no longer fund the project, that investment may evaporate overnight. Smaller browsers do not have the resources to fill that gap. In total, this could result in an estimated 70% drop in funding for the web platform, a catastrophic blow to the ongoing evolution of the web. Progress in new web features could stagnate, and the performance and stability of the web platform will deteriorate.
This in turn would harm the ability of the web to compete with the mobile app store duopoly of Apple and Google, directly undercutting the DOJ’s case against Apple, and threatening recent progress by UK and EU regulators to improve competition between browsers and between web apps and native apps. Critical efforts to port both Chromium and Gecko to iOS could be abandoned entirely.
What makes the web unique is that it is not built to trap users in closed ecosystems. It is the world’s only truly open and interoperable platform, one that requires no contracts with OS gatekeepers, no revenue cuts to intermediaries, and no permission from dominant platform owners. Anyone can create a website or web app without needing approval from Apple, Google, or any other gatekeeper. There are no lock-in mechanisms designed to keep users tethered to a single vendor’s hardware or services. Users can switch browsers, change devices, or move between ecosystems without losing access to their data, tools, or digital lives. That level of freedom and portability simply does not exist in app store-controlled environments, where every update, transaction, and user interaction can be subject to control, censorship, or a mandatory financial cut. The web’s architecture prioritizes user agency, developer freedom, and cross-platform compatibility. In short, the web is the antidote to operating system platform monopolies.
Building an app, convincing users to install, and then to engage with it presents an incredibly high bar and massive friction. Major brands with established fans can achieve escape velocity, but the millions of SMBs trying to make their first sale? They stand no chance. They're operating on razor-thin margins, and the online store is the primary and predominant channel of choice because it is a one-tap destination for the potential buyer. It is also the only channel that gives them full creative control, one-tap open and permissionless discovery, and direct relationship with the customer. Continued success of the open web platform is essential to the success of all merchants, and existential for most SMBs. Ilya Grigorik - Distinguished Engineer at Shopify
Perhaps even more troubling, the fallout wouldn’t be limited to mobile. This could also harm the web on a platform it is already dominant: desktop. Over 70% of user time on desktop is spent in the browser, only possible thanks to the vast multi-year investment in web technologies over the last decade.
In trying to solve one monopoly problem, the DOJ could unintentionally harm the open web ecosystem, a sector worth trillions to the U.S. economy. Web technologies are also used in a vast array of native apps and power the code run on servers of the most high traffic applications in the world. From WebRTC to the V8 JavaScript engine that powers Node.js, the impact of this more than a billion-dollar annual investment in the web is staggering. No one truly knows what the impact of cutting this investment off will be. Certainly, all the code already written will not disappear, but new feature development will stall and severe bugs and security vulnerabilities are bound to become more frequent. This will reduce the stability that developers so desperately need, pushing them towards closed ecosystems.
Given the sheer scale of the web’s usage, its role underpinning the multi-trillion dollar digital economy, the rapid pace of innovation that would be disrupted, and the weak competition on alternative platforms (such as the mobile app stores), it is easy to predict that the resulting damage to US companies and consumers will be in the billions per year.
We believe the DOJ can avoid this outcome. We are optimistic that with targeted adjustments, the DOJ can achieve its goal of breaking Google’s monopoly while safeguarding the web platform's funding and the vast benefits it brings so many US consumers and businesses every year, for free. In fact, we believe that the DOJ could increase both funding and browser competition with adjustments to their existing remedies.
Given that just one of the DOJ’s remedies, canceling the Apple-Google search deal, will by our estimate reduce Google’s U.S. search market share by approximately 21.8% to 30.2%, there is a strong argument that the DOJ can succeed without resorting to remedies that risk gutting web platform funding.
We propose the following six potential targeted changes:
Since the primary justification for these remedies is to prevent actions that would inadvertently dismantle the funding that sustains the web platform, it is both logical and essential that they include concrete safeguards to ensure that goal is actually met. For this reason, we have proposed measures such as minimum reinvestment requirements for any revenue derived from Google search deals, so that these remedies not only avoid harm, but actively support the long-term health of the web platform.
Our goal is not to weaken the DOJ’s case or shield Google. The anticompetitive behavior must be addressed, but the remedies must not destroy the very ecosystem that Google itself indexes.
The DOJ’s case has the potential to unlock vast benefits, not just for search, but for the web itself. We urge both the DOJ and the court to carefully consider the ramifications of their remedies and adjust them where needed. The web platform is too important, and too valuable, to become unnecessary collateral damage in the fight to rein in Google’s search dominance.
Open Web Advocacy (OWA) is an independent non-profit dedicated to promoting fair competition in both browsers and web apps. We receive no funding from browser vendors, search engine providers, or any companies involved in this case, nor do we advocate on their behalf. Our work is focused entirely on defending the interests of consumers, developers, and the open web.
Our interest in this case is driven by concern over the potential unintended consequences of some of the DOJ’s proposed remedies, and the broader impact these measures could have on the health of the web and the millions of developers and billions of consumers who rely upon it.
The federal antitrust case United States v. Google LLC was filed by the Department of Justice (DOJ) on October 20, 2020. The DOJ alleged that Google violated the Sherman Antitrust Act by unlawfully monopolizing the search engine market.
Google has entered into a series of exclusionary agreements that collectively lock up the primary avenues through which users access search engines, and thus the internet, by requiring that Google be set as the preset default general search engine on billions of mobile devices and computers worldwide and, in many cases, prohibiting preinstallation of a competitor.
DOJ - Statement on Issuing Complaint
After having carefully considered and weighed the witness testimony and evidence, the court reaches the following conclusion: Google is a monopolist, and it has acted as one to maintain its monopoly.
Judge Mehta - Judgement
Following the ruling, on November 20, 2024, the DOJ released an initial proposed final judgment outlining potential remedies to address Google’s monopolistic practices. The document is extensive and details numerous overlapping remedies, which will be discussed in more detail later.
Apple sought to join the proceedings but was decisively rejected on the grounds that it had waited nearly four years to make the request. The court also found that Google was sufficiently positioned to represent Apple’s interests in the case. However, Apple was granted permission to submit an amicus brief, a filing by a non-party, intended to offer additional legal arguments or context for the court to consider.
A trial on these remedies started this monday, with a final ruling by Judge Mehta anticipated by August 2025.
However, legal experts predict the case will be appealed, likely delaying the implementation of any remedies further.
The core argument in the case is that Google leveraged its vast profits and dominant market position in the search engine industry to establish a series of overlapping contractual arrangements, creating significant barriers for new competitors to enter the market.
Although we are not legal experts or scholars, as technical professionals in the industry, we find the DOJ’s case compelling. In our view, the ruling was well justified. While we might disagree with some individual points raised during the proceedings, it is evident that Google’s practices have made it exceptionally challenging for competitors to gain a foothold in the search engine market. In our conversations with software engineers and academics, few questioned the fundamental validity of the DOJ’s case.
The list of remedies that the DOJ has proposed is extensive, and it is essential to at least skim through it to grasp the scope and scale of the proposed measures. Many of the remedies are profoundly impactful on their own. While some may not be adopted by the court, the DOJ appears to be advocating for the implementation of every remedy listed, not just a select few.
These have been abbreviated and rewritten for the purposes of readability and “brevity” but you can read the originals and updated remedies. In some cases remedies have been split for readability purposes. Finally you may also be interested in this justification document submitted at the same time by the DOJ.
Google is prohibited from compensating or incentivizing any third party to block entry into the General Search Engine market or the Search Text Ad market.
Google is prohibited from compensating or incentivizing any third party to give preferential treatment to Google Search or any Google Search Access Point (e.g., Google Search App, Chrome) over its competitors.
Google is prohibited from compensating or incentivizing any third party to set or maintain any General Search Engine as the default in a new or existing Search Access Point.
Google is prohibited from compensating or incentivizing any third party to discourage the use of competing General Search Engines.
Google is prohibited from compensating or incentivizing any third party for pre-installation, positioning, or setting any Search Access Point as the default.
Google is prohibited from compensating or incentivizing Apple to refrain from entering the General Search Engine or Search Text Ad markets, effectively nullifying the Google-Apple search agreement and broadly barring any future similar arrangements.
Google is not allowed to contract with publishers to licence data in any way which provides Google exclusivity or prevents the publisher from making the same data available to any other General Search Engine or AI product.
Google is not allowed to condition access to the Play Store or any other Google product on a distribution agreement for a GSE, Search Access Point, or Choice Screen. Similarly they may not condition it on not distributing a Competitor’s product or service.
Google may not bundle or tie any Google Search Engine or Search Access Point by, for example, licensing a product to a distributor and including a General Search Engine or Search Access Point for free.
Google may not pay any distributor any amount that is calculated based on the usage of or revenue generated by any Google Search Engine. This is essentially a ban on all revenue sharing agreements that Google currently has.
Google must (within 6 months) sell any investment it has in any company that controls a Search Access Point, an AI Product or similar technologies that are potential entrants into the General Search Engine or Search Text Ads market or could be reasonably anticipated competitive threats to General Search Engines. Google must immediately refrain from taking any action that could discourage or disincentivize from developing products that would compete with or disrupt Google's General Search Engine or Search Text Ads.
Google must not without prior written consent of the United States acquire any interest in, invest in, partner with, expand the scope of an existing joint venture of any company that that competes with Google in the GSE or Search Text Ads markets or any company that controls a Search Access Point or query-based AI Product.
Google must promptly and fully divest Chrome, to a buyer approved by the Plaintiffs in their sole discretion subject to terms that the Court and Plaintiffs approve.
Google may not release any other Google Browser during the term of this Final Judgment (the next 10 years) absent approval by the Court.
Google must not use any Google-owned asset (including any software, website, device, service, dataset, algorithm, or app) to self-preference Google’s GSE, Search Text Ads, or AI Products. The section provides a long list of examples.
Google must not use any Google-owned asset (including any software, website, device, service, dataset, algorithm, or app) to self-preference Google’s GSE, Search Text Ads, or AI Products. The section provides a long list of examples.
Google must not use any Google-owned asset (including any software, website, device, service, dataset, algorithm, or app) to undermine or lessen the ability of a user to discover a rival GSE or of an advertiser to discover or shift its Search Text Ad spending to a rival Search Text Ads provider. The section provides a long list of examples.
Google must not use any Google-owned asset (including any software, website, device, service, dataset, algorithm, or app) to undermine or lessen the ability of a user to discover a rival GSE or of an advertiser to discover or shift its Search Text Ad spending to a rival Search Text Ads provider. The section provides a long list of examples.
If the remedies fail to restore competition or if Google circumvents them, the Court may order additional measures, including divesting Android (and the Google Play Store). If the DOJ proves insufficient competition persists, Google must divest Android (and the Google Play Store) unless it proves that its ownership did not substantially hinder competition.
Google must provide its Search Index to Qualified Competitors at marginal cost, ensuring equal access for both Qualified Competitors and Google.
Google must include content from all its owned or operated platforms (e.g., YouTube) in the Search Index it shares.
Google must ensure the shared Search Index has the same latency and reliability as Google's own access.
Google cannot use or retain data that cannot be shared with Qualified Competitors due to privacy or security concerns.
Google must provide publishers, websites, and content creators a simple way to selectively opt-out of having the content of their web pages or domains used in search indexing, AI training, AI tools, or AI-generated content on Search Engine Result Pages. This opt-out applies to Google and all Search Index users, must be user-specific, and includes Google-owned platforms like YouTube, with no retaliation allowed.
Google must provide Qualified Competitors with free, non-discriminatory access to User-side Data while protecting privacy and security. Google has six months to implement the necessary technology, and competitors can choose real-time or daily access via API, data firehose, or other suitable mechanisms Google uses in its own search engine.
Google must allow Qualified Competitors to submit synthetic queries for free. Competitors may log and use the results, including ads and Search Engine Page Result content. The maximum number of allowable synthetic queries will be determined by the Plaintiffs in consultation with the Technical Committee.
Google must provide Qualified Competitors with free, non-discriminatory access to Ads Data while protecting privacy and security. Google has six months to implement the necessary technology, and competitors can choose real-time or daily access via API, data firehose, or other suitable mechanisms Google uses in its own search engine.
Google must offer Qualified Competitors a 10-year syndication license at marginal cost, providing all non-advertising components of its General Search Engine (organic results, Search Features, Ranking Signals, and query understanding) to enable licensees to display Search Engine Page Result, understand ranking logic, and query modifications. The license must be non-discriminatory, unrestricted in use or display, and interoperable with Search Access Points and AI products, while allowing Google to protect its brand, reputation, and security. This only requires Google to provide syndication for queries that originate in the United States. The licence will have the following required features:
a) Google must deliver syndicated content via an API with latency and reliability equivalent to its own Search Engine Result Page.
b) Syndication access will start broadly and decline over 10 years, encouraging licensees to build independent search capabilities, with scope set by Plaintiffs and the Technical Committee.
c) Google may not consent to licensees exceeding syndication limits set by Plaintiffs, and licensees must submit to the Technical Committee audits of syndication frequency.
Google must provide Qualified Competitors a 1-year non-discriminatory license for all components of its Search Text Ads, including any assets, extensions, or similar Search Text Ad variations that appear on Google’s Search Engine Result Page or available through Google’s AdSense for Search. Google must share all related Ads Data without restricting use, display, or interoperability with Search Access Points or AI products, while allowing reasonable protections for its brand, reputation, and security. This only requires Google to provide syndication for queries that originate in the United States. Additionally:
a) Google must provide syndicated content via an API with latency and reliability equivalent to its own Search Text Ads on Search Engine Result Pages.
b) Licensees may request syndicated ads for up to 25% of U.S.-originating queries, with no exceptions allowed. Licensees must also submit syndication frequency audits to the Technical Committee.
For existing Google syndication agreements or new contracts with third parties outside Qualified Competitors Google must:
a) Google must allow Qualified Competitor to terminate its existing agreement in favor of the new rules.
b) Google must follow the new rules either within two years of the Effective Date or when any current syndication contract ends, whichever comes first.
For any current or future agreements where Google licenses or syndicates search or search ads products to a competitor, Google cannot:
a) Restrict how competitors use, display, or integrate these products with Search Access Points or AI tools, but Google can take reasonable steps to protect its brand, reputation, and security. Competitors can decide which queries or syndication components to use or display however they want.
b) Keep or use data from syndicated queries or information from competitors for its own products or services.
Google must provide advertisers with detailed data for each Search Text Ad served or clicked from the preceding 18 months. This includes the query, keyword trigger, match type, CPC, SERP position, LTV, and other metrics to evaluate ad performance. Data must be accessible via an API for real-time downloads, reporting, and analysis, as well as through auto-generated monthly summaries in the Google Ads interface.
Google must provide advertisers with a keyword matching option that ensures ads enter the auction only when a query exactly matches the chosen keyword, with no variations. This option must also apply to negative keywords.
Google must allow advertisers to export all their ad and campaign data, including placement and performance metrics, in real time through an interface or API.
Each month, Google must report to the Technical Committee and DOJ all changes to its Search Text Ads auction, include public disclosures or explain why none were made, and identify any material changes.
Google must not pay Distributors for default settings, placement, or preinstallation of a General Search Engine or Search Access Point on non-Apple, third-party devices. Google cannot interfere with the ability of devices or preinstalled Search Access Points to default to or work with non-Google General Search Engine or competitors. For preinstalled Google Search Access Points under prior agreements, Google must offer Distributors the option to display a Choice Screen to users which currently have Google as the default General Search Engine. Google must pay a fixed monthly amount for each such device, based on the average payments made in the past year for the device lifetime or one year, whichever is shorter. Chrome is considered a Google Search Access Point until divested.
Google must not pay any Distributor for any form of default, placement, or preinstallation distribution (including choice screens) related to making any General Search Engine a default within a new or existing Search Access Point.
Google must not preinstall any Search Access Point on any new Google Device.
Google must not hinder the ability of third-party Search Access Point to be set as default or interoperate with non-Google Search Engines or other competitive entrants.
For existing Search Access Point preinstalled on an existing Google Device before the date of entry of this Final Judgment, Google must implement a Choice Screen.
Google must display a Choice Screen on all Google Browsers where the user hasn't affirmatively set a default General Search Engine, including via settings.
Google must disclose each Choice Screens, related distribution agreements, and implementation plans to Plaintiffs and the Technical Committee at least 60 days before user display. The Choice Screen must offer a clear, unbiased selection between competitors, be accessible, user-friendly, and minimize choice friction based on user behavior data. After consulting a behavioral scientist, the Technical Committee will assess compliance and report to Plaintiffs, who must approve any Choice Screen under this Final Judgment.
A five-member Technical Committee (TC) will be appointed to monitor Google’s compliance with the Final Judgment, ensuring fairness and preventing anti-competitive behavior. TC members must be experts, free from conflicts of interest, and will have access to Google's systems, source code, documents, facilities, and personnel to enforce compliance. The TC will report regularly to Plaintiffs, handle complaints, recommend modifications, and operate with Google-funded resources under strict confidentiality agreements. This section of the proposed final judgement is quite extensive on the powers of the technical committee.
Google will appoint a compliance officer who among other duties will distribute a copy of the final judgement to ALL google employees and have them annually certify that they have read, will abide by its terms and understand that failure to do so may result in a finding of contempt of court. This includes appropriate training for all Google employees on how to comply with this judgement.
Google must not retaliate against anyone for competing with its GSE or Search Ads, filing complaints, participating in legal proceedings, or exercising rights under this Final Judgment.
Google is prohibited from enforcing or entering contracts that violate this Final Judgment. It must not replicate banned anti-competitive behavior, evade obligations, or undermine the Judgment’s purpose. If found liable for antitrust violations in federal court, structural relief may be automatically ordered. These provisions apply globally to all Google conduct and contracts.
If after 5 years, Google has complied with all provisions and its competitors combined market share is greater than 50% in the US General Search Engine market then Google may petition the court to terminate this judgement.
# 6.1. Proposed Remedies and Their Potential Unintended Consequences
Out of the above quite substantial list, two remedies stand out above all others in terms of their impact on the web:
A total ban on deals with Google that set search engine defaults or that share revenue with search engine entry points.
Forcing Google to sell Chrome and banning Google from re-entering the browser market for 10 years.
While we fully understand the intent behind these remedies, we are concerned that the DOJ has not fully considered or appreciated the profound ramifications these remedies will have on the adjacent browser and web software market including:
Bankrupting or shrinking the share of smaller browsers.
Consolidating power in the browser market in even fewer hands.
Plummeting investment in the Web, thus strengthening the non-interoperable app store model on mobile.
# 7. The Problem with Canceling Deals with Small Browsers
Google has agreements with several browser vendors to set Google as the default search engine for users who have not previously made a manual choice. In return, Google shares a portion of the revenue it earns from searches performed through those browsers.
Google also maintains revenue-sharing agreements with several smaller browser vendors, including Mozilla. These browsers rely heavily on this funding to sustain operations. Google is estimated to pay Mozilla approximately $410-420 million per year, though public figures for its deals with other vendors are not available. While these browsers collectively represent only a small share of the market, they play a disproportionately important role in maintaining competition within the browser ecosystem. However, according to the court judgment, they account for just 1.15% of search queries in the United States.
Expanding the presence of smaller browsers is vital. A greater number of competitors leads to stronger and fiercer competition, pushing larger players to innovate and improve. It is essential that any remedies to the current market dynamics do not further reduce the number of players in the browser ecosystem.
Smaller browsers are our best hope for cultivating a more competitive market in the future. Ideally, in 5 to 10 years, a more balanced search engine landscape would lead to increased competition for placement deals, driving higher revenues for smaller browsers. This additional funding could help them grow and gain market share.
In the short term, however, blocking these funding arrangements could jeopardize the financial stability of smaller browser vendors. While they might seek deals with Bing or other search engines, those arrangements would likely yield lower payments, as Bing would only need to outbid smaller rivals and not Google, further reducing the resources available to these browsers.
Mozilla, in particular, is at significant risk due to the high costs associated with maintaining and advancing its Gecko browser engine. Losing Mozilla would be a major blow to competition, as it represents a unique alternative in the market. In contrast, larger browsers like Microsoft Edge and Apple Safari are likely to survive, supported by their parent companies’ vast resources and strategic interests. However, a market reduced to three dominant players, including Safari which operates solely on Apple’s platforms, would critically undermine competition.
We believe that blocking smaller players from making search deals with Google is unjustified given the broader harm this would cause to the browser market. The potential benefits in the search engine market are minimal compared to the significant blow to browser competition. Ensuring the survival and growth of smaller browsers is key to a healthier, more competitive ecosystem.
Any remedy that would significantly impact the finances of the smaller browsers should be backed by detailed arguments as to why it will not cause the exit of these smaller players and consolidation in the hands of a few tech giants.
During the case, evidence showed that Mozilla reinvested much of the revenue from its Google search deal into Firefox and Gecko. However, its 3% market share was deemed too small to be relevant to significantly benefit the public.
This reasoning is flawed. If Mozilla’s market share is considered negligible, then their share of Google’s search payments, only 1.6% of what Google pays browsers and OEMs, should also be seen as insignificant in the broader context. It is inconsistent to argue that one metric matters while dismissing the other.
That is, the questions that should be asked are:
Do payments to Mozilla and other smaller browsers cause more harm by limiting opportunities for other search engines to enter the market, or do they provide greater benefits by enabling Mozilla’s critical contributions to web standards, browser development, and the maintenance of Gecko, one of the three remaining browser engines?
Given Mozilla’s 3% market share, doesn't its role in hindering other search engines pale in comparison to Google’s other strategies, such as the Apple Search deal, Android OEM placements, revenue-sharing agreements, and defaults in Google’s own browser?
We firmly believe the answer lies in allowing Mozilla and other smaller browsers that rely on Google’s search deals to continue to make them. The DOJ can address Google’s monopoly without crippling or mortally wounding Mozilla, an already struggling but vital player, or undermining the broader ecosystem of smaller browsers.
The DOJ has proposed that Google be required to sell Chrome and banned from re-entering the browser market for 10 years, which raises several important concerns.
A key question is: Who would buy Chrome, and once purchased, what would its revenue source be?
The proposed remedies prohibit any search deal with Google, including partial agreements, leaving its financial viability uncertain. While this new entity would be free to make deals with other search engines such as Bing, would this be enough to cover costs, and would these search engine providers feel pressure to bid sufficiently large sums?
We are particularly worried about the possibility of Chrome being acquired by an entity that does not value the open web, or worse, is actively opposed to it.
Another concern is whether a new owner would continue funneling the necessary investment, which we estimate at around $1 billion annually, into maintaining and advancing the platform. The web platform relies on a vast body of work that extends far beyond the code in any single browser engine. It includes infrastructure maintenance, security research, standards development, and the efforts of web advocates: individuals and organizations committed to improving the web as a whole. Today, the overwhelming majority of this work is funded either directly or indirectly by Google.
Assuming they find a buyer, that buyer will be scrambling to find a way to make that investment worth it. Will they be choosing to employ people who are just abstractly making the web better? I would think not.
Chris Coyer - CSS Tricks
Google itself would have drastically reduced incentive to invest in Chromium, as it would no longer benefit directly from maintaining a browser. Moreover, the risk of another tech giant acquiring Chrome could create a similar antitrust issue down the road. For example, if Microsoft were to regain a dominant share of browsers on Windows, it could mirror the competitive concerns of its antitrust case from 20 years ago. While we support Edge as a minority browser, we remain critical of certain anti-competitive practices Microsoft is currently employing on Windows to increase its browser market share.
A potential disaster scenario emerges if Chrome is acquired by a buyer focused on short-term returns. After investing a substantial amount to acquire the browser, the new owner would face strong incentives to prioritize rapid monetization over long-term investment in the web platform.
Corporate acquirers targeting high-risk, high-reward purchases typically aim for annual returns exceeding 15–20%. With a $20 billion purchase price under discussion, the buyer would be under significant pressure to generate $3–4 billion in annual profit to justify the investment. In that context, it would be entirely rational for them to focus solely on revenue-driving components.
This makes it likely that any investment in a newly acquired browser would be concentrated on user-facing features that grow or maintain market share. Improvements to the underlying web platform, which would benefit all Chromium-based browsers including direct competitors, would likely be deprioritized.
If the acquirer were unable to secure a lucrative search deal with Google (due to a prohibition from the court), the next logical option would be Microsoft’s Bing. However, in a world where Google is not bidding, it's unclear how much Microsoft would be willing, or feel compelled, to pay. Without competitive tension in the bidding process, any resulting deal would likely be far less valuable.
This scenario could leave the acquirer with substantial engineering overhead and no clear path to recover those costs, let alone achieve the level of profitability their investment demands. The financial strain would be even greater if the acquisition were debt-financed, amplifying the risk of falling short.
This could result in drastic cost-cutting measures, including reducing staff to a bare minimum, terminating teams working on new web platform features, and maintaining only a skeleton crew for basic bug fixes and security updates. The new owners could also focus on extracting maximum revenue from search engine providers and other deals while neglecting long-term improvements to Chrome.
Investment in Chromium, both from this new entity and Google, would likely dry up overnight. The resulting stagnation in web development could have lasting repercussions for decades, as the Web falls behind closed, extractive native app ecosystems.
Does it matter if the web platform adds new capabilities? And if it should, which ones? The web is a meta-platform. Like other meta-platforms the web thrives or declines to the extent it can accomplish the lion's share of the things we expect most computers to do.
[...]
There's no technical reason why, with continued investment, meta-platforms can't integrate new features. As the set expands, use cases that were previously the exclusive purview of native (single-OS) apps can transition to the meta-platform, gaining whatever benefits come with its model. Alex Russell - Program Manager on Microsoft Edge
This would cause immense harm to countless smaller U.S. businesses that depend on a thriving and continuously evolving Web. Ultimately, it would shift power away from the Web, and into the hands of tech giants controlling the alternative.
Most industry experts we have consulted agree that this is, by far, the most likely outcome. There is widespread fear across the industry, particularly among those who rely on the Web, that such a scenario would have devastating and far-reaching consequences for its future.
Browsers are highly sophisticated pieces of software, tasked with far more than simply rendering web pages. They interpret and execute HTML, CSS, and JavaScript; manage memory and isolate processes for stability; enforce critical security mechanisms like sandboxing and same-origin policies; protect users from malicious content; support audio and video playback; handle networking and caching; integrate with various operating system services; synchronize data such as bookmarks and passwords; and offer robust tools for developers, along with numerous other complex functions. Few, if any, engineers fully understand all the functions a modern browser performs.
Conceptually, browsers can be divided into two main components:
The Browser User Interface
This includes all the visible elements users interact with, such as tabs, address bars, bookmarks, and menus. It also manages user actions like navigating between pages or downloading files. Notably, this excludes the main content area where the web page is rendered, which is the responsibility of the browser engine.
The Browser Engine
Often considered the "heart" of the browser, the engine is responsible for rendering web pages, running JavaScript, interpreting HTML/CSS, and managing web APIs. It powers the browser platform, which serves as the foundation for web developers and businesses relying on the web as an application platform.
The term "browser platform" refers to the collection of tools, APIs, and capabilities that enable developers to create websites and web apps. It provides essential features like rendering, storage, communication, and graphics capabilities. While the boundaries of the browser platform can sometimes blur with the broader browser architecture, the bulk of it typically resides within the browser engine.
Industry conversations suggest a consistent view among engineers: building a browser involves roughly a 50-50 split (with about a 10% margin) between developing the browser UI and the underlying browser platform. This balance is generally seen among browsers that are the primary maintainers of their own engines, such as Chrome, Firefox, and Safari. However, other browsers, including well-funded ones like Edge, are believed to overwhelmingly focus their efforts on the browser UI, often allocating over 90% of their resources to it, contributing significantly less to the platform layer. While both components are crucial to delivering a seamless experience for users, the browser platform holds particular importance for businesses and developers. It provides the tools they need to create innovative web applications, deliver services, and support their operations.
The significance of the browser platform cannot be overstated, as it forms the backbone of the modern web. Businesses depend on its reliability, security, and functionality to ensure their web applications perform efficiently across all devices and operating systems. Developers rely on its APIs and tools to push the boundaries of what is possible on the web.
The key factors driving the advancement of the web platform are fierce competition among browsers, the substantial funding necessary to maintain and push forward the platform, and a steadfast belief that given the web's unique attributes of openness and interoperability, the web can and should be allowed to compete fairly.
Gecko traces its origins to the defunct Netscape Navigator browser. Mozilla began developing Gecko in 1998 after Netscape open-sourced its code. This effort culminated in the release of Firefox 1.0 in 2004, marking the beginning of renewed competition against the then-dominant Internet Explorer from Microsoft.
WebKit originated as a fork of the KHTML browser engine. As a fork WebKit inherited KHTML's LGPL copyleft license and powers Safari and several smaller browsers. Between the mid-2000s and early 2010s, both Google and Apple contributed code and resources to WebKit. However, disagreements over Apple’s management of the project led Google to hard-fork WebKit in 2013, creating its own engine, Blink.
A soft fork refers to maintaining a customized version of a browser engine while continuing to accept upstream patches and improvements from the core project. In contrast, a hard fork involves taking full control of a new codebase, starting from a snapshot copy of the original, and developing it independently.
Blink powers Chrome, Edge, Opera, Samsung Internet, Vivaldi, Brave, and many other smaller browsers. Its popularity stems in part from the open-source project Chromium, which includes not only the Blink engine but also the full surrounding browser UI. This makes it easy for new browser vendors to create a soft-fork of Chromium, whereas with WebKit or Gecko, they would need to develop the entire browser UI themselves.
Chrome is Google's browser, built on the open-source Blink engine and the Chromium project, both of which Google primarily develops and maintains. Chrome holds a dominant market share, with approximately 86% on Android, 67% on Windows and 55% on macOS. Google also maintains a Chrome-branded WebKit browser on iOS with a 15.6% share.
Google’s motivations for maintaining and investing in Chrome are wide-ranging and deeply tied to its core business interests.
First, Chrome acts as a vital gateway to Google Search. With Google set as the default search engine for all Chrome users, the browser drives substantial search traffic, translating directly into revenue.
Second, as the operator of major web-based services like Gmail, YouTube, and Google Docs, Google has a strong incentive to ensure the underlying web platform remains fast, stable, and feature-rich, allowing these products to deliver a seamless user experience.
Third, Google’s search business depends on access to the open web. By heavily investing in both Chrome and the web platform, Google increases the share of the world’s data that is publicly indexable, enhancing the reach and relevance of its search engine.
Finally, Chrome plays a strategic role in supporting Google’s advertising ecosystem. Search ads, especially in e-commerce, are typically priced on a per-conversion basis. Improving web performance and capabilities leads to higher conversion rates across the web, making Google’s ads more effective and more valuable to advertisers.
Safari is Apple's browser, powered by the open-source WebKit engine, which Apple primarily develops and maintains. On iOS Safari has an 82.2% share, and holds approximately 37.8% of the browser market on macOS. While WebKit is open-source, Apple has unilateral control over the version and feature set of the WebKit that is shipped with and is available on iOS.
Safari plays a key role in Apple's branding, positioning itself as a privacy-focused alternative to Chrome.
One significant limitation of Safari as a competitor to Chrome is Apple's decision to restrict Safari's availability to its own platforms, including macOS, iOS, iPadOS, VisionOS, and WatchOS. This exclusivity prevents Safari from being a meaningful competitor in broader browser markets like Windows, Android, and Linux.
Apple has also effectively banned all rival browsers from competing on iOS via their browser engine ban. This lack of competition has diminished Apple's incentive to significantly enhance Safari on iOS beyond what is necessary to maintain its reputation among users. Developers, reliant on supporting iOS, and therefore Safari, often have to find workarounds for various issues.
Apple has a browser monopoly on iOS, which is something Microsoft was never able to achieve with IE Scott Gilbertson - The Register
because WebKit has literally zero competition on iOS, because Apple doesn’t allow competition, the incentive to make Safari better is much lighter than it could (should) be.
Chris Coyier - CSS Tricks
What Gruber conveniently failed to mention is that Apple’s banning of third-party browser engines on iOS is repressing innovation in web apps.
Richard MacManus - NewsStack
Firefox is Mozilla’s browser and is powered by the Gecko engine. While it played a pivotal role in revitalizing competition against Internet Explorer in the mid-2000s, Firefox’s market share has dwindled to single digits in recent years. Mozilla relies primarily on its search engine deal with Google to fund the ongoing development of Firefox and its independent browser engine, Gecko.
Despite its declining market share, Mozilla and Firefox play an outsized and vital role in the development of the web and web standards. However, this role is hindered by insufficient funding. Unlike smaller browsers that can rely on Chromium to reduce costs, Mozilla shoulders the full burden of maintaining an independent browser engine. This independence is vital for web diversity but comes at a steep financial cost.
While Mozilla has undoubtedly made missteps, there is a compelling argument that they have been unfairly prevented from competing on equal terms. On iOS, Apple’s ban on third-party browser engines has effectively barred Firefox from fully competing. Similarly, on Android, Mozilla has faced challenges due to overlapping and restrictive placement deals that favor Chrome. Over the past 15 years, these barriers have likely cost Mozilla billions in search engine revenue. This lost funding could have provided Mozilla with a significantly larger budget to compete head to head on platform via Gecko with Chrome. It would also have given Mozilla more room to make and recover from errors.
Microsoft Edge is built on the Blink engine, utilizing the open-source Chromium project. In 2018, Microsoft transitioned Edge from its proprietary EdgeHTML engine to Chromium/Blink. While Edge is the default browser on Windows, it faces significant competition from Chrome, which remains the dominant browser on the platform.
Microsoft is heavily invested in the transition to a more web-centric future. Many of its key applications, such as Teams, Outlook and Visual Studio Code (VSCode), are built using web technologies (e.g., Electron), effectively making them web apps running in native wrappers powered by Chromium.
Smaller browsers include Samsung Internet, Opera, Vivaldi, Brave, Tor, and many others. Most of these browsers are built as forks of Chromium and rely on the Blink engine. Some, but not all, of these browsers have search deals with either Google or Bing.
These browsers have the ability to add, remove, or modify features in the Blink or Chromium codebase allowing them some significant ability to compete. Despite their small size, it is critical that these browsers be given the opportunity to grow and even now despite their small share they apply competitive pressure on Chrome to meet consumer and developer expectations or be replaced.
However, their ability to steer Blink and Chromium's future relies on these browsers' willingness and ability to invest in the platform’s maintenance and development. Implementing and refining web standards is a costly and complex process, requiring substantial resources. Unfortunately, many smaller browsers have not reinvested enough into Chromium, even proportional to their market share. This leaves the vast majority of the financial and developmental burden for maintaining and advancing Chromium on Google.
For smaller vendors, it is often more difficult to justify investing in the shared platform, work that also benefits their competitors, rather than focusing on features unique to their own browser. By contrast, for companies with larger market share, investing in the underlying web platform is more easily justified. Enhancing the platform increases the overall value of the web, which in turn raises revenue across all browsers. This return on platform investment becomes more favorable the larger the browser share.
However, for the health of the web, it would be far better if the governance and funding of Chromium were more evenly distributed among participants and interested parties.
Each of these organisations contain a part of the “web standards community”, but feature differing processes, publication gates, and formal mechanisms for including designs into official standards documents. Critically, all of these SDOs create voluntary standards. Companies contribute their intellectual property to the commons of voluntary web standards for complex reasons, but competition has historically driven this process.
In a healthy environment, Web Standards evolve quickly, spurred on by competing browser makers working with developers to solve important problems. This involves collaboration in standards bodies to improve compatibility, however if each vendor had to wait until there was consensus among every vendor regarding every design, it would be possible for a vendor (e.g. Apple) to game these processes. There is also significant risk that well-funded third-parties could infiltrate standards organisations in order to block/stall development or functionality in a manner that is not in the best interests of the user or of competition.
Browser vendors enjoy outsized influence in development of web standards, and providing them with a veto over all progress will only serve to reward the slowest mover by preventing competitors from taking market share. In the existing structure, it is enough for a vendor to withhold engagement and prevent functionality from being standardised. This could lead to a bad situation if there were any rules preventing engines from pushing ahead and using competition to push poor performance with market outcomes.
Typically, cutting edge features are deployed by browser makers in their own engines first, then, using real world feedback over several years, eventual standards are created.
No feature starts out as a web standard:
Web Standards are voluntary. The force that most powerfully compels their adoption is competition, rather than regulation. This is an inherent property of modern browsers. Vendors participate in standards processes not because they need anyone else to tell them what to do, and not because they are somehow subject to the dictates of standards bodies, but rather to learn from developers and find agreement with competitors in a problem space where compatibility returns outsized gains Alex Russell - Program Manager on Microsoft Edge
No one can predict what web technologies will be important in the future, and disagreements between browser makers on the exact path forward are reasonable and expected. It is very difficult, if not impossible for regulators to predict which standards will be the most important and what their exact definition will end up being. It is a subtle and complex topic, and one that would require significant staffing, over a wide swath of technical areas, for any regulator to credibly participate in.
The existing patchwork of standards groups, along with the social and legal background of voluntary standards, makes recent proposals to bar browsers from implementing features ahead of formal standardisation deeply problematic.
Our analysis of the situation regarding browsers suggests that users and developers do not suffer from too much divergence of views about how to solve leading-edge problems, but rather a lack of engagement and investment in addressing those challenges. We believe this lack of investment stems from reduced competition that browser makers experience on iOS, and to a lesser extent, Android.
The suggestion that individual browser vendors or groups of browser vendors should be able to block all other browsers from producing functionality (that these browsers have no intention of implementing) would further stifle competition.
Requiring consensus before implementation would block the ability of users to signal their discontent by switching browsers to ones that offer the functionality they need. It would also remove any pressure browser vendors might feel to implement popular features if they can block all competitors from providing it. Subtly, it would also reduce the quality of features delivered, because it is only through market-oriented mechanisms like Origin Trials that leading engine teams ensure their designs are fit for purpose.
Apple has held back the Web on iOS (and mobile in general, thanks to network effects) for more than a decade via their veto on features for all browsers on iOS. Handing Apple explicit power to veto features for all browsers would be a disaster. One of the key aims is to break Apple's ability to prevent iOS users from accessing useful web functionality that competes with either their own apps or their App Store.
Browsers (and their engines) need to be free to lead and experiment on the competitive frontier. They need the freedom to be wrong but also to win users through unique features and leading edge capabilities. It is competition, developers and user choice that determines which features will be successful.
Standardization between similar features in browsers is desirable, but it is an outcome that comes at the end of the development and competitive process. It should not be placed as a gate at the beginning. Further, the potential for blocking browsers’ ability to differentiate themselves and compete would be catastrophic to competition.
Our primary concern is not that Apple will have a different vision for how particular features will function, but rather that Apple has already sought to delay features that allow the web to compete with its own, proprietary, Native Apps platform. By trying to ensure that competing features are not available, Apple removes pricing pressure on its native app ecosystem and extends power over developers.
It is important that the excellent work of the W3C and other standards organisations not be weaponized to block innovation and competition, a better approach is regulating to enable effective competition on the gatekeepers operating systems both between rival browsers and between Web Apps and Native Apps. Then allow market forces to push forward the changes (new web features) most beneficial to end users.
Both developers and users gain significant advantages from interoperable implementations of browser functionality. However, it is essential that any interventions ensure that the competitive aspects of browsers are protected including the pressure to significantly invest in new and cutting edge technologies.
Standards should be used to:
Increase interoperability between Browsers.
To allow multiple browser vendors from different companies an ability to be meaningfully involved and provide constructive feedback including but not limited to privacy and security concerns.
Provide implementation documentation for Browser Vendors.
Standards should not be used to:
Reduce or block the level of investment OR remove pressure on vendors to invest.
Reduce or block implementation of cutting edge functionality.
Designate functionality as being exclusive to native (proprietary) apps.
Enable third-parties to undermine features or functionality required by developers or users (i.e. Telecommunication or Advertising Companies attempting to undermine privacy rules).
Native app ecosystems are deeply flawed because they place unilateral control in the hands of tech giants, allowing them to dictate the rules, demand exorbitant fees, and centralize decision-making over what can and cannot be shipped. These companies, like Apple and Google, charge developers a 30% cut of revenue from all third-party apps, not because of added value but simply because they control the only avenues for app distribution. Beyond this financial toll, native apps are non-interoperable between operating systems, requiring developers to write and maintain separate versions for each platform. This dramatically increases costs and creates a form of lock-in, as developers invest heavily in specific ecosystems, making it even harder for them to leave or compete independently.
The lack of competition in mobile ecosystems is, at its heart, a structural issue. These companies wield vast power due to the security models on which mobile devices are built. Traditionally, operating systems such as Windows, macOS, and Linux have allowed users to install any application they want, with minimal interference from gatekeepers. Users could grant programs the permissions they needed, offering flexibility and control.
Locking down what applications can do, such as restricting which APIs they can access behind user permissions, is not by itself anti-competitive and can bring legitimate security advantages. However, the manner in which it has been implemented on mobile devices is both self-serving and significantly damages competition.
What is needed is a way to securely run interoperable and capable software across all operating systems. Luckily, such a solution already exists and is not only thriving on open desktop platforms but is dominating, and that dominance is growing every year. The solution is of course, the Web and more specifically Web Apps.
Today, more than 70% of users' time on desktop is done using web technologies, and that looks set to only grow.
These applications thrive on open desktop platforms, and their dominance is growing every year. Web apps run securely within the browser’s sandbox, recognized by even Apple as “orders of magnitude more stringent than the sandbox for native iOS apps”. They are interoperable, requiring no platform-specific adaptations, and do not require developers to sign contracts with operating system gatekeepers. They are capable of incredible things and 90% of the apps on your phone could be written as web apps today.
The web continues to thrive on desktop platforms, where openness and competition enable it to flourish. So why is it struggling on mobile, where just 8% of users’ time is spent in a browser, as noted in the UK’s recent Browsers and Cloud Gaming Provisional Decision?
The simple answer to this question is lack of browser competition on iOS, and active hostility by Apple towards effective Web App support, both by their own mobile browser and by their mobile OS. Apple's own browser faces no competition on iOS, as they have effectively barred the other browsers from competing by prohibiting them from using or modifying their engines, the core part of what allows browser vendors to differentiate in stability, features, security and privacy.
This is referenced in the DOJ vs Apple case where they state:
Developers cannot avoid Apple’s control of app distribution and app creation by making web apps—apps created using standard programming languages for web-based content and available over the internet—as an alternative to native apps. Many iPhone users do not look for or know how to find web apps, causing web apps to constitute only a small fraction of app usage. Apple recognizes that web apps are not a good alternative to native apps for developers. As one Apple executive acknowledged, “[d]evelopers can’t make much money on the web.” Regardless, Apple can still control the functionality of web apps because Apple requires all web browsers on the iPhone to use WebKit, Apple’s browser engine—the key software components that third-party browsers use to display web content.
DOJ vs Apple
The DOJ highlighted several ways Apple has suppressed web apps from being a viable replacement to their app store, including bans on third-party browser engines and poor visibility for web apps on iOS. By mandating WebKit for all browsers, Apple ensures it retains unilateral control, blocking competition from engines like Blink and Gecko. This has stifled innovation and entrenched Apple’s dominance.
Fortunately, change is beginning in jurisdictions like the EU, UK, and Japan, where regulators are pushing Apple to relax its restrictions. Mozilla and Google are already working on porting their engines to iOS, and although Apple has erected significant barriers, regulatory pressure is forcing progress. If this trend continues, the web could finally become a competitive alternative to native ecosystems on mobile platforms.
However, this progress is at risk of being undermined by the DOJ's case against Google.
The current funding model for browsers relies heavily on revenue from default search engine deals and this is what incentivises fighting to gain users. While we understand the DOJ's noble intent in canceling such deals, we believe that they have failed to appreciate the depth of the collateral damage that will be done by removing this funding with no viable replacement.
It won’t happen overnight, but stagnation will set in. A stagnated web is incentive for the operating system makers of the world to invest in pulling developers toward those proprietary systems. The browser wars sucked but at least we were still making websites. Being forced to make proprietary apps to reach people is an expensive prospect for the rest of us companies of the world, it will probably be done poorly, and we’ll all suffer for it.
Chris Coyer - CSS Tricks (emphasis added)
This will likely scuttle plans to port both Gecko and Blink to iOS in the EU and eventually in other jurisdictions as Apple is forced to allow competition. Mozilla is going to have a severe hit to their finances, Google will be forced to sell Chrome, and the new owners will be blocked entirely from making a search deal with Google. If the new owners of Chrome are not investing to port it to iOS, a non-trivial investment, this will make it incredibly expensive to port any of the other Chromium browsers, such as Edge, Opera, Vivaldi and Brave.
This will also greatly reduce Apple’s incentive to sustain the recent increase in investment in Safari, which is likely driven by the threat of actual competition in EU, UK, Japan and potential other territories such as Australia.
Any remedy to the current antitrust cases must consider the broader battle between closed ecosystems and the open, interoperable web. History has shown that antitrust actions can inadvertently dismantle one monopoly only to empower another. This outcome is avoidable, but only with careful consideration of the risks to adjacent but interlocked ecosystems.
Chromium is an open-source web browser project that powers Google Chrome, Microsoft Edge, Vivaldi, Brave, and others. Unlike Blink which is a browser engine, Chromium is a full browser making it relatively easy for third-parties to soft-fork and make their own browsers without having to build the full browser shell themselves.
As we discuss below, a vast number of discrete and interconnected technologies are funded under Chromium, some of these technologies are used not only in native apps but are also used in other browsers with their own engines such as Safari and Firefox.
This raises two perspectives: either Google wields too much influence over web standards, or many companies benefiting from Chromium are failing to contribute their fair share.
Ideally a healthier web would have the investment shared between a greater number of stakeholders, with Google providing sub 50% of the funding in the project. However, the core issue is that many companies have chosen not to fund Chromium adequately, despite the resources they have and the value they gain from Chromium.
The solution is not to cripple Chromium by destroying its primary funding source but to encourage broader investment, ensuring contributors support the project in proportion to their means while having a voice in its governance.
Google, by virtue of having Chrome, invests heavily in the web itself. Not just Chrome-the-browser, but the web standards that power the web. I can’t claim to know every detail of that investment, but I personally know people employed by Google that literally just try to make the web better all day.
And there are evangelists, and documentation writers, and other people who aren’t working directly on Chrome, but really the web itself.
Will Google continue to invest like this if they are forced to sell Chrome? It would be hard to blame them if they did not. Chris Coyer - CSS Tricks
The sheer scope of technologies developed and maintained under the Chromium umbrella is staggering, covering everything from core web rendering and JavaScript execution to advanced networking protocols, security frameworks, media codecs, and developer tools.
This list alone, already expansive, is likely missing additional crucial components that power modern web experiences. Without these technologies, much of the web (and indeed many native apps) simply wouldn’t function at the level users expect today.
Dawn: Implementation of WebGPU, used in browsers and machine learning tasks.
ANGLE (Almost Native Graphics Layer Engine): Abstraction layer for OpenGL ES on DirectX, Metal, and Vulkan. Used by both Mozilla and Android.
Skia: 2D platform-independent raster graphics library for rendering text, shapes, and images. Skia is used by Mozilla, Chromium, Android and many others.
WebGL2: (Significant Contributor) Open standard for interactive 2D and 3D graphics.
WebGPU: Successor to WebGL, offering lower-level access to GPU resources.
Cronet: Cross-platform networking library based on Chromium's networking stack.
WebRTC: Framework for real-time communication like audio, video, and data sharing. Significant collaboration with the IETF and W3C, but the majority of development is driven by Google's engineering teams. LibRTC, derived from WebRTC, is extensively used in native applications.
QUIC/HTTP3: Faster, secure transport protocol replacing TCP in many cases.
SPDY/HTTP2: Earlier work to optimize HTTP communication
Brotli: Advanced compression algorithm for web content.
Certificate Transparency - Chromium has driven the adoption of Certificate Transparency, a framework for logging all issued certificates in public, verifiable logs.
Chrome DevTools: The most widely used and essential suite of tools for web developers, enabling efficient debugging, profiling, and optimization of web applications. It is the primary choice for most developers developing on the web platform, providing unparalleled capabilities to inspect, edit, and debug HTML, CSS, JavaScript, and network performance in real time. Chrome DevTools is used within every Chromium-based browser.
Lighthouse: Automated tool for improving the quality of web pages (performance, accessibility and SEO).
Remote Debugging Protocol: Interface for debugging web applications remotely.
Sandboxing: The largest investment in security and safety technology for browser processes isolation to limit security vulnerabilities. Benefits affect the entire ecosystem including webviews and electron apps.
Safe Browsing: Warns users of malicious websites and phishing attempts. This is used by all major browsers including Safari and Firefox.
Fuzzers: Automated tools designed to detect bugs and vulnerabilities by generating and testing unexpected or invalid inputs. The Chromium project has significantly contributed to advancing fuzzing technologies, including innovations like PartitionAlloc, which enhances memory safety and reliability.
This list is far from exhaustive; it simply highlights the surprisingly broad, varied, and critical areas where Chromium plays a role. A sudden disruption to its funding would have far-reaching and unpredictable consequences, even in industries that might seem unrelated, or immune.
Chromium unsurprisingly is the core of all Chromium-based browsers. Google’s open-source Chromium project significantly lowers the barrier to entering the browser market. Its open-source license allows any party to soft-fork or hard-fork the project without Google’s approval.
Soft-forking, which involves creating a browser while still relying on updates from the project, can be done by a very small team. This allows these teams to focus on individual features to differentiate themselves while receiving the bulk of the code, features and maintenance (for example security patches) from the main Chromium project.
Hard-forking, where a party duplicates the project’s current code and assumes governance, would be costly, likely costing in the hundreds of millions to low billions annually, though still far cheaper than developing a browser engine from scratch.
It may seem surprising, given that Firefox and Safari have their own distinct engines, but Chromium plays a significant role in supporting both. This happens in two key ways. First, several components, libraries, and services maintained under the Chromium project are used by these browsers. For example, Google Safe Browsing, WebRTC, HTTP3, various codecs, and graphics libraries.
Second, Google, through Chromium, drives a vast amount of exploratory specification work. This involves designing new web standards, implementing them in Chrome (often behind developer settings), and evaluating their viability. The process is expensive, and most proposals never progress beyond early experimentation or reach standardization.
Ideally, Mozilla and Apple would take on more of this exploratory development, but Mozilla lacks the budget to push the web forward at the same scale, while Apple, despite having the resources, is insufficiently incentivised (and in some cases disincentivized) to invest sufficiently in Safari. A key challenge in shaping sound web policies is ensuring Mozilla has the funding it needs and that Apple is properly incentivized to meaningfully invest in Safari and web platform innovation.
SpaceX uses Chromium for the touchscreen interfaces in its Dragon spacecraft, a striking endorsement of its stability and reliability. Spaceflight is an inherently high-risk endeavor, where every system must perform flawlessly. That a web-based technology is trusted for such critical operations highlights Chromium’s robustness, not just for everyday browsing, but in extreme, high-stakes environments.
The rendering and UI logic in Bloomberg’s financial terminals run on Chromium, highlighting its diverse role beyond web browsing. These terminals handle vast amounts of real-time financial data, where stability and performance are crucial.
Bloomberg terminals are among the most relied-upon systems in global finance, used by traders, analysts, and institutions to make split-second decisions involving billions of dollars. They serve as a primary gateway to financial markets, providing access to market data, trading platforms, news, analytics, and communications tools.
A vast number of applications that might be considered "native" are actually built using Chromium and web technologies, then packaged within a native shell called Electron.
Microsoft TeamsVisual Studio CodeFigma
This includes popular apps like:
Microsoft Teams
Microsoft Outlook
Slack
Visual Studio Code
Skype
WhatsApp’s desktop client
Discord
Figma
Spotify
Bitwarden
1Password
Netflix’s desktop client
Signal’s desktop client
And many more. While these apps appear to be native desktop applications, they are fundamentally Chromium-based, running inside a cross-platform Electron wrapper, or a Chromium WebView.
The V8 engine is developed under the Chromium project and serves as a highly optimized JavaScript engine. While it powers Chromium-based browsers, its impact extends far beyond, as it is widely used on servers, thanks to the popularity of server-side JavaScript runtimes like Node.js.
V8 is particularly favored for handling high-demand, high-traffic applications and is extensively utilized by major organizations, including:
WebRTC, originally based on technologies from GIPS and On2 Technologies (both acquired by Google), is primarily developed within the Chromium project, but is used across all major browsers and platforms. It serves as the backbone for real-time audio and video communication, powering nearly all modern communication platforms, including:
Skia and Dawn are two critical graphics technologies primarily developed within the Chromium project. Skia is a high-performance 2D graphics library used for rendering in Chromium-based browsers, as well as in Android, Flutter, and some parts of Firefox. It provides essential drawing capabilities, handling text, vector graphics, and images efficiently.
Dawn, Chromium’s implementation of the WebGPU API, serves as an abstraction layer over modern GPU APIs like Vulkan, Metal, and Direct3D 12, enabling high-performance graphics and compute workloads on the web.
Together, Skia and Dawn power critical graphics rendering in Chromium-based browsers, Android applications, and emerging GPU-accelerated web technologies.
AV1, VP9, and WebP are video and image codecs primarily developed within the Chromium ecosystem, with significant contributions from the Alliance for Open Media (Amazon, Apple, Cisco, Google, Intel, Meta, Microsoft, Mozilla, Netflix, NVIDIA, Samsung, and Tencent). These codecs are designed to deliver high-quality compression with lower bandwidth usage, making them essential for modern web and media applications.
AV1, the successor to VP9, is an open-source, royalty-free video codec optimized for streaming efficiency. It is widely supported in Chromium-based browsers and Firefox, and is increasingly adopted by platforms like YouTube, Netflix, and Facebook.
VP9, developed by Google, remains a key video codec in YouTube and WebRTC applications, offering superior compression compared to H.264. It is supported in Chromium-based browsers and Firefox, and more recently in Safari.
WebP, a modern image format designed to replace JPEG and PNG, provides superior compression with lossless and lossy options. It is natively supported in Chromium-based browsers, Firefox and Safari.
These codecs are integral to efficient media delivery across the web, including for many native apps, reducing file sizes while maintaining high visual fidelity.
# 12. What Does It Cost to Develop and Maintain the Web Platform?
Determining the cost of developing a browser engine is challenging, as most companies keep this information private. Mozilla is one of the few exceptions, as its non-profit structure makes its budget more transparent.
Additionally, defining the full scope of browser engine development is complex. The web platform encompasses a vast range of technologies that evolve based on how the web is being used. In many ways, it functions as an interoperable operating system, running on top of major OS platforms while providing a foundation for countless applications and services.
The distinction between browser spending and platform spending is also crucial. Browser spending typically funds features specific to a single browser, focusing on user-facing improvements that do not necessarily benefit the broader web ecosystem or applications that rely on the platform. Platform spending, on the other hand, supports fundamental web technologies that are shared across all browsers using that engine, and often benefit other engines as well. This investment directly enhances the capabilities, performance, and reliability of web applications, making it essential for the long-term success of the open web. While both types of spending have value, platform investment is by far the most critical when assessing the net benefit of the web to the world.
Maintaining the current capabilities of the web platform is important, but equally critical is continuing to push it forward. Advancing the web requires significant investment in research and development, as creating new functionality is both complex and costly. Each new feature must be designed, tested with developers, and undergo a rigorous standardization process before becoming part of the platform. Many proposed features, even those that seem promising, fail to make it through this process and are ultimately abandoned.
Despite these challenges, ongoing innovation is essential for the web to remain competitive with proprietary platforms. Without sustained investment in developing and refining new web technologies, the web risks stagnation and falling behind.
Recent data published by Google indicates that it is responsible for approximately 94% of all Git commits to Chromium. While this is a crude metric, we believe it provides a reasonable estimate of Google’s relative financial contribution to Chromium’s development which we estimate at approximately 90%.
Estimates suggest Google employs around 2,000 engineers working on Chrome and Blink/Chromium, with an estimated 50-50 split between browser and platform development. With an average cost of $500,000 per employee, this suggests that Google’s technical staff alone costs roughly $1 billion annually.
When accounting for additional expenses, including legal, marketing, security, and other supporting departments, we estimate that Google’s total annual investment in Blink/Chromium is approximately $1 billion with another $1 billion on the browser layer. This rough figure is consistent with estimates from academic researchers studying the topic.
We estimate that Apple spends between $300 – 400 million annually on Safari and WebKit. This estimate is derived from an analysis of employee contributions based on Git commits, Apple's presence in web standards discussions, average salaries at Apple, and expected overhead costs.
However, this remains an approximation, as there is no publicly available breakdown of Apple's investment in Safari. Without detailed financial disclosures or insider information, an exact figure is impossible to determine.
We have long argued that Safari is significantly underfunded compared to Chrome and that Apple needs genuine browser competition on iOS to create the incentive to invest more heavily in web platform development. Without meaningful competition, Apple has little motivation to allocate additional resources toward improving Safari and WebKit at the scale required to keep pace with the evolving web.
Additionally, Apple has a significant disincentive to allowing the web to compete effectively with its app store, which earns the company roughly $31 billion per year and has long feared a web-based alternative. In 2011, Philip Schiller internally sent an email to Eddy Cue to discuss the threat of HTML5 to the Apple App Store titled “HTML5 poses a threat to both Flash and the App Store”.
Food for thought: Do we think our 30/70% split will last forever? While I am a staunch supporter of the 30/70% split and keeping it simple and consistent across our stores, I don’t think 30/70 will last unchanged forever. I think someday we will see a challenge from another platform or a web based solution to want to adjust our model
Internal Apple Emails (emphasis added)
We lack precise data on how much other Chromium-based browsers invest beyond their contributions to Chromium itself. However, it is clear that Microsoft allocates significantly more resources to developing its browser than to contributing to the underlying platform, a strategy made possible by Google shouldering the majority of Chromium’s development costs.
Smaller Chromium-based browsers can focus their limited resources, typically in the range of a few million to tens of millions, on niche features and differentiated user experiences rather than maintaining or contributing significantly to the Chromium core. This model of competition is valuable, as it pressures larger browsers (such as Chrome, Edge, Firefox, and Safari) to adopt new features they might otherwise ignore and preserves the potential for one of these smaller players to grow its market share over time.
Mozilla is one of the few browser vendors with publicly available spending data for its work on Firefox and the Gecko engine, with an annual budget of approximately $420 million. Although Mozilla allocates some resources to other initiatives, the bulk of its funding supports browser development and engine maintenance. Based on industry norms for browser vendors who maintain their own engines, it's reasonable to estimate a roughly 50-50 split between browser-specific features and web platform investment. This suggests a rough upper bound of $400 million currently being invested annually in Firefox and Gecko, with approximately $200 million directed specifically toward the Gecko engine.
# 12.5. Is $400 Million a Year Enough to Fund Gecko and Firefox?
Some have argued that Mozilla’s budget could serve as a baseline for reasonable investment in the web platform, but this approach is deeply flawed for several reasons.
First, Firefox is a shrinking browser that is struggling to maintain market share. To thrive rather than simply survive, Mozilla would need significantly more funding than it currently receives. Treating its underfunded budget as a benchmark ignores the reality that Firefox is not in a strong competitive position.
Second, Mozilla benefits heavily from the vast amount of work done in Chromium, despite having its own distinct browser engine. Chromium’s contributions extend far beyond its own ecosystem, influencing web standards, shared libraries, and platform innovations that Firefox incorporates. If Chromium’s funding were drastically reduced, Mozilla’s costs would rise significantly just to maintain its current pace of development and quality.
Third, the very remedies being proposed in this case, could bankrupt Mozilla. If search revenue-sharing deals are eliminated or severely restricted, Mozilla’s primary funding source would disappear, threatening its survival entirely.
Finally, these remedies risk reducing total investment in web platform development by 70%. The idea that a collapse in funding of this magnitude would have no consequences for the web platform defies belief. The web provides trillions of dollars in economic value, and its continued growth depends on sustained investment in browser engines and platform evolution.
The DOJ has a legitimate case against Google and is right to take action to dismantle its search monopoly. However, remedies should not be applied like a sledgehammer, nor should the collateral damage to the adjacent markets of browsers and the web platform be ignored.
The DOJ does not have to choose between breaking Google’s dominance and preserving a well-funded web, they can achieve both. It is possible to curb Google’s monopoly, restore competition, and ensure continued, substantial investment in the web platform without crippling smaller browsers like Firefox. In fact, if structured correctly, the DOJ’s remedies could increase investment in the web platform.
If Google is forced to divest Chromium, the project faces a serious risk of falling into a tragedy of the commons, a scenario where an essential shared resource benefits many, yet no single entity is willing to sustain the cost of maintaining it.
Chromium is the foundation of the majority of modern web browsers, including Chrome, Edge, Opera, Vivaldi, and many others. It enables businesses across industries to generate trillions of dollars in value by providing a high-performance, secure, and continuously evolving web platform. However, the cost of maintaining and advancing Chromium is massive, requiring at least 1 billion dollars in annual investment to support its engineering teams, security updates, compatibility improvements, and new web standards development.
The challenge is that while many companies benefit from Chromium’s existence, none may be willing to fund it at the scale necessary to keep it competitive. Microsoft, for example, benefits from Edge’s Chromium foundation but contributes only a small fraction of what Google does to Chromium’s development. Similarly, while companies like Meta and Amazon depend on the web platform for their core services, they contribute minimally to Chromium’s ongoing development compared to Google. If Google is forced to divest the project, and if no individual company or consortium steps up to replace its funding, Chromium could stagnate or deteriorate, leading to slower web innovation, a significant increase in bugs, declining security, and greater reliance on proprietary platform ecosystems such as iOS and Android.
The full economic impact of such a scenario is difficult to quantify, but the risks are enormous. The U.S. digital economy alone is estimated to contribute $2.4 trillion and support 8 million jobs. The web has been well-funded for two decades, allowing it to become a critical pillar of the global economy. The repercussions of a crippling blow to the underlying funding of the web platform could have unpredictable and lasting consequences for businesses, developers, and users worldwide.
Mozilla faces a serious risk of bankruptcy if its primary source of funding is cut off. As one of the last independent browser vendors maintaining its own engine. Its collapse would leave the web even more dependent on a small group of dominant players while also silencing an independent voice in web standards development.
Chromium’s funding could be severely reduced, resulting in slower development, increased security vulnerabilities, fewer new features, and a significant rise in bugs. This would weaken the web platform’s overall competitiveness, making it less stable and reliable for businesses, developers, and organizations that depend on it.
Without sustained funding, efforts to bring alternative browser engines to iOS may never materialize. This work is primarily being driven by Google and Mozilla, and if financial constraints prevent them from completing it, Apple’s long-standing restrictions on third-party browser engines will continue to suppress competition in both browsers and web apps on iOS. Even as regulatory intervention in the EU, UK, and Japan pushes for change, a lack of viable competitors could limit the effectiveness of those efforts. Additionally, this could undermine the DOJ’s ability to address Apple’s anti-competitive behavior alleged in its complaint.
A weaker browser market would reduce competitive pressure on the remaining players, slowing innovation and further entrenching Google and Apple’s control over their respective mobile app ecosystems. With fewer challengers advocating for better performance, privacy, and open standards, users would face a stagnant web, leading to fewer choices, lower-quality software, and higher costs. Startups and independent developers may be locked out if the web becomes an unreliable distribution platform, increasing barriers to entry and making digital markets even more expensive to compete in.
# 15. Estimating the Impact on Web Platform Funding
If the DOJ proceeds with remedies requiring Google to divest Chrome and banning all search engine revenue sharing deals, including those with smaller browsers, the impact on web platform investment could be profound.
Quantifying this impact is inherently difficult. Current investment levels are largely opaque, with Mozilla being the only significant exception. What follows is informed, but ultimately speculative, analysis.
This concern may become moot if the DOJ finds a buyer for Chrome who is willing, capable, and incentivized to invest in the web at levels comparable to Google. The central question is whether such a buyer actually exists.
We estimate that Mozilla currently invests around $200 million per year in the web platform, with a similar amount going into the browser layer. If the Google search deal, which accounts for the vast majority of Mozilla's revenue, is terminated, it's hard to see Mozilla surviving in its current form.
However, Mozilla does have sizable financial reserves, so they won’t vanish overnight. But those reserves won’t last forever. In fact, for Mozilla to remain a meaningful player in the browser space, its budget would need to grow, not shrink. Firefox continues to lose users, even with the Google deal in place.
If Google is barred from revenue sharing and Mozilla turns to Bing or other search engines, it’s unclear how much they would be willing to pay in a market without Google bidding up the price. If Microsoft pays half of what Google paid, for example, then Mozilla will, over the long term, decline into irrelevance and cease to be the positive force for the web that it is today.
That is, Mozilla's net contribution to the web platform is likely over the medium term to drop to near zero as a result of these remedies.
Benefits for Google of a strong web platform such as support for its online services and keeping the world's data indexable will remain and are individually powerful, but these remedies will both mechanically and psychologically change Google's relationship with the web. We can see this with companies such as Meta, Amazon, Microsoft and Netflix, who radically benefit from the web, and while they do fund it, do not fund it to anywhere near the level that Google does.
The most immediate change is the disappearance of the most significant and clear financial incentive to fund Chrome and Chromium, the Google Search default. With Chrome divested and revenue sharing banned, Google would no longer derive direct financial benefit in this manner from the project. That changes the return on investment calculus dramatically.
There are also open questions about what happens to the engineering infrastructure around Chrome and Chromium. What becomes of the thousands of Chrome and Chromium engineers currently at Google? If the new owner of Chrome decides not to continue investing at current levels, and fires most of the team, can Google hire them back? Would that be permitted under the terms of the divestment?
Control over Chromium itself may also become contested. If the new owner of Chromium deprioritized or slowed down development and Google disagrees with the direction or pace, can it legally fork Chromium and resume independent investment? Would that be permitted under the court’s remedies? These aren’t abstract concerns, they directly affect whether Google retains the technical and legal ability to keep pushing the web forward and to continue to invest in the web platform. Remember, Google is widely believed to have forked Blink from WebKit due to frustration that Apple was preventing them from investing heavily and pushing the web forward. The risk here is that history repeats itself, but under far more constrained and politically sensitive conditions.
Beyond logistics, there’s a psychological and political hurdle inside Google. After being forced to give up a major asset like Chrome, and losing the staff, control, and influence that came with it, it will be a hard internal sell to reinvest heavily in the web platform. The idea that Google should hire a new 2000 staff (the existing browser staff have presumably left with the new entity) and spend a billion dollars a year for the benefit of browsers it no longer owns, in a market it’s been pushed out of, is going to face strong resistance.
Google’s role in web standards bodies may also be affected. Without a browser, its influence could fade. If its position in standards processes is weakened, the strategic value of continuing to invest in web platform research and development could shrink accordingly.
All of this points in one direction: a significant and prolonged decline in Google’s support for the web platform. While investment won’t drop to zero, we expect it to fall sharply.
Our best estimate is that Google’s current ~$1 billion per year investment will decline to under $150 million annually if these remedies are enforced. Again, this is of course speculation but for those suggesting other figures they need to argue convincingly why (and mechanically how) Google will continue to invest at higher levels.
Based in part on Git commit activity, which is roughly one-twentieth that of Google, we estimate that Microsoft currently invests around $100 million per year into the web platform. Microsoft is believed to allocate significantly more funding to the browser layer of Edge.
Microsoft has strong incentives to invest in the web. It has a browser with reasonable market share, it has the second largest search engine in the world and a significant number of apps such as Teams and VS Code, that are essentially web apps wrapped in a native shell running on Chromium.
Additionally, Microsoft stands to gain from increased Bing revenue if Google is banned from revenue sharing, potentially giving it more financial room to support browser development.
However, Microsoft is also heavily dependent on Chromium. If Google sharply reduces its investment and the new owner of Chrome fails to fill the gap, Microsoft will feel the impact acutely. Much of the stability, security, and day-to-day maintenance of Chromium is currently shouldered by Google. Without that, Microsoft will be forced to pick up the slack.
It also has far more resources and web-aligned revenue than smaller Chromium-based browser vendors, which makes it better positioned to adapt. We believe Microsoft will maintain its current investment and may even slightly increase it.
That said, the nature of Microsoft's investment will likely shift. Today, Microsoft is able to focus on features that advance its own strategic goals because Google handles much of the foundational maintenance. But if Google steps back, Microsoft will need to redirect resources toward infrastructure work: security, bug fixing, and performance tuning, at the expense of new feature development.
We estimate that Microsoft will continue to invest around $100 million annually but with a more defensive and maintenance-focused allocation.
We estimate that Apple currently invests approximately $150 million per year into the web platform, with a similar amount directed toward the Safari browser layer.
Apple has clear incentives to ensure Safari remains “good enough” for everyday web use, sufficiently poor browser performance noticeable by consumers would damage the Apple brand. At the same time, Apple has strong disincentives to support web capabilities that could enable the web to meaningfully compete with its App Store. While it does face some competitive pressure from Chrome, Firefox, and Edge, this pressure is severely diminished by Apple’s ban on third-party browser engines on iOS, which effectively eliminates true browser competition on its mobile devices.
However, if the proposed DOJ remedies are implemented, the landscape will shift dramatically. Mozilla may collapse, Google’s investment in the web platform is expected to decline sharply, Microsoft will likely pivot toward stability over new features, and ports of Gecko and Chromium/Blink to iOS are likely to be canceled. In this environment, Apple will face far less competitive pressure to advance the web. While it will still be motivated to maintain a secure browser, if only to avoid damaging headlines and regulatory pushback, its incentives to support new web features will diminish significantly.
The cancellation of Apple’s search deal with Google would further reshape the dynamics. Safari would go from generating an estimated $19.7 billion in pure profit annually, with an extraordinary 98.5% profit margin, to costing Apple an estimated $300 million per year. While Apple can easily afford to continue funding Safari and WebKit without a revenue stream, there will be psychological impact within the company. A once massively profitable product line will suddenly become a cost center.
Taking all of this into account, we expect Apple’s investment in the web platform to decline. Our estimate is that annual spending would fall from $150 million to around $100 million.
Smaller browser vendors vary in how they generate revenue; some rely on search deals with Google or Bing, while others pursue alternative business models. However, compared to Google, Apple, Mozilla and Microsoft the financial resources available to these vendors is more limited. They also depend far more heavily on upstream contributions from Chromium rather than investing directly in the web platform themselves.
These vendors typically focus on innovation within the browser layer, such as user interface improvements, privacy tools, and niche features, instead of contributing to the underlying web platform. This is reflected in their minimal presence in Chromium’s development, accounting for less than 1% of Git commits. Despite this, they play an important role in browser diversity and innovation. If any of them were to grow significantly in market share, their contribution to the web platform would likely increase accordingly.
Given the potential loss of search revenue and ongoing resource constraints, we expect their already small investment in the web platform to either stay flat or decline further.
Igalia is an independent open-source consultancy that plays a valuable role in the browser ecosystem. Their team of skilled engineers contributes to a wide range of browser engines and web standards, often helping implement features across multiple platforms. In some cases, browser vendors hire them to fix bugs or implement features. In other cases, non-browser vendors hire them to implement or spec needed functionality. For example, Bloomberg paid Igalia to implement CSS Grid in Chromium and Webkit.
However, while they play a critical role in lowering the technical barrier to contributing to the web platform, particularly for parties without in-house browser engineering expertise, they typically do not directly fund this work themselves. Instead, they operate on a contract basis, with their efforts funded by clients who hire them to advance specific features or capabilities. As such, Igalia’s overall contribution to the web platform tends to scale in proportion to the broader level of investment from other stakeholders. If overall funding for web platform development increases or decreases, Igalia’s role is likely to grow or shrink proportionally.
Other non-browser companies, such as Intel, also contribute to the web platform. For example, contributions from these organizations account for approximately 1.5% of the commits to Chromium. It’s worth noting that, as mentioned previously, many of these companies channel their contributions through contracted work with firms like Igalia, so a portion of non-browser vendor investment is already reflected within Igalia’s overall activity.
How this investment will evolve remains uncertain. On one hand, if as predicted overall investment in the web platform plummets sharply, some of these companies may step up their involvement to ensure the continued development and support of features critical to their products. On the other hand, a significant drop in momentum and confidence in the web platform could prompt a strategic shift toward native ecosystems, leading these companies to reduce or withdraw their investment in the web platform altogether.
Everything hinges on who, if anyone, ends up buying Chrome. The ideal buyer would need deep financial resources, strong technical capability, and a strategic incentive to keep the web open and competitive. But it’s unclear whether such a buyer exists. Without one, Chrome risks being reduced to a cash-generating product with its roughly $1 billion annual web platform budget slashed.
The DOJ has not suggested any binding conditions requiring buyers to continue investing in Chromium or the web platform. It’s also unclear what exactly the buyer would receive. Will they inherit the current engineering staff? Will they gain control over the Chromium open-source project, the Chromium brand, or Google's positions on key web standards bodies? These details matter, and currently, they remain unanswered.
While it would be ideal if the new entity maintained or even increased spending, as we've outlined earlier in this analysis, there will be immense financial pressure to cut costs. This is especially true given that this new owner will lose its most obvious revenue source: the ability to sell the default search engine slot to Google.
They will, of course, be able to sell that slot to another search engine, but it is not clear whether the resulting revenue will be sufficient. According to court documents, Microsoft offered Apple $4 billion per year:
Microsoft offered Apple a revenue share rate of 90%, or a little under $20 billion over five years. [...] The analysis assumed that Microsoft would initially pay Apple 100% of Bing’s revenue share, while Google would continue paying Apple % revenue share if retained as the default. The analysis showed that if Apple extended the ISA, it would gain about $40 billion from Google in the next five years, and then $70 billion in the following five years. Id. at 974. This was double the $20 billion Microsoft offered Apple for the first five years.Memorandum Opinion - United States of America vs Google LLC (emphasis added)
However, the 90% revenue share rate is clearly unsustainable. Realistically, if Microsoft were not bidding against Google, it’s unlikely to offer more than $1 to $1.5 billion per year. Meanwhile, Chrome and Chromium are estimated to cost $2 billion annually to develop. Servicing a $20 billion acquisition loan could add another $2 to $5 billion per year, depending on the loan’s risk profile. Adding a modest 10% profit target, roughly $2 billion per year, brings the total funding requirement to between $6 and $9 billion annually. That would leave the buyer facing a shortfall of approximately $5.5 to $8 billion per year.
That said, even a short-term profit-driven buyer won’t reduce spending to zero. It will still be in their interest to keep Chrome at least minimally secure and functional. However, we could expect most new feature development to be halted, the Chromium port to iOS likely canceled, and much of the engineering team acquired from Google to be laid off.
Taking all this into account, we estimate that the new Chrome owner would reduce investment in the web platform to, what Microsoft is estimated to be investing, roughly $100 million per year, down from the current $1 billion.
It’s also important to note that this isn’t the worst-case scenario. Given the challenging dynamics of such a sale, there remains a very real possibility that the new Chrome entity could ultimately go bankrupt.
We can now estimate the overall change in web platform investment based on the likely impact across the major contributors.
Current estimated annual investment:
Google: $1,000 million
Mozilla: $200 million
Microsoft: $100 million
Apple: $150 million
Total: $1.45 billion per year
Projected post-remedy investment:
Google: $150 million
Mozilla: $0 million
Microsoft: $100 million
Apple: $100 million
Chrome Buyer: $100 million
Total: $450 million per year
This represents a decline of roughly 70% in annual investment into the web platform, a dramatic reduction that could severely undermine the pace of web innovation and long-term competitiveness of the open web.
Again, it should be stressed that this is an estimate, but we have yet to see any other careful analysis on what the change in investment will be or why a 70% plunge in investment for the web platform would not be catastrophic. Anyone making such an analysis must answer the questions we pose in this section.
While a 70% drop in web platform investment may sound dramatic, it is not, in our view, the worst-case scenario, it is the most realistic and probable outcome based on the incentives created by the DOJ’s proposed remedies. Google would lose its primary reason to invest, the new owner of Chrome would face severe financial pressure and lack viable revenue streams, Mozilla’s funding would be cut off, Microsoft would shift toward maintenance over feature development, and Apple would have little incentive to increase or maintain its already limited investment. If this is not the median case, then those who argue otherwise must identify who will fund the web platform at current levels, and why.
Enabling real competition between search engines would be a major win for the web.
For consumers, greater competition could lead to a better search experience offering higher-quality results, fewer ads, stronger privacy protections, and more choice. Many users have criticized Google for placing too many ads ahead of actual search results. If Google had to compete more aggressively for users, it would be incentivized to improve its services while keeping them free.
On the business side, Google serves as an aggregator between companies and their customers, with advertisers paying Google for placement. While this model is less extractive than mobile app stores, where Google and Apple demand a 30% cut, greater competition in search advertising would push ad prices down, ultimately reducing costs for businesses and, in turn, consumers. Regardless of the criticisms surrounding online advertising, it continues to be a crucial funding source for much of the internet.
Finally, the DOJ’s intervention could boost browser competition on both iOS and Android by terminating the Apple-Google search deal and eliminating Chrome’s placement agreements on Android.
All of this could be a huge positive, provided the DOJ structures its remedies carefully to avoid plummeting investment in the web platform or bankrupting smaller browsers, which remain critical to a competitive internet.
# 17. Should the Apple Google Search Deal be Banned?
The Internet Services Agreement (ISA) is the official name of the landmark deal between Apple and Google, under which Google pays Apple a substantial share of its search advertising revenue from Safari on iOS and macOS. In return, Apple sets Google as the default search engine in Safari across both platforms and, in most cases, prioritizes Google Search for Siri and Spotlight queries. This partnership ensures Google's dominance in Apple's ecosystem while securing a significant revenue stream for Apple.
Astonishingly, on iOS, Google has also agreed to share its search engine revenue with Apple, even from its own browser, Chrome, a highly unusual arrangement. Google is effectively paying Apple for searches conducted by users who have already chosen Google’s browser. The typical browser monetization strategy is to expand market share to maximize search revenue. Without the Chrome revenue share clauses, maximising Chrome’s share on iOS would reduce the amount of revenue Google would have to share with Apple. However, the ISA comes strikingly close to a tacit agreement not to compete with Apple for browser share on iOS. This arrangement undermines Google’s incentive to compete for browser market share on iOS.
When Microsoft CEO Satya Nadella testified, he posited another reason for Apple to keep the Google deal going: Google might cause trouble if it went away. Google could use its ultra-popular apps like Gmail, Maps, and YouTube to promote Chrome and the Google app, diverting people away from Safari and potentially submarining the value of Apple’s deal with any other search engine. In that sense, not only was the Google / Apple deal mutually beneficial but it may have also been something like a peace treaty.
The Verge - On Apple - Google Search Deal
This deal is also for a colossal amount of money even in the context of companies the size of Google and Apple.
In 2022, Google’s revenue share payment to Apple was an estimated $20 billion (worldwide queries). This is nearly double the payment made in 2020, which was then equivalent to 17.5% of Apple’s operating profit. Google’s 2022 payment under the ISA is more than all of its other revenue share payments combined and is approximately double that combined value.
Memorandum Opinion - United States of America vs Google LLC
This single deal accounted for roughly one-sixth of Apple's annual profit, a striking figure considering the immense success of its hardware sales, particularly the iPhone. Perhaps for this reason, this deal was specifically singled out by name as a significant issue to fix in the DOJ's opening statement when it filed the complaint in 2020.
An argument in favor of such a deal might be that Apple reinvests a significant portion of the revenue into developing Safari and WebKit. However, by our estimate, less than 3% is actually being reinvested into Safari and WebKit. Neither Google nor Apple provided concrete evidence to the contrary during the case:
The ISA does not require Apple to use revenue share payments to improve Safari, and Google has presented no evidence that Apple does so. Mozilla likely does use its payments from Google to upgrade Firefox (given that those payments make up 80% of its operating budget), but Firefox’s contribution to the overall search market is so small that the additional output it produces, at most, marginal procompetitive benefits.
Memorandum Opinion - United States of America vs Google LLC (emphasis added)
The DOJ has argued that search engine default deals have blocked rivals from effectively entering the search market and denied them the scale they need to outbid Google. Out of these deals, the ISA is by far and away the most significant.
over half of all search volume in the United States flows through Apple devices
The DOJ is undoubtedly correct that under the current market conditions for search engines in the United States, none of the other search engines has the ability to outbid Google for default placement. In court documents it was revealed that both Microsoft and DuckDuckGo repeatedly approached Apple to set up a search deal and replace Google as the default search engine on iOS and MacOS.
Microsoft offered Apple a revenue share rate of 90%, or a little under $20 billion over five years
Both Apple has claimed in both court documents and the media that it has chosen Google as it is the best search engine, implying that the size and reliability of the payments was not the primary concern.
I think one of the benefits, for example, that Google gets from Apple is that we are telling the world that Google is the best search engine, because that's what they would expect Apple to pick.
Eddy Cue - Apple’s Senior Vice-President of Services
However, reading through the court documents, it seems clear that this was about revenue above all else. Apple would not replace Google unless another party could reliably pay more.
Apple evaluated the potential financial impact of replacing Google with Bing. See generally UPX273. The analysis assumed that Microsoft would initially pay Apple 100% of Bing’s revenue share, while Google would continue paying Apple % revenue share if retained as the default. Id. at 975–76. The analysis showed that if Apple extended the ISA, it would gain about $40 billion from Google in the next five years, and then $70 billion in the following five years. Id. at 974. This was double the $20 billion Microsoft offered Apple for the first five years. Id. ('Clearly, Microsoft can’t commit to these numbers or even anything close to them.').
'In response to this analysis, Apple’s Senior Vice President of Services, Eddy Cue, internally proposed that the only way Apple could make the switch was if Microsoft were to guarantee minimum annual revenues of $4 billion the first year and a stepped increases of $1 billion per year over the next four years, for a total of $30 billion in guarantees. Still, even that approach would produce revenues well short (by $10 billion) of Apple’s expected earnings if it retained Google as the default. Id. (“[T]his doesn’t match Google ($30B v. $40B) and provides no protection for the following 5 years[.]”). Cue concluded that a Microsoft-Apple deal would only make sense if Apple “view[ed] Google as somebody [they] don’t want to be in business with and therefore are willing to jeopardize revenue to get out. Otherwise it [was a] no brainer to stay with Google as it is as close to a sure thing as can be.” Id.; Tr. at 2528:13-16 (Cue) (“And so Google’s a sure thing. They have the best search engine, they know how to advertise, and they’re monetizing really well.”). Memorandum Opinion - United States of America vs Google LLC (emphasis added)
Apple also claims that they have no intention of building their own search engine and that they chose Google as it was the best search engine. While it is difficult to determine whether Apple has the capability or desire to develop a successful search engine, the alternative of selling the default search position to another party is easier to evaluate.
Is it truly credible that Apple secured such a substantial payment from Google without the implicit or explicit threat of replacing them? While this video is dated, it provides a valuable example of Apple's negotiation tactics in the past.
Setting aside the DOJ's extensive list of other proposed remedies, what would be the outcome if they successfully terminated the Apple-Google search deal, and what would the consequences be? It is important to note that the DOJ is particularly focused on Google's share of the U.S. search engine market, making U.S. statistics the most relevant in this context.
First, it is helpful to work out what success looks like in the DOJ's eyes. Luckily, the court documents include some interesting context here.
[A] market share below 50% is rarely evidence of monopoly power, a share between 50% and 70% can occasionally show monopoly power, and a share above 70% is usually strong evidence of monopoly power.
Memorandum Opinion - United States of America vs Google LLC
It is also worth noting that the entire judgment can be withdrawn after five years if Google's market share falls below 50%.
In essence, the goal is to reduce Google's share in the U.S. search engine market from around 90% to either below 50%, a complete victory, or, at the very least, to somewhere between 50% and 60%.
So, if the DOJ decides to enforce this remedy, and it would be remarkable if they chose to withdraw it, what would happen?
Suddenly, Google would have a strong incentive to compete on iOS, assuming they were still allowed to participate in the browser market. Meanwhile, Apple would face a $20 billion annual shortfall from the lost Google deal and would be motivated to find an alternative revenue stream. While it is unclear whether Apple would enter the search engine market themselves, they would undoubtedly have a strong incentive to strike a deal with Bing or another search provider.
The case offers some insight into what such a deal might look like, though the value would likely be lower unless fierce competition emerged among the smaller search engines. But what if Apple suddenly switched all U.S. users who hadn't proactively chosen a default browser to another search engine? How many would manually switch back to Google?
Fortunately, Mozilla provides some relevant statistics, revealing that user behavior can vary significantly, likely depending on the quality of the replacement search engine.
When Mozilla swapped Google out for Yahoo in 2014, Yahoo gained a mere 20% of users. That is 70% of users switched back to Google or to another search engine.
When Mozilla switched the Firefox default GSE from Google to Yahoo, the query volume for each search provider changed. Google’s share of queries on Firefox abruptly dropped from between 80–90% to between 60–70%, a 20-point decline. Yahoo’s share, in turn, increased from around 10% to 30% of the Firefox queries. Memorandum Opinion - United States of America vs Google LLC
Later in 2016 when Mozilla experimented with switching the search engine to Bing, Bing only managed to retain a 20-35% share.
In a 2016 experiment, Mozilla switched the default GSE on both new and existing users from Google to Bing. By the twelfth day, Bing had kept only 42% of the search volume. After some additional time, those numbers dropped to 20–35%, depending on certain variables. Memorandum Opinion - United States of America vs Google LLC
However when Mozilla repeated the experiment 4 years later, in 2022, Bing retained 65% of the users. This is likely due to the improvement in the quality of Bing over those years.
This suggests that unlike choice screens, which tend to have important but quite small effects, in the order of a few percentage points, actually switching everyone's default could be massively impactful. It seems likely that search quality plays a critical role in whether users switch back, i.e. users annoyed at poor search results are likely to manually switch back. Given that the DOJ proposal contains provisions such as forcing Google to allow other search engines to syndicate its results, this should result in a bump in quality for these search engines and would suggest they would manage even higher retention rates.
So were Apple to switch the default from Google to another reasonably high quality search engine (such as Bing), just how much of the United States search traffic would Google lose and what would its market share be reduced to?
The Google Search App is not available on macOS, so the entirety of this is on iOS. The case doesn’t provide the percentage for iOS but we can calculate it.
Safari, Spotlight and Siri make up 73.7% of searches on iOS and roughly that percentage would be impacted by switching the default search engine.
Between Siri, Spotlight, and Safari, Apple gets about 10 billion user queries per week. Roughly 80% of those queries are entered into Safari; Siri and Spotlight thus make up a minority of queries.
Memorandum Opinion - United States of America vs Google LLC
The sources of traffic are Safari, Spotlight and Siri, Chrome, Google Search App and other browsers. From the above data and the previous points we know for iOS that the Google Search App is 12.2%, Safari is 5.3 times the Google traffic of Spotlight and Siri, 8 times the Google traffic of Chrome and 37.3 times the Google traffic of other small browsers combined. That is if Safari share of Google traffic on iOS is x then:
Using this we can infer:
Source
Percentage Share Google Search
Safari
65.5%
Spotlight and Siri
8.2%
Google Search App
12.2%
Chrome
12.4%
Other Browsers
1.7%
That is Safari, Spotlight and Siri combined make up 73.7% of Google searches on iOS.
67.1% of Apple’s searches on both platforms would be impacted by changing the default search engine.
Note: that while Spotlight and Siri can show results that link directly to a third-party website, the case does not quantify how significant it was. Google does not appear to have attempted to make Apple remove this functionality via the search deal, instead they seemed more concerned about Apple potentially expanding it in future. As such we have assumed its impact is minimal.
More than 65% of users would keep the new search engine if Apple was to switch the default. Again this is likely conservative as it depends on search quality which will be significantly improved by the syndication remedy.
It makes sense to use the more recent figure as the change is mostly likely due to improved quality of Bing search between those dates.
43.6% of Apple’s US users would switch to and stick to a new search engine.
This calculation is a prediction of what would happen if Apple were to change the search engine default for all users on iOS and macOS for Safari, Spotlight and Siri to another search engine. Some percentage of users would switch back to Google, thus lessening the impact.
= (percentage Google Search traffic impacted by changing the default) * (retention rate of new search engine) = 67.1% * 65% = 43.6%
This would reduce Google’s market share in the US by 21.8%.
= (Percentage of Apple traffic moved to new Search Engine) * (Apple devices share of Google's search traffic in the United States)
= 43.6% * 50%
= 21.8%
Google’s search engine currently has an 89.2% market share in the United States.
“Measured by query volume, Google enjoys an 89.2% share of the market for general search services”
Apple switching the default search engine on iOS and macOS would conservatively reduce Google’s United States market share down to 67.4%.
= 89.2% - 21.8%
= 67.4%
Conservatively, based on actual statistics, if Apple were to strike a deal with another search engine, and it is hard to imagine they wouldn't, over 21.8% of Google's search traffic would immediately shift to that new provider. This would result in another search engine gaining and retaining 21.8% of the U.S. search market and reducing Google's market share from 89.2% to 67.4%.
Our assessment is actually more conservative than Google’s own which is even worse for Google, as cited in court documents.
Google estimated that if it lost the Safari default placement, it would claw back more search volume on desktop than on mobile. (Google would recover only 30% on iOS but 70% on MacOS) Memorandum Opinion - United States of America vs Google LLC (emphasis added)
That is, if Apple were to switch the default on both iOS and MacOS to a search engine other than Google, Google would lose 70% of its share on iOS and 30% of its share on macOS.
We need some addition statistics to calculate the total predicted change in share here:
18% of Apple’s searches happen on macOS and 82% on iOS.
As calculated in the previous section.
62% of Apple’s US users would switch to and stick to a new search engine.
Combining that with Google’s figures of a 70% loss for iOS and a 30% loss on macOS, we get a 70% * 82% + 30% * 18% = 62% loss of market share overall on Apple devices.
This would reduce Google’s market share in the US by 31.0%.
62% * 50% = 31%
Google’s market share in the United States would be reduced down to 58.2%.
89.2% - 31.0% = 58.2%
This is even lower than our calculation of 65.7%. Note in both cases we would expect the loss to be higher due to the search engine syndication remedy increasing the quality of the other search engines. So Google’s own internal assessment predicts that this single remedy will reduce Google’s market share in the United States to sub 60%.
The DOJ judgment also includes a provision requiring Google to offer Qualified Competitors a 10-year syndication license at marginal cost, providing access to all non-advertising components of its General Search Engine.
This detail is crucial in evaluating the potential impact, as it directly affects whether other search engines can retain users while improving the quality of their own, non-Google syndicated search engines. Bing serves as a baseline with a 65% retention rate, but with Google syndication, this rate is almost certain to be higher.
Consider what happens when a company like Apple switches the default search engine. Users perform searches, and results from a non-Google search engine appear. If users encounter irrelevant results or struggle to find what they need after repeated searches, they'll likely switch back to Google, despite it being a relatively high-friction task. Conversely, if users receive high-quality, relevant results, they are far more likely to stick with the new search engine.
Using the calculations above, we can estimate the increased impact when combining the syndication remedy by adjusting the retention rate from the initial 65%. This involves replacing the 65% retention rate used in step 8 of the previous calculation.
Retention Percentage
Decrease in Google United States Market Share
65%
21.8%
70%
23.5%
80%
26.8%
90%
30.2%
That is the DOJ’s syndication remedy should greatly improve the effectiveness of their remedy prohibiting the Apple-Google search deal.
In response to the DOJ's remedy proposal, Apple's Eddy Cue (Senior Apple Management) testified.
I understand that Plaintiffs seek a remedy that would prevent Apple from receiving any revenue share for distributing Google Search on Apple devices, and that the proposed remedy would be in place for the next 10 years.
Eddy Cue - In Support of Apple Inc’s Motion to Intervene (emphasis added)
He then argued that Apple's goal was for the best user experience possible or more specifically that the current Apple-Google search deal is part of Apple’s efforts to best serve its users’ needs (as opposed to earning Apple $20 billion per year).
Only Apple can speak to what kinds of future collaborations can best serve its users. Apple is relentlessly focused on creating the best user experience possible and explores potential partnerships and arrangements with other companies to make that happen. If the remedies above were implemented, it would hamstring Apple's ability to continue delivering products that best serve its users' needs. Eddy Cue - In Support of Apple Inc’s Motion to Intervene (emphasis added)
This is despite arguing against switching to Bing in 2015 on the basis that it would make Apple $10 billion less and be risky long term from a revenue perspective.
In response to this analysis, Apple’s Senior Vice President of Services, Eddy Cue, internally proposed that the only way Apple could make the switch was if Microsoft were to guarantee minimum annual revenues of $4 billion the first year and a stepped increases of $1 billion per year over the next four years, for a total of $30 billion in guarantees. Id. Still, even that approach would produce revenues well short (by $10 billion) of Apple’s expected earnings if it retained Google as the default. Id. (“[T]his doesn’t match Google ($30B v. $40B) and provides no protection for the following 5 years[.]”). Cue concluded that a Microsoft-Apple deal would only make sense if Apple “view[ed] Google as somebody [they] don’t want to be in business with and therefore are willing to jeopardize revenue to get out. Otherwise it [was a] no brainer to stay with Google as it is as close to a sure thing as can be.Memorandum Opinion - United States of America vs Google LLC (emphasis added)
He goes on to argue that were the DOJ to prohibit such a deal between Apple and Google then either Google would get users for free or that Apple would have entirely removed the ability for users to manually set Google as the default, something that the DOJ has never asked for. This is a slightly ridiculous framing, as currently the DOJ is not suggesting that Apple block users from manually selecting Google, simply that they can not be paid to set them as the default.
He frames this as a binary choice, missing the far more obvious alternative. Apple, absent its $20 billion annual payments from Google, sells that default to another search engine.
If this Court prohibits Google from sharing revenue for search distribution, Apple would have two unacceptable choices. It could still let users in the United States choose Google as a search engine for Safari, but Apple could not receive any share of the resulting revenue, so Google would obtain valuable access to Apple's users at no cost. Or Apple could remove Google Search as a choice on Safari. But because customers prefer Google, removing it as an option would harm both Apple and its customers. Eddy Cue - In Support of Apple Inc’s Motion to Intervene (emphasis added)
Finally, he argues that Apple has no intention of developing a search engine.
From what I understand, Plaintiffs’ proposed remedies assume that, without a revenue sharing agreement or other commercial terms with Google, Apple would develop its own search engine or enter the Search Text Ad market. Apple witnesses can offer testimony and evidence explaining why that assumption is wrong. Eddy Cue - In Support of Apple Inc’s Motion to Intervene (emphasis added)
Whether or not Apple would develop a search engine is hard to say, although certainly receiving $20 billion per year from Google would certainly disincentive it. In Apple’s own internal discussions it appears that risk and a lower predicted revenue than from Google was the primary reason to not pursue this avenue.
Notwithstanding these investments, Apple has decided not to enter general search at this time. Apple would forego significant revenues under the ISA if it were to do so. (2016 email from Cue to Apple CEO Tim Cook stating that Apple would have to “jeopardize revenue” if it stopped partnering with Google); (internal Apple assessment from 2018, which concluded that, even assuming that Apple would retain 80% of queries should it launch a GSE, it would lose over $12 billion in revenue during the first five years following a potential separation from Google). It would also have to undertake the risk of consumer backlash, see (Giannandrea email stating, “there is considerable risk that [Apple] could end up with an unprofitable search engine that [is] also not better for users”), and forgo investment in other areas of product development, (Cue) (“And so if we took all of our resources and started spending them on search, sure, we could have competed with Google . . . [b]ut that meant we wouldn’t have done other things.”). Memorandum Opinion - United States of America vs Google LLC (emphasis added)
However, even if we assume that he is right and that Apple would never create a search engine, at no point in this testimony does he state that Apple would not sell the right to be the default search engine to another search engine provider. His sole argument against that appears to be that Google would retain users but this time for free, something that the available statistics do not support.
As the Court found, Google achieved its popularity and success through innovation: by building the best search engine and making smart investment and business decisions, like our early investment in mobile. People don't use Google because they have to — they use it because they want to.
Lee-Anne Mulholland - Google Vice President, Regulatory Affairs
Google claims it has a dominant market share simply because it is the best search engine. While Google is an excellent product and very likely the current best search engine in the world, it stretches credulity that Google would be willing to pay Apple $20 billion per year if they believed that canceling the deal would have little or no negative impact on their market share. Google’s own internal analysis does not support that belief.
Both Apple and Google are acting in public statements as if canceling the deal and allowing Apple to sell the default to a party other than Google will have limited impact on Google’s share of the market. Suggesting that the court will be handing equivalent market power to Google but this time for free. However the evidence in the court documents and even Google’s own assessment show that the most likely outcome is that Google market share will be reduced from nearly 90% to less than 65%, and likely less than 60%, by this single remedy.
# 17.6. Harms and Benefits from Canceling the Apple - Google Search Deal
What harms and benefits does the deal create for consumers?
Pros:
Funds Safari/WebKit
Increases Apple’s revenue
Cons:
Cements Google’s dominance in search
Disincentivizes Apple from selling the search engine default to another party
Significantly reduces and may eliminate Google’s incentive to compete in the browser market on iOS and macOS
Disincentivizes Apple from competing in the Search Engine Market
Apple reinvests little of the money it receives from this deal back into Safari/WebKit. Neither Google nor Apple supplied concrete evidence to the contrary during the case. We estimate that as little as 3% could be reinvested by Apple back into Safari/WebKit:
The ISA does not require Apple to use revenue share payments to improve Safari, and Google has presented no evidence that Apple does so. Mozilla likely does use its payments from Google to upgrade Firefox (given that those payments make up 80% of its operating budget), but Firefox’s contribution to the overall search market is so small that the additional output it produces, at most, marginal procompetitive benefits. Memorandum Opinion - United States of America vs Google LLC (emphasis added)
Given this, could Apple secure enough funds from another search engine, to fund Safari/WebKit?
While this figure is from 10 years ago, given that Bing's search quality has considerably improved since then (as noted multiple times throughout the court documents), it seems likely that both its retention and revenue per given volume of traffic would now be higher. It is not clear what percentage revenue share would be agreed between Apple and another search engine such as Bing. In the short term catapulting Bing to 30% or more market share would have significant value so it is likely Apple would still have considerable bargaining power, even without Google as a bidder. A reasonable estimate might be in the order of $1 to $1.5 billion per year.
While $1.5 billion annually is significantly less than $20 billion annually, accepting such a sum will be in Apple's best financial interest.
Given that we believe Apple's expenditure into Safari/WebKit (estimated by us at $300-400 million annually) is significantly lower than Google’s expenditure into Blink/Chromium (estimated at between $1 and $2 billion annually), it is clear that this is more than enough to cover Apple's browser expenses. Apple also has significant external motivations to continue to fund Safari to at least its current level of expenditure, as Safari is a key part of Apple's branding and would be revenue positive. With iOS being opened up to third-party browser competition in the EU, UK, Australia, Japan (and possibly even the United States), pressure to invest is likely to increase, not decrease.
That is, it seems likely that canceling the Apple-Google deal by itself will not significantly reduce Apple's investment in either Safari or WebKit, nor have Apple submitted any evidence suggesting that it would.
But, let's assume that cutting this deal would have severe repercussions to Safari’s financing. Even in that case, the most the DOJ should grant Apple, is that Google is only allowed to purchase 5% of the default on iOS and macOS, and there should be a clause that 95%+ of those funds must be spent on Safari and WebKit. Such a remedy would actually increase Safari’s budget.
Apple’s already massive profits and cash reserves suggest that additional revenue from Google has limited benefits for consumers. The company operates with high margins and does not face sufficient competitive pressure to lower prices or significantly reinvest in ways that directly benefit users. Unlike companies in highly competitive markets that might use extra funds to reduce costs or enhance services, Apple is more likely to allocate this revenue toward maintaining its premium pricing, stock buybacks, or ecosystem control rather than passing savings or improvements to consumers. Moreover, its investment priorities are dictated by long-term strategic goals rather than immediate financial constraints, meaning that an increased budget does not necessarily accelerate consumer-friendly innovation beyond what Apple would have already pursued.
There doesn’t appear to be a case that this additional revenue offers any benefits to consumers, nor have Apple submitted any evidence suggesting that.
# 17.6.3. The Benefits of Canceling the Apple-Google Search Deal
Canceling the Apple-Google search deal would significantly weaken Google’s dominance, reducing its market share from nearly 90% to likely below 60%. Without Google's payments, Apple would have a strong financial incentive to sell its default search placement to another provider. Currently, Google’s payments to Apple effectively lock out rivals from iOS, making it very difficult for them to gain meaningful traction in the search market.
Unlike Google's other search deals, where most of the revenue funds browser and platform development, Apple appears to pocket nearly all of it (likely more than 95%). These other deals have allowed and maintained browsers such as Firefox to continue to compete and exist.
Additionally, removing Google’s financial incentive to remain the default search provider on Apple devices would force it to compete more aggressively in the browser market. Google currently has little reason to improve its browser offerings on iOS and macOS because it already benefits from being Safari’s default search engine. This is especially true on iOS where it pays Apple the same revenue split for Chrome as Safari. If the deal were canceled, Google might be compelled to fight harder for the right to compete on all of Apple’s platforms, improving browser competition and leading to better user experiences. A stronger Chrome competitor on iOS and macOS would put strong pressure on Safari to invest more, particularly once third-party browsers are allowed to ship their real browsers with their own engines on iOS. This will increase features and reduce bugs for browsers on iOS.
Finally, Apple itself might be incentivized to develop its own search engine or enter the search market in a more meaningful way. As long as Google continues paying Apple billions of dollars, Apple has little reason to challenge the status quo. In the court documents it is revealed that Apple has explored creating a search engine but decided against it due to it being financially risky relative to the sure bet of Google's money.
Yes, the DOJ should seek to cancel this deal and prohibit all future such deals with Apple for the next 10 years.
The deal offers very limited benefit, suppresses rather than promotes competition in the adjacent browser market, is substantial in scale, and appears poised to be highly effective in maintaining Google's dominance. Canceling based on available data would single-handedly reduce Google’s United States market share to below 60%.
# 17.8. What does this mean for the DOJs other remedies?
Given how effective this single remedy is likely to be, some of the DOJ’s other remedies that seem likely to cause significant harm to the adjacent market may not be warranted.
In particular, the total ban on search engine revenue sharing deals with smaller browsers and the divestment of Chrome (and exit of Google from the browser market). In this context these remedies should either be removed or adjusted to limit the harm to the web platform.
# 18. Should the Google Android Placement and Bundling Deals be Banned?
Google operates a global web of licensing agreements that govern the distribution of its popular applications, most notably the Google Play Store. These agreements are structured around a suite of proprietary apps known as Google Mobile Services (GMS).
Under MADA device manufacturers (OEMs) must pre-install all of Google's major applications if they want any of them. In court documents, OEMs available in the US consider Google Play essential.
Under the MADA, partner OEMs must preload all 11 GMS applications onto a new device, including the Google Search Widget, Chrome, YouTube, Gmail, Google Maps, and Google Drive, among others. Six of these applications, including the Google Search application and Chrome (which both default to Google), cannot be deleted by the user. Without a MADA, an OEM cannot distribute any one of these GMS applications. Memorandum Opinion - United States of America vs Google LLC
Additionally the search widget and Chrome must be prominently placed:
Signatories of the MADA agree to preload and place the Widget on the default home screen of the device. Signatories also receive Chrome, and generally speaking, they agree to place Chrome in the Google applications folder, which appears on the default home screen. The MADA requires the Google applications folder to be on the default home screen, but it does not require its placement on the dock, sometimes known as the 'hotseat' Memorandum Opinion - United States of America vs Google LLC
On top of MADA Google has various revenue sharing and placement payments contingent on further conditions:
A revenue share agreement, or RSA, is a separate agreement from the MADA. Each RSA generally follows a tiered structure, in which a carrier’s or OEM’s payment is tied to the degree of device exclusivity. Memorandum Opinion - United States of America vs Google LLC
The Samsung RSA also provides for “Enhanced Devices,” which requires additional placements beyond the MADA, such as placing Chrome as the default browser (over S Browser) in the hotseat, or dock.
Memorandum Opinion - United States of America vs Google LLC
In 2018, the EU Commission fined Google €4.34 billion for breaching EU antitrust rules. In particular Google had required manufacturers to pre-install the Google Search app and Chrome, as a condition for licensing the Play Store and made payments to certain large manufacturers and mobile network operators on condition that they exclusively pre-installed the Google Search app on their devices.
Google subsequently updated and created a new agreement for Europe called the European Mobile Application Distribution Agreement (EMADA). Under this new agreement, Google Search and Chrome would not be force bundled with the rest of GMS. However, licensing Google Search and Chrome is conditional on a manufacturer entering the EMADA.
UK - CMA - Mobile Ecosystems Investigation
However despite the more coercive tactic of bundling Google Search and Chrome with the other GMS applications being removed under EMADA, Google has managed to largely retain its position via placement and revenue sharing deals.
Overall, through the PAs and RSAs in relation to Chrome, Google has considerable influence over the choice architecture on Android devices and this leads to Chrome being pre-installed, prominently placed and, in some cases, set as default on Android devices in factory settings
UK Mobile Browsers and Cloud Gaming MIR
Google’s revenue sharing arrangements with smaller browser vendors serve a fundamentally different purpose than its deals with OEMs. While Firefox, for example, accounts for less than 1.6% of Google’s total mobile RSA payouts, and less than 1.15% of the US search market, its contribution to the Web ecosystem is far greater than those figures. Firefox helps sustain an independent browser engine and heavily engages in web standards which deliver outsized value to consumers and to the health of the open web. Thus the relative benefit is significantly greater than the relative harm of specifically those deals.
Google’s OEM agreements represent a double bind that locks rivals out of the ecosystem entirely. First, Chrome is preinstalled, often as the default and non-removable browser. Second, Google’s dominant position and extensive suite of apps mean that few OEMs would risk rejecting Google Play just to preinstall an alternative browser.
The result is a market where almost no manufacturer installs more than two browsers, and virtually none would sacrifice Play Store access to promote a competitor, even Microsoft felt obligated to accept such a deal. So even though revenue sharing agreements are not inherently problematic, the OEM variant is fundamentally different in nature and effect.
These deals are not just payments, they are interlocking control mechanisms that combine preinstallation, default status, placement mandates, and strong financial incentives.
We support the DOJ’s remedies requiring the unbundling of Google Search and Chrome from the rest of the GMS suite, following the approach taken by the European Union.
Google is not allowed to condition access to the Play Store or any other Google product on a distribution agreement for a GSE, Search Access Point, or Choice Screen. Similarly they may not condition it on not distributing a Competitor’s product or service.
DOJ - Remedies
The question of whether revenue sharing agreements should be allowed is more nuanced. In the EU, even after bundling was formally ended, Google was still able to maintain the default placement and pre-installation of Google Search and Chrome through revenue sharing arrangements with OEMs.
Although potentially these OEM revenue sharing agreements may reduce the cost of handsets, there is no clear evidence that ending them would cause significant or lasting harm to the broader Android ecosystem.For instance, ending such deals would not bankrupt Samsung nor plunge investment in the Android ecosystem.
Therefore, at a minimum, the DOJ should consider limiting Google’s ability to enter into such revenue sharing and placement agreements to no more than 50% of Android devices. And in the absence of compelling evidence that these deals serve the public interest, the DOJ is correct to attempt to prohibit them entirely.
# 19. Should all Search Engine Default Placement Deals be Banned?
Revenue-sharing deals are not inherently anti-competitive.
For instance, it is common for smartphone manufacturers to invest in advertising to boost their sales. Since all major players in the industry have the capability to engage in this kind of marketing, it is generally seen as healthy competition rather than a problem.
However, consider a scenario where one manufacturer becomes so dominant that it can outbid all others for nearly every advertising slot. If that dominance helps it capture nearly 90% of the smartphone market, it would be reasonable to impose restrictions on that company’s ability to monopolize advertising channels, especially if that strategy locks out competitors and entrenches its market position.
This is precisely the concern at the heart of the DOJ’s case against Google.
The DOJ argues, convincingly, that Google uses its revenue-sharing agreements to effectively shut out rival search engines from critical distribution channels, such as default placement on browsers and devices. This creates a self-reinforcing loop: Google's market dominance allows it to extract more revenue per search, which in turn gives it the financial power to secure exclusive or near-exclusive deals, further entrenching its position.
These kinds of deals wouldn't be problematic if either of the following were true:
Google's market share in general search was substantially lower at below 50–60%.
Google wasn't able to secure the vast majority of default search placements, as measured by search volume.
If the DOJ succeeds in its case and remedies are implemented wisely, there is real potential for long-term benefit to the broader browser and web ecosystem. In a competitive market where four or five search engines hold meaningful market share and bid aggressively for default placement, browser vendors could see significantly increased revenue. This, in turn, could drive more investment into the web platform as a whole.
Unfortunately, the current situation is far from competitive.
Google controls 89.2% of the general search market, and its deal with Apple alone covers over 50% of all U.S. search volume. Due to its scale, Google can outbid any competitor.
As Apple executive Eddy Cue stated, even if Microsoft offered Apple 100% of Bing’s revenue, it still wouldn't be enough to compete with Google’s offer.
So should all search default placement deals be banned?
Clearly not. There’s nothing wrong with smaller search engines like Bing, DuckDuckGo, or Ecosia paying for default placement, these deals help fund browser development and support competition.
That leaves us to three distinct types of deals:
The Apple-Google deal:
This arrangement is not justifiable in its current form. It covers over half of U.S. search traffic, yet Apple reinvests only a tiny fraction (estimated by us at below 2%) into Safari or WebKit. This deal should either be terminated or, at a minimum, capped at 50% of Apple’s defaults. In addition, Apple should be required to reinvest the majority (at least 95%) of the proceeds into Safari, WebKit, and the broader web platform. This would ensure that the deal’s continuation is directly tied to its public benefit.
Google’s deals with smaller browser vendors:
These should be allowed to continue, as they help support browser diversity and competition in the adjacent browser market. These deals are small totaling less than 1.9% of Google’s revenue share payments. In the event that one of these browsers becomes too large then the 50% cap should apply. This should be done in a manner that does not disincentivize smaller browsers from gaining market share, such as the one discussed here.
Chrome’s default search engine behavior:
Chrome's default to Google is effectively an implicit internal deal. Given Google’s substantial investment in Chromium and the web platform, it is reasonable to allow Chrome to default to Google, but only in part. Chrome should be required to allocate at least 50% of its default search traffic through competitive auction to other search providers. Moreover, the majority (at least 95%) of all proceeds from these auctions should be obligated to be reinvested into Chrome and the web platform.
While we understand the DOJ’s intent behind its proposed remedies, we are deeply concerned that some measures could have unintended consequences, consolidating market power in browsers and the web platform even further into the hands of a few dominant players while plummeting investment in critical web technologies. This would reinforce the existing Google-Apple duopoly in mobile app markets, a problem that is already the subject of another DOJ complaint.
Ideal remedies would:
Avoid bankrupting smaller browsers.
Not cause the elimination of Gecko, one of the world’s three remaining browser engines.
Preserve funding for the Web platform, which requires substantial investment to sustain.
Not prevent the web from effectively competing against closed platforms.
The web plays a critical economic role in both the U.S. and global markets, requiring continuous and substantial investment to sustain its growth and competitiveness.
For the past two decades, search default deals have been the primary funding mechanism for web platform development. While alternative models potentially exist, the challenge lies in the sheer scale of funding required, which is extraordinarily large.
Without a clear, sustainable and substantial funding model, we risk a tragedy of the commons: a situation where a vital resource, the web platform, contributes trillions to the global economy, and serves as critical infrastructure powering our public and private services but lacks enough entities willing to adequately fund its development and maintenance.
To be clear, no one in the industry wants the web platform’s primary funding source to be Google Search. However, it must be funded somehow. The real issue is not the existence of search default deals, but rather that Google monopolizes 100% of these agreements, preventing other search engines from scaling to a level where they can meaningfully compete.
A viable solution would be to guarantee other search engines access to at least half of the available search default placements. This could go a long way toward addressing the underlying competition problem without destabilizing web platform funding.
Any remedies must not further shrink the number of players in the browser market.
The loss of Mozilla and the Gecko browser engine would be a major setback, eliminating one of the world's three browser engines and an important voice in web standards.
Smaller browsers represent our best opportunity for a more competitive future in the browser market. If solutions are not carefully considered, they could inadvertently cause significant browser market consolidation. This must not be allowed to happen.
# 21. Challenges for those Arguing for Chrome Divestment
Some proponents of a Chrome divestiture argue that even if browser funding were significantly reduced, the web would still survive. But that’s an unhelpfully low bar for assessing harm. The question isn’t whether the web continues to exist in some form, it will, but what condition it will be in, and what we risk losing in the process.
In many of these arguments, there is an implicit assumption that the current level of investment in Chromium is excessive, and that the open web could function just as well with far less. The analysis often suggests that since smaller engines like Gecko exist on a leaner budget, Chromium could operate on a similar scale without much consequence. But this overlooks critical realities: nearly every industry insider agrees that Firefox is under-funded, and there's no clear evidence that cutting Chromium’s budget down to similar levels would have anything but a negative effect. The fact that such a drastic cut is being treated as inconsequential is deeply concerning.
Worse still, the potential side effects of these remedies are often considered in isolation, when in fact they are deeply interconnected. In this case, a Chrome divestment is coupled with an outright ban on revenue-sharing agreements, the very deals that currently fund much of the browser ecosystem. Evaluating these measures separately ignores their combined impact. A newly divested Chrome/Chromium entity would be left without a reliable or sufficiently large funding source to sustain its current level of development and maintenance. At the same time, independent browsers would lose critical revenue streams that enable them to compete. Taken together, the impact on the broader browser ecosystem, and on the web platform itself, is likely to be severe and deeply damaging.
The web will suffer should Google be forced to sell Chrome. I think a fair assumption that overall investment and contribution to the open web will take a dive.
Chris Coyer - CSS Tricks
Research and development is one of the most costly and complex aspects of advancing the web platform. It’s a long, iterative process involving experimentation, incubation, and active participation in standards bodies. Many ideas are tested and ultimately abandoned, but this process is essential, it’s how virtually every new feature and improvement over the past decade has come to life.
Today, Google is the primary funder of web platform R&D. A significant drop in funding from Google would almost certainly lead to a disproportionate decline in this kind of foundational work. While this wouldn't affect existing features and functionality, it would severely slow the pace of innovation. Given how heavily the industry has relied on Google to carry this load, it is highly uncertain that any other party, or even a coalition of them, would step in to fill the gap.
It is worth stating clearly: browsers and the web will not vanish. But that’s not the metric by which these remedies should be judged. The more important questions are:
How much will these remedies reduce overall funding for the web platform?
While exact figures are difficult to pin down, we can make a reasonable estimate of current investment in the web platform. Google likely contributes around $1 billion annually, with Microsoft investing approximately $100 million, Mozilla about $200 million, and Apple in the range of $150 to $200 million. If Chrome is left without a meaningful funding source, Mozilla is bankrupted, Microsoft is forced to shift resources from feature development to maintenance, competition in the browser space collapses, and confidence in the web as a platform erodes, the consequences would be severe.
In such a scenario, Chrome’s investment could shrink to a minimal maintenance budget, Mozilla’s contributions would disappear almost entirely (though not immediately, due to reserves), and Apple’s already limited investment could decline further in the absence of meaningful browser competition. Altogether, this could amount to a loss of up to $1 billion in annual investment, an estimated 70 percent drop in funding for the web platform.
What will be the cost to businesses in terms of more bugs, lower stability, and a major slowdown in feature development?
There will be a sharp rise in bugs, delays in critical fixes, and a noticeable slowdown in innovation. Businesses that rely on the web will face higher engineering costs and reduced confidence in the consistency and reliability of the platform.
Quantifying this in dollar terms is almost certainly impossible but given the digital ecosystem is worth trillions annually in the US alone and the degree to which web technologies are used, the figure is almost certainly in the billions annually.
Will this lead to even more market consolidation, as only tech giants with unrelated revenue streams can afford to operate browsers without a viable business model?
Yes, consolidation will increase. Although not all smaller vendors will disappear immediately, as they can remain competitive by relying on smaller teams focused on browser features rather than platform development, However these companies will suffer significantly from a plunge in Chromium funding. Mozilla, an independent non-profit, will likely go bankrupt if it loses its primary funding source. This would push the web into even fewer hands. Only the largest tech companies, like Apple and Microsoft, will have the resources to sustain full-scale browser and engine development, further concentrating control over the future of the web.
Could this halt the deployment of non-WebKit browsers on iOS, due to funding cuts that weaken both Chromium and Gecko?
Yes. Without sufficient funding, both Gecko and Chromium will be unable to sustain the substantial engineering effort required to port their engines to iOS. Apple’s long-standing platform restrictions already make this an unusually complex and costly undertaking. If Mozilla loses its primary source of funding, it will almost certainly be unable to port Gecko. Likewise, a divested Chrome entity may lack the resources, strategic priorities, or incentives to continue the Chromium iOS port. Other browser vendors depend on these core engine ports to support their own efforts. Without them, the prospect of future engine-level competition, and, more broadly, any realistic chance of meaningful browser competition on iOS, will never materialize.
Will vendors like Microsoft be forced to pause new features and focus solely on maintenance, due to a lack of upstream fixes from Google?
Yes. Microsoft relies heavily on Google’s upstream contributions to Chromium. If those slow down, Microsoft will be forced to allocate resources to stability and maintenance just to preserve existing functionality, leaving little room for innovation.
What will be the knock-on effect on the many non-browser businesses that depend on technologies developed and maintained within Chromium?
They will face increased costs, slower progress, and growing technical debt. Frameworks like Electron, tools built on headless Chrome, and countless development workflows depend on a stable, well-funded Chromium. Those ecosystems will suffer directly.
If browsers stagnate, will users and developers shift further toward native apps, strengthening Apple’s and Google’s control over mobile software distribution?
Yes, this shift will accelerate. As browser capabilities fall behind, developers will increasingly turn to native platforms for performance, deeper API access, and a more consistent user experience. Stability is also critical: if the web platform becomes underfunded, or unreliable, developers will be far less willing to build and scale businesses on top of it. The open web depends not just on feature parity, but on a predictable, well maintained foundation.
This ecosystem has already been severely undermined by the long standing lack of engine level competition on iOS. Critical features on iOS such as install prompts have still not been implemented, and others like push notifications were delayed for years and remain incomplete and inconsistent. These missing capabilities make it significantly harder to build high quality web apps that can rival native ones. Without strong, sustained investment and broad platform support, the web risks falling further behind, giving up even more ground to Apple’s and Google’s tightly controlled native ecosystems.
# 22. Challenges for those Arguing for Banning Search Engine Deals with Small Browsers
Mozilla agrees that we need to improve search competition, but the DOJ’s proposed remedies unnecessarily risk harming browser competition instead.
[...]
Punishing independent browsers will not solve the problem. Judge Mehta found that independent browsers account for just 1.15% of U.S. search queries. This means that cutting off our access to search deals won’t fix the issue of search dominance—not by a landslide. Instead, it hurts browser competition.
[...]
Mozilla has played an outsized role in keeping the web open, private and advocating for choice. [...] Shaping the future of web standards—maintaining our own browser engine, Gecko, gives us a voice in defining how the web works and making decisions that are in support of people, not the bottom-line. [...] Ensuring interoperability—we fight for a web accessible to all—where anyone can create, access, and share content seamlessly, regardless of the devices or web services they use—not locked into a few ecosystems. [...] ‘This isn’t something we do because it’s profitable or easy,’ said Surman. ‘We do it because it matters. The DOJ’s proposal doesn’t just miss the mark, it risks handing even more power to dominant industry players like Google or Apple, not less.’
Mozilla
While it is entirely expected that Mozilla would advocate for its own survival, in this case, its arguments are clear, well reasoned, and compelling.
In the court proceedings, Mozilla’s contribution to the web was largely dismissed based on its 2.6% market share, which was framed as too small to be meaningful. However, as Mozilla rightly pointed out and as the court itself acknowledged, independent browsers collectively account for just 1.15% of search queries in the United States.
So which is it? If 2.6% is considered insignificant, then 1.15% must be even more so. A consistent standard must be applied. The real question is whether the potential harm of allowing Google to pay for default placement in smaller browsers outweighs the very real benefit of continued funding for vendors like Mozilla.
Like Mozilla, we believe that its value to the web ecosystem is far greater than its market share alone might suggest. As an independent nonprofit, Mozilla has been a consistent and influential voice in web standards discussions and has played a key role in advancing openness, privacy, and user choice. Losing that voice would leave the ecosystem less diverse, less accountable, and more heavily shaped by the interests of dominant tech companies.
It is true that Mozilla’s management has made missteps, as any long running organization might. However, it is equally true that anti-competitive practices by both Apple and Google, have made it nearly impossible for Mozilla to gain meaningful share in the mobile market. This has limited its ability to generate revenue and denied it the room to recover from mistakes that larger companies can more easily absorb.
Smaller browser vendors should be exempt from any blanket ban on Google revenue sharing deals. However, to prevent abuse and ensure fair competition, Google’s ability to enter into such deals should be capped based on the total percentage of the market they cover. This would guard against potential gaming of the system and account for scenarios where one or more smaller browsers rapidly gain significant market share.
For those advocating a total ban on all such deals, the burden is on them to present a detailed case. They must explain why the potential harm of allowing Google to gain up to an additional 1.15% of search share, particularly in the context of broader remedies that would reduce Google’s overall market share below 50%, outweighs the clear and immediate harm of losing Mozilla from the browser market, stripping smaller vendors of critical funding, and accelerating the consolidation of browser development in the hands of a few dominant tech companies.
Given these concerns, what is the best path forward? How can the DOJ succeed in its core objective: breaking Google’s search monopoly, without inflicting significant damage on the adjacent markets of browsers and the web platform?
One approach is to drop certain remedies entirely, such as the forced divestment of Chrome and the ban on search engine revenue-sharing deals. However, it remains essential that the DOJ is successful in preventing Google's anti-competitive conduct and that any deals that remain both do not contribute to a monopoly by Google and serve the public good via investment in the web platform. It is worth exploring targeted remedies that reduce Google's influence on the search market while still ensuring that both smaller browsers and the web platform remain sustainably funded.
With that in mind, there are several alternative remedies that are less severe but still effective, without harming the web platform. It is important to note that the vast majority of the DOJ’s proposed remedies (approximately 45 in total) can remain unchanged and proceed as planned.
Other possible remedies include:
Cap default search deals for browsers at 50%.
Allow exceptions for small browsers.
Require reinvestment of a percentage of search deal revenue into browsers and the web platform.
Transfer Chrome to a non-profit.
Allow the sale of Chrome but attach minimum platform investment conditions.
Move Chrome into a separate legal entity within Alphabet, structurally independent from Google LLC.
Cap Chrome’s search defaults to Google at 50%.
Require that Google’s default search deals with browsers are public and have a single revenue share rate with all vendors.
Ensure that any structural remedies do not prevent Google from continuing to invest in the open-source Chromium project.
This remedy proposes capping the share of default search placements that Google can pay for at 50% of that browser user base.
While safeguards would be necessary to prevent manipulation by Google, the core concept is straightforward.
The key advantage is that it preserves funding for the web platform while opening significant opportunities for competing search engines. As these competitors scale through feedback loops, this approach could foster a competitive search market without jeopardizing continued investment in the web platform.
A major concern with an outright ban on search deals is that it could leave the web platform severely underfunded for years during a market transition, causing significant harm.
The core issue raised by the court is that Google has been so successful in securing these deals that it has completely blocked competitors from entering the market and gaining the necessary scale to effectively compete and outbid Google for search placements.
This remedy forces Google to relinquish at least 50% of the market for search deals, breaking its exclusive control while still allowing it to significantly contribute to web platform funding.
Even if a 50% cap on Google’s ability to pay for default search placement were implemented, we believe it’s essential to include a limited carve-out for smaller browsers.
We propose that smaller browsers, such as Mozilla, be allowed to sell 100% of their default search placement to Google. For these vendors, losing nearly half of their core revenue would likely be catastrophic.
As Judge Mehta noted in United States v. Google LLC:
THE COURT: So I mean, it seems to me Mozilla, in some sense, would have a more compelling argument than you because it's not like Apple is going to go out of business if I don't -- you know, if you can no longer get revenue share.
You've got other sources of revenue; Mozilla hardly has any.
UNITED STATES OF AMERICA vs GOOGLE LLC
This carve-out is justified because, while these smaller browsers account for only a minor share of search traffic, they play a vital role in sustaining browser competition and in governing the open web. A healthy browser market depends on preserving these potential future challengers.
Two potential concerns might be raised:
Growth scenario: A smaller browser, such as Firefox, Opera, or Samsung Internet, could significantly grow in market share over 5–10 years, reaching 20–40% of the market. While such growth is highly desirable from a competition standpoint, it could become problematic if Google continued paying for 100% of the default search placement at that scale.
Aggregate deals scenario: Google might strike numerous deals with smaller browsers, which in aggregate could exceed the 50% market share cap.
Both scenarios are solvable and, in our view, unlikely.
For the first case, the 50% cap could be applied progressively as a browser grows. The key is to avoid any disincentive for smaller browsers to expand their market share. Their revenue should increase as their user base grows, not decrease due to a hard threshold. This can be achieved with a tapered formula that gradually reduces the allowable default share Google can purchase, while ensuring that increased market share always results in increased revenue.
For example, the allowed default sale percentage could follow this structure:
If 0% ≤ X ≤ 5%, then 100% of the default can be sold to Google
If 5% < X ≤ 20%, then allowed percentage = 5% + ((X - 5%) × 33.5%) / X
If X > 20%, then capped at 50%
Where X is the browser's share of the total browser market.
This would result in a smooth tapering from 100% to 50% as market share increases from 5% to 20% which would look like the above.
For the second concern, Google’s ability to pursue aggregate deals could be limited by enforcing a strict overall cap, e.g., prohibiting it from purchasing more than 50% of total browser defaults. This should be coupled with a ban on bundling or coercive agreements through arrangements like MADA or OEM partnerships that artificially steer distribution.
There are, of course, numerous implementation details to be considered. But the core idea is straightforward: it’s possible to design clear, practical mechanisms that protect the viability of smaller browsers without undermining the broader goals of the DOJ’s remedies.
# 23.3. Require Reinvestment of Search Revenue into Browsers and the Web Platform
This remedy builds upon the 50% cap proposal by ensuring that search deal payments directly support the browser ecosystem and the web platform.
If the court determines that these payments are harmful yet necessary for funding the web platform, it would be logical to impose conditions ensuring their use for public benefit. Under this approach, 90% of search revenue received from such deals with Google must be reinvested into browser development and the web platform, with at least 50% of that total specifically allocated to the web platform.
This would help guarantee that these funds serve a long-term public interest, rather than being diverted for other purposes.
One intriguing option is to spin off Chrome into a non-profit organization dedicated to advancing the open web.
For this approach to succeed, several key conditions must be met:
A substantial financial war chest to sustain operations for 3-4 years.
The transfer of all relevant personnel, currently spread across various Google divisions and offices.
A reliable and significant source of ongoing funding.
A mission statement focused on advancing the web and the web platform.
If this new entity were able to secure a 50% search deal with Google, it could likely cover its required budget and remain financially viable.
However, the DOJ has not proposed this remedy, and it remains unclear whether such an approach would be legally feasible under U.S. law.
# 23.5. Allow Chrome’s Sale with Minimum Platform Investment Conditions
The concerns surrounding a potential forced sale of Chrome could be entirely alleviated if a buyer were found who was both willing and financially capable of funding Chromium at a comparable level to Google’s current investment.
If such a buyer emerged, the benefits of divestment would outweigh the now-mitigated risks. To ensure this, the buyer should make a legally binding commitment to invest in Chromium at a level equivalent to Google’s current annual funding for at least five years. While there is some risk that funding could decline after that period, there is no guarantee that Google itself will continue funding Chromium indefinitely. Ideally, the buyer should be an entity with a strong financial interest in the long-term success of the web.
Notably, if the new owner were able to sell 50% of its search default placement to Google, this would easily cover all ongoing development, maintenance, and web platform research costs while still allowing them to generate a healthy profit from other ventures, without contributing to majority market share for Google.
We appreciate that the DOJ is taking these concerns seriously and acknowledging the importance of a viable future for Chromium and the open web in its Revised Final Judgment Proposal, which now requires an evaluation of the buyer’s business and investment plans, including those for the open-source Chromium project. The proposal states:
The evaluation of any potential buyer shall include the potential buyer’s proposed business and investment plans (including those for open-source project Chromium), the United States’ evaluation, at its sole discretion, of any potential risks to national security, the potential buyer’s plans for sharing and protecting user data included in the acquisition, and any other issues a potential buyer may present.
Plaintiffs’ Revised Proposed Final Judgment (emphasis added)
However, we believe it is crucial that any commitments to continued funding be legally binding and that preventing a drastic decline in Chromium’s funding should be a strict condition of sale.
One compelling alternative to a full divestiture is to restructure Chrome as a separate legal entity under Alphabet, independent from Google LLC.
Currently, Chrome operates within Google LLC, Alphabet’s primary operating subsidiary. Under this remedy, Google would not need to sell Chrome outright but would instead be required to transfer it into a distinct corporate entity with its own governance, board of directors, financial independence, and operational autonomy.
This new Chrome entity would be permitted to sell no more than 50% of its default search placements to Google, with the remaining 50% auctioned off to competing search engines for at least 10 years. This structure would ensure stable funding to maintain Chrome’s current staffing levels and Chromium investment, while removing any contribution to a Google monopoly.
Additional requirements would include:
90% reinvestment of Google search revenue into browser and platform development, split evenly between Chrome and the web platform.
A legally binding commitment to keep Chromium freely licensed and open-source.
The removal of Google branding and integration from Chrome, and the adoption of a distinct privacy policy independent of Google or other Alphabet subsidiaries.
Full operational autonomy from Google, with strict firewalls and oversight.
Crucially, this approach avoids the debt burden, likely in the range of $15–20 billion, that would come with an external sale. The restructured Chrome entity would remain profitable, well-resourced, and competitively neutral, allowing it to continue investing heavily in the web platform.
While this may seem like a subtle structural shift, it preserves web platform investment while preventing Google from monopolizing default search placement in the world's most widely used browser.
# 23.7. Cap Chrome’s Search Defaults to Google at 50%
As outlined in the previous section, the DOJ should consider capping Chrome’s default search allocation to Google at 50% while requiring the remaining 50% to be sold to other search engines through an auction-style system.
While search choice screens do offer some important benefits, they typically only shift a few percentage points of market share, which would be far less impactful than directly reallocating 50% of the default search market to competing providers.
This remedy will be even more effective if Chrome is removed from Google’s corporate structure and established as a standalone entity under Alphabet, ensuring stronger operational independence and fully separate financial governance.
# 23.8. Transparency and Uniform Revenue Share Requirement
If the DOJ or the court chooses to permit Google to continue entering into default search engine agreements with browser vendors, the only defensible justification in the public interest is to support ongoing investment in smaller browsers and in the web platform more broadly. Without this justification, there would be a strong case for prohibiting Google from making such deals entirely.
If these agreements are allowed to continue, it is essential that they be made fully transparent to both the public and relevant third-party oversight bodies. Transparency exerts consistent pressure on dominant firms, helping to curb the use of opaque, preferential deals that distort market dynamics and limit fair competition.
At present, larger entities such as Apple possess significantly more bargaining power than smaller players like Mozilla. This disparity is evident in the scale of their respective deals with Google, which are far out of proportion to their actual browser market shares. For example, Safari holds a 17.6% share of the browser market, while Firefox accounts for 2.5%. Yet Apple reportedly receives around $20 billion per year from Google for default search placement, while Mozilla receives only $400 million. Even using a conservative estimate that Firefox users are only half as valuable to Google as Safari users (this is possible due to the on-average higher income and spending of iOS users), Mozilla should still be receiving approximately $1.4 billion annually if the revenue share rate were equal. That figure is more than three times Mozilla’s current deal.
This imbalance highlights the need for the DOJ to require Google to apply a single, uniform revenue share rate across all browser vendors. This approach would effectively align the rate with the terms secured by the most powerful party, most likely Apple, and would help establish competitive parity. For smaller browsers such as Mozilla, this remedy could double or even triple their current revenue, providing much-needed funding for browser development and web platform innovation.
Another option is to set the revenue share rate for deals with smaller browsers to match the rate Google previously agreed upon with Apple. The rationale is that this represents a fair market rate, and that Google had been leveraging its dominant position to negotiate disproportionately lower payments with smaller browser vendors.
Economists widely recognize transparency and uniform pricing as tools to curb price discrimination in gatekeeper-dominated markets. Google's current ability to make individualized, confidential agreements allows it to favor certain partners and withhold critical resources from potential competitors.
Requiring Google to implement transparent, standardized revenue-sharing terms for all browser vendors would be a narrowly focused behavioral remedy. It directly addresses Google's currently entrenched position in the default search market while helping to sustain, and enhance, competition across the browser ecosystem.
# 23.9. Guarantee that Google Is Not Barred from Investing in Chromium
This remedy serves as a critical last resort. If the DOJ proceeds with its plan to divest Chrome, then in order to preserve web platform investment, the DOJ and the court must ensure that Google is not, either explicitly or implicitly, prohibited from continuing to invest in Chromium. The final remedy must clearly state that Google is permitted, and ideally encouraged, to contribute to Chromium, recognizing that Chromium functions as both a standalone browser and the foundation for many others.
This clarity is essential. Even under the most pessimistic scenarios, Google would still likely invest around $100 million annually in the web platform, primarily to ensure that core services like Search, YouTube, Google Docs, and Gmail continue to function smoothly and securely across browsers. If Google were barred from supporting Chromium, that remaining investment, still a significant portion of total global web platform funding, could drop to zero.
Regardless of the outcome of divestiture or other structural remedies, it is vital that the court preserve Google's ability to contribute to the foundational technologies of the web.
In the previous section, we explored a number of possibilities, but some of these remedies conflict with each other. So what does an ideal remedy package look like?
This is difficult to determine with certainty. What both the DOJ and the broader web ecosystem need is a carefully balanced set of remedies that prevents Google from monopolizing the search market, reduces its market share to below 60 percent, and does so without devastating investment in the web platform or undermining competition in the browser market.
With this in mind, and considering the evidence presented in this document, we believe that the following remedies package offers the best chance of achieving these goals while remaining legally viable and practically enforceable.
# 24.1.1. Preserve and Implement Majority of the DOJ's Existing Remedies
The vast majority of the DOJ’s proposed remedies are both appropriate and necessary, and should be fully implemented.
In particular, the search engine syndication remedies, which allow competing search engines to replicate Google’s search results, are especially important. These remedies will strengthen the ability of alternative search engines to retain users gained through their own default placement deals. In turn, this will help these competitors generate the revenue needed to sustain and grow their operations. Combined with improved access to data through other remedies, this funding will enable them to enhance the long-term quality and competitiveness of their own search results.
# 24.1.2. Terminate the Apple-Google Search Agreement
Unlike other browser vendors, Apple reinvests only a small fraction of its search deal revenue into WebKit and Safari. Moreover, the sheer scale of this deal, representing over 50% of U.S. Google search traffic, means that any justification for retaining it, even in part, would need to be exceptionally compelling.
The strongest argument in favor of keeping the agreement is that it helps fund Apple’s browser and engine development, which we estimate at approximately $300 million per year. However, Apple does not need to receive $20 billion annually from Google to cover that investment.
Court documents reveal that Microsoft offered $4 billion per year for this placement back in 2015. While future offers might be significantly lower in the absence of a bidding war with Google, the value of default placement on Apple’s platforms is so high that a non-Google search engine would almost certainly be willing to pay between $500 million and $1 billion per year for the opportunity.
Combined with increasing global regulatory pressure on the browser engine ban on iOS, as well as our proposed remedies that promote broader browser competition and platform investment, and given their other many revenue streams and the importance of maintaining their brand recognition, Apple will have both the financial means and significant pressure to increase its investment in Safari and WebKit, even without Google’s payments.
For these reasons, we strongly support the DOJ’s position and advocate for the complete cancellation and long-term prohibition of all default search agreements between Apple and Google.
We support the DOJ’s proposed remedies to eliminate OEM placement deals, revenue sharing agreements, and the bundling of Google Search and Chrome with other Google services. While Google and its OEM partners may argue that such agreements benefit consumers, for example by subsidizing device prices, we do not believe there is sufficient evidence to justify that claim. More importantly, these arrangements have long served to entrench Google's dominance, not only in the search engine market but also by significantly weakening browser competition on Android.
Unlike the termination of revenue-sharing deals with smaller browser vendors, which could pose a serious risk to web platform investment and browser diversity, eliminating OEM deals will not be catastrophic to the financial stability of large partners. For instance, Samsung will not be bankrupted by the loss of such agreements, as its core business and primary revenue streams remain unaffected.
Given the anti-competitive impact of these deals and the minimal risk posed by their removal, we fully support the DOJ’s remedies targeting the elimination of OEM placement, bundling, and revenue-sharing arrangements.
# 24.1.4. Permit Browser Search Default Deals up to 50% Market Share, Excluding Apple
As previously discussed, this remedy would place a cap on Google’s ability to secure default search engine placements, limiting Google to 50% of available default placements on any browser.
Crucially, Apple would be excluded from participating in such deals with Google, for reasons outlined here.
This approach strikes an important balance. It prevents Google from monopolizing the majority of available search defaults while still preserving the critical source of funding for the web platform. In our view, this remedy represents a proportionate and pragmatic solution, one that helps reduce Google’s market share without triggering a sudden and damaging collapse in web platform investment, which underpins services relied upon by millions of American consumers and businesses.
# 24.1.5. Require Reinvestment of Search Revenue into Browser and Web Platform Development
The only compelling justification for allowing Google to continue making search engine default deals with browser vendors is to preserve and support funding for both smaller browsers and the broader web platform.
Given this rationale, it is entirely reasonable to attach conditions to such deals that require 90% of the resulting revenue to be reinvested directly into browser development and web platform improvements. This ensures that the agreements serve a clear public interest and are not simply used to subsidize unrelated corporate priorities.
If properly enforced, this condition would substantially increase the level of funding flowing into the web platform and would help ensure that the web continues to thrive as a viable platform for U.S. businesses.
As discussed earlier, smaller browsers will likely require a carve-out from the 50% default cap in order to remain viable. However, to prevent this exception from being exploited, the share that each of these browsers could sell to Google would gradually decrease to 50% as their market share increases. This could be done using a tapered formula to prevent any sharp changes in revenue and preserve appropriate incentives.
Google’s ability to pursue aggregate deals could be limited by enforcing a strict overall cap, e.g., prohibiting it from purchasing more than 50% of total browser defaults.
This carve-out is essential for preserving meaningful competition in the browser market, particularly from smaller and emerging vendors that play a critical role in innovation and preventing market consolidation.
Rather than requiring a full divestiture of Chrome, the DOJ should compel Google to restructure Chrome as a separate legal entity under Alphabet, with its own independent management. This approach avoids the complexity and risk of an external sale, prevents Google from securing 100% of Chrome’s default search placements and provides Chrome (and Chromium) with a clear and sufficiently large revenue stream.
Under this proposal, the newly independent Chrome entity would be allowed to enter into a default search engine agreement with Google, but only for up to 50% of its available search defaults. The remaining 50% would be auctioned to competing search engines, ensuring that users are exposed to non-Google options at scale.
Critically, the Chrome organization must be independent from Google. It should operate at arm’s length, with its own board of directors and full discretion over its spending. In addition, Chrome must adopt its own distinct privacy policy, separate from those of Google and other Alphabet subsidiaries.
This model is likely to be far more effective than the use of choice screens which typically result in only low single-digit market share shifts. Whereas, as evidenced in the court record, over 65% of users will stay with a non-Google default if the quality is high, which is likely under the DOJ’s proposed syndication remedies. In fact, reliance on a choice screen could directly undermine this remedy by encouraging users to revert back to Google during setup.
Additionally, Chrome’s share of revenue from the Google deal would be subject to a mandatory reinvestment requirement, with 50% allocated to Chrome and 50% to Chromium. This would not only preserve but significantly increase funding for the web platform, likely more than doubling current investment levels.
This remedy is also meaningfully distinct from a full divestiture which would likely saddle the new organization with substantial debt, potentially in the range of $15–20 billion. By contrast, restructuring Chrome as an independent entity under Alphabet avoids the financial burden of acquisition-related liabilities, allowing the organization to invest fully in browser development and open web infrastructure rather than servicing debt. This also avoids the large uncertainty related to attrition of critical talent and access to critical infrastructure that powers Chrome operations. Finally, Chromium will remain shielded by Google’s extensive patent portfolio and formidable legal resources.
The newly structured Chrome entity would still be financially viable, generating profit from its other search engine partnerships and its share of Google’s payment. At the same time, this remedy would:
Prevent Google from using Chrome to gain over 50% market share in the general search engine market
Enable competing search engines to gain meaningful share on Chrome
Substantially expand investment in the web platform
Remove the significant risk present in the divestment remedy
We believe this remedy is the appropriate balance that both achieves the DOJ’s goals while not risking catastrophic damage to the web platform’s funding.
Finally, the DOJ should attach additional conditions to any search engine default deals that Google is permitted to retain.
First, all terms of these agreements should be made public. Transparency enables public scrutiny, which in turn creates meaningful pressure for fair and accountable behavior. It is unlikely that the Apple-Google search deal would have remained in its current form had its details been subject to public disclosure. Making these deals transparent would deter exploitative or anti-competitive terms and ensure they are structured in the public interest.
Second, the revenue share rate should be standardized and locked at the level agreed to in the Apple-Google search deal. There is currently a significant imbalance in bargaining power between Google and smaller browser vendors. Google’s market dominance allows it to dictate terms, and in extreme cases, it could threaten the survival of smaller competitors, such as Mozilla, simply by walking away from negotiations. This imbalance often results in lower revenue shares for smaller browsers, weakening their ability to compete with Chrome.
Only a company on the scale of Apple has sufficient leverage to negotiate more favorable terms. By standardizing the revenue share rate across all browser vendors based on the Apple deal, the DOJ can help ensure that smaller browsers receive a fair share of value from these agreements. This would strengthen competition in the browser market and ensure that any default search deals allowed to continue provide maximum benefit to the public.
At a minimum, the court should require Google to apply non-discriminatory terms to all allowed browser vendors in its default search agreements. This would ensure that no browser is offered significantly worse terms or rates than those given to the largest or most strategically valuable partners, most likely the new Chrome organization under Alphabet.
Now that we have a package of remedies, it is worth revisiting our analysis of the impact of the DOJ’s existing remedies which we predicted would lead to a 70% decline in web platform funding and estimating what the impact of the adjusted remedies would likely be.
Again, as with the previous section, this is an informed but ultimately speculative estimate.
(28% through the ISA, 19.4% through the MADAs and RSAs, and the remaining 2.3% through third-party browser agreements). This figure does not include the 20% of all queries in the United States that flow through Google on user-downloaded Chrome
Queries on user-downloaded Chrome make up 20% of searches conducted in the United States
Based on data from the DOJ's Memorandum Opinion in United States of America vs. Google LLC, we can estimate Chrome’s contribution to U.S. Google Search traffic and use that to establish a lower bound on the potential value of Chrome as a standalone entity within Alphabet.
The court found that user-downloaded Chrome accounts for 20% of U.S. Google Search queries. Additionally, 19.4% of queries flow through Android default access points, and since over 50% of Android search revenue comes from the Google Search Widget, it's reasonable to estimate that the remaining share (roughly 9.7%) comes from Chrome preloaded via MADA and RSA deals.
Combining downloaded Chrome (20%) with Chrome via Android defaults (~9.7%) suggests Chrome contributes ~29.7% of U.S. Google Search traffic.
For comparison, the Apple-Google default deal, which covers 28% of search traffic, is valued at $20 billion annually. Using that benchmark, Chrome’s traffic share could be worth a similar amount. Even assuming Google’s deal with Apple also served as a non-compete, preventing Apple from expanding Safari’s role or building a competing search engine, the traffic value alone should be worth at least half of that, suggesting that 50% of Chrome’s search share default is worth at least $5 billion per year.
If that entire $5 billion were obligated to be reinvested into the Chrome and Chromium ecosystem on a 50-50 basis, Google’s annual direct spending on the web platform would rise to $2.5 billion, a very significant increase in its investment in the web platform.
Available data suggests that Google is significantly underpaying Mozilla relative to Apple for default search engine placement. Safari holds a 17.59% share of the global browser market, while Firefox holds 2.5%. Yet Apple reportedly receives around $20 billion annually from Google, compared to just $400 million for Mozilla.
Even assuming Firefox users are only half as valuable to Google as Safari users, a conservative estimate, Mozilla should be receiving approximately $1.4 billion per year if the revenue share rate were equal. That’s more than three times what Mozilla currently receives.
The disparity stems from a stark imbalance in bargaining power. Google can afford to walk away from Firefox’s small share of the search market. Mozilla, on the other hand, is financially dependent on Google’s payments, and would likely face bankruptcy without them.
The remedy that makes these search engine contracts public and mandates that all browser vendors receive the same revenue share rate that Google has agreed to with Apple redresses this imbalance. This ensures that more of Google’s search revenue is returned to the public good and into smaller browsers that compete with Chrome.
Under such a model, Mozilla’s payments would rise to roughly $1.4 billion annually. That could boost their web platform budget to around $700 million per year, enough to fund serious, sustained investment in Gecko and allow Mozilla to apply real competitive pressure on other browser engines and other browsers.
It is uncertain how Microsoft’s own investment in the web platform will evolve under these conditions. While Microsoft will significantly benefit from increased investment in Chromium, it’s unclear whether this will translate into a corresponding rise in their own contributions.
One likely outcome is that greater confidence in the web platform, driven by higher ecosystem investment, will accelerate Microsoft’s existing efforts to transition more of its software to run on web technologies.
Overall, we expect Microsoft’s investment in the web platform to either increase or at least remain stable in this scenario.
Apple currently receives an estimated $20 billion annually from Google in exchange for default search placement, yet reinvests only a small fraction of that into Safari and WebKit.
Whether Apple intends to build its own search engine remains unclear, and in any case, such a project would be long-term. Our position aligns with the U.S. Department of Justice: the Apple-Google default search deal should be entirely prohibited, along with any future arrangements of a similar nature. If enacted, Apple would lose access to that $20 billion yearly windfall.
However, Apple would almost certainly strike a new default search agreement with another provider, or a group of them, worth at a minimum between $500 million and $1 billion annually. That amount is still more than sufficient to fund Apple’s estimated $300 million annual investment into Safari and WebKit. Moreover, Apple has the financial strength to support Safari even without direct search revenue. For context, Apple has demonstrated willingness to absorb losses exceeding $1 billion annually to support Apple TV+.
This ultimately comes down to Apple’s strategic incentives. First, Apple will not want to cede control over the iOS web ecosystem to third-party browsers. Second, Apple will still have a valuable default search position to protect, even if sourced from different providers.
Until now, Apple has faced no real browser competition on iOS due to its longstanding ban on third-party browser engines. But that is changing, as regulatory actions in the EU, UK, Japan, Australia, and possibly the DOJ’s own case will force Apple to open iOS to real browser competition. Combined with the surge in global web platform investment that our suggested alternative remedies will trigger, all major browsers will be ported to iOS, and those ports will likely, in the long term, be rolled out globally.
Apple will need to respond aggressively to retain Safari’s share on iOS. That means significantly increasing its investment in Safari and WebKit. It may even require bringing Safari back to Windows, Android, and Linux in order to remain viable with developers. Currently, developers must purchase Apple hardware to test Safari, a practice that likely becomes unsustainable once real alternatives exist on iOS.
Given these dynamics, we expect Apple to at least double its investment in Safari and WebKit to a combined $600 million per year, if not more. That is, Apple's investment in the web platform will likely double to $300 million per year.
Smaller browser vendors with existing search engine deals would benefit directly from these remedies, as the mandated revenue share rate based on the Apple-Google benchmark, would significantly increase their payouts. The removal of the Apple-Google agreement would also raise competitive pressure among search engines to secure default placement, making such deals both more lucrative and more widely available.
Over the longer term, as alternative search engines grow in market share and quality, their ability to bid substantial sums for default placement will improve considerably, further boosting the revenue available to browser vendors.
In the short term, it’s unclear whether this will translate into significant increases in web platform investment. Smaller vendors are typically incentivized to differentiate themselves through browser-specific features rather than low-level platform work. However, if any of these vendors achieve meaningful growth, made more likely by the removal of restrictive MADA clauses and the opening of iOS to full competition, we would expect their investments in the web platform to rise accordingly.
Investment in the web platform by non-browser companies tends to track overall confidence in the platform’s ability to meet their technical and business needs. Given that these remedies will drive substantial increases in both web platform investment and meaningful browser competition, we expect a corresponding rise in investment from third-party developers, tool vendors, and other ecosystem participants.
As the web becomes a more capable and competitive environment, these companies will have stronger incentives to build on it.
# 24.2.7. Estimated Total Impact on Web Platform Investment
We can now estimate the overall change in web platform investment based on the likely impact of these alternative remedies across major contributors. While these projections are necessarily speculative, the underlying assumptions and rationale are well-grounded and reasonable.
Current estimated annual investment:
Google: $1,000 million
Mozilla: $200 million
Microsoft: $100 million
Apple: $150 million
Total: $1.45 billion per year
Projected post-alternative-remedy annual investment:
Google: $2,500 million
Mozilla: $700 million
Microsoft: $100 million
Apple: $300 million
Total: $3,600 million per year
This represents an approximate 150% increase in annual investment into the web platform. Such a dramatic rise would significantly accelerate web innovation and strengthen the long-term competitiveness of the open web. The ripple effects could be profound, challenging the dominance of closed ecosystems, particularly the mobile app store duopoly maintained by Apple and Google.
# 24.3. Estimated Impact of the Package on Google's Search Engine Market Share
We can also estimate the potential impact of these alternative remedies on Google Search’s market share in the United States. While these figures are speculative, they are based on well-reasoned assumptions and the data available in the court documents.
As outlined earlier, terminating the Apple-Google search deal is expected to reduce Google’s U.S. search market share by approximately 21.8% to 30.2%. The core assumption is that Apple will sell its default search placement to a competing engine, and given the rising quality of alternative search providers and the supporting syndication remedy, retention rates could match or exceed the 65% retention Bing achieved on Firefox in 2020. This, combined with the fact that the Apple deal accounts for over 50% of Google’s U.S. search traffic, leads to such a steep decline in market share.
As discussed, we can infer from court documents that Chrome accounts for approximately 29.7% of Google’s U.S. search traffic. Under the proposed remedy, requiring Chrome to retain the default search engine for no more than 50% of its users and auction the default for the remaining 50%, an estimated 14.8% of Google’s U.S. search traffic would initially be redirected to competing search engines.
Not all users will stay with the new default. Some will manually switch back to Google. However, using the 65% retention rate Bing achieved on Firefox in 2020 as a benchmark, and factoring in the effects of the syndication remedy, which should improve user retention for alternatives, the actual loss for Google is likely to be smaller, but still significant.
Thus, we estimate that this remedy alone would result in a reduction of between 9.5% and 13% in Google’s U.S. search market share.
It is almost impossible to evaluate the vast number of other remedies that the DOJ has proposed be imposed. Even “comparably minor” ones are individually highly significant, such as the removal of specific bundling terms in MADA agreements.
Given their cumulative effect, even a conservative estimate would suggest at least a 10% reduction in Google’s U.S. search market share attributable solely to these other remedies.
# 24.3.7. Estimated Total Impact on Google Search Share
Combining these, we get a lower bound estimate of a reduction in Google’s share of the search engine market for the United States of between 41.3% and 53.2%.
Currently, Google holds 89.2% of the U.S. search engine market. A 40.9% and 53.2% decline would reduce that share to between 36% and 48.3%.
But what does success look like for the DOJ? Fortunately, the court has already provided clear guidance on this point:
[A] market share below 50% is rarely evidence of monopoly power, a share between 50% and 70% can occasionally show monopoly power, and a share above 70% is usually strong evidence of monopoly power. Memorandum Opinion - United States of America vs Google LLC
It is also worth noting that the entire judgment can be withdrawn after five years if Google's market share falls below 50%.
In other words, even using lower-bound estimates, these alternative remedies would drive Google’s share to below the threshold for presumed monopoly power, easily meeting the DOJ’s own benchmark for success.
In our opinion, the Department of Justice (DOJ) was absolutely right to bring and win its case against Google. The court’s finding that Google has maintained an illegal monopoly over general search is a landmark victory for competition. The proposed remedies are wide-ranging, and many of them are not only justified but necessary.
However, while most of the remedies will either benefit or have a neutral effect on the broader web platform, two stand out as collectively likely catastrophic: a total ban on search engine placement deals and forcing Google to divest Chrome.
A total ban on search engine placement deals would likely bankrupt Mozilla and strip a newly independent Chrome of its most reliable revenue stream. Even more concerning, forcing a Chrome divestment could collapse investment in the web platform, likely cutting it by 70%. Together, these actions risk destabilizing the browser ecosystem, concentrating power among even fewer players, and severely undermining innovation and long-term investment in the web platform.
We are deeply concerned that in trying to solve one monopoly problem, the DOJ could unintentionally harm the open web ecosystem, a sector worth trillions to the U.S. economy, and in doing so, strengthen other entrenched tech giants, potentially undermining its own antitrust efforts, including their case against Apple.
Critically, such a collapse in web investment would significantly weaken the web's ability to compete with the closed ecosystems operated by Apple and Google. Web apps offer the only viable cross-platform alternative to native apps locked behind app stores and OS restrictions. Undermining browser funding now would kneecap the web just as regulators around the world are starting to push for real competition on mobile platforms. Without sufficient funding, the open web cannot keep pace, and users, developers, and the broader digital economy will be the ones who suffer.
But this outcome is avoidable.
We believe the DOJ can not only break Google’s monopoly without harming web platform funding, but also increase it, along with the competition that drives innovation in browsers, by making a few targeted adjustments to its remedies that protect browser competition and ensure sustainable investment in the web platform.
The DOJ has a historic opportunity not just to break Google’s monopoly, but to increase investment in the web platform and strengthen competition in the browser market. By making a few targeted changes to its remedy package, the DOJ can protect long-term innovation, enhance browser diversity, and ensure the open web continues to thrive.
We have proposed the following six potential targeted changes:
Cap Google’s default search deals to 50% per browser, excluding Apple whose contract should be canceled entirely.
Introduce a carve-out for smaller browsers.
Mandate 90% reinvestment of Google search revenues into web platform and browser development.
Restructure Chrome as an independent subsidiary within Alphabet.
Limit Chrome’s default search deal with Google to 50% of users and auction the remaining defaults to rival search engines.
Enforce transparency and fair revenue share terms across all search deals.
These adjustments would still achieve the DOJ’s core goal: restoring meaningful competition in general search. Conservatively, we estimate these adjusted remedies would reduce Google’s U.S. search market share to below 50%, the threshold for presumed monopoly power.
Critically, though, rather than collapsing platform funding, these adjusted remedies would likely increase web platform investment by 150%, creating a healthier, more competitive, and more innovative internet ecosystem.
With the right adjustments, the DOJ’s case against Google can mark not just the end of a monopoly, but the start of a new era of competition and innovation on the web. This is a once-in-a-generation opportunity to restore balance and ensure the internet remains an open, competitive platform, one that continues to serve millions of Americans and fuel growth across the entire U.S. economy.
]]>
UK Regulator's Final Verdict: Apple’s Browser Engine Ban Harms Competition2025-03-19T00:00:00Zhttps://open-web-advocacy.org/blog/uk-regulators-final-verdict--apples-browser-engine-ban-harms-competition/
The UK's Mobile Browsers and Cloud Gaming Market Investigation Reference (MIR) has published its final report. The conclusion is clear: Apple’s “WebKit restriction”, which forces all browsers on iOS to use Apple’s engine, harms competition, stifles innovation and functionality, particularly for Web Apps.
Most importantly, the MIR recommends a complete reversal of Apple’s ban on third-party browser engines. For the first time, a regulator proposes a remedy requiring Apple to allow third-party browsers to install and manage Web Apps using their own engines. This is a critical win for developers, startups, and anyone who relies on an open web.
These remedies are not just theoretical. The UK’s Competition and Markets Authority (CMA) has now launched Strategic Market Status (SMS) investigations into both Apple and Google under the new Digital Markets, Competition and Consumers Act (DMCC). Many of the MIR’s remedies, including lifting Apple’s browser engine ban, have already been integrated into the SMS investigations, signaling the CMA’s clear intent to enforce them swiftly once designation is complete, which is set to happen within nine months.
This report is a landmark moment for web and browser competition. While there is still work ahead, this marks strong action by yet another country's regulator to restore fair competition between browsers and between Web Apps and native app stores. Open Web Advocacy is proud to have played a role in this process and remains committed to seeing these remedies fully implemented. We would like to thank the CMA and the MIR team for their tireless work over the last 4 years. We would also like to thank every developer, business, and supporter who helped make this possible. Together, we are one step closer to an open web that can compete effectively.
The report (which is more than 600 pages) contains a number of significant conclusions which we have split by section. We haven’t covered everything that the report lays out.
We conclude that the WebKit restriction means that there is no competition between browser engines on iOS.
We also conclude that the WebKit restriction harms competition in the market for mobile browsers on iOS.
We conclude that Apple’s WebKit restriction limits the ability of rival browser vendors to improve the performance of their mobile browsers on iOS.
We conclude that Apple’s WebKit restriction limits the ability of rival browser vendors to innovate and improve their mobile browsers on iOS.
We conclude that Apple’s WebKit restriction increases costs of rival browser vendors as it requires them to develop and maintain an additional version of their mobile browser, based on WebKit, to serve iOS users.
We conclude that this reduces the features available to consumers and web developers, and limits effective competition between browser vendors on iOS on security, privacy, and performance.
We conclude that the WebKit restriction does not give rise to rivalry-enhancing efficiencies in mobile browsers on iOS that would offset the negative effects on competition associated with the WebKit restriction we have identified
We conclude that the WebKit restriction therefore limits the features available to users and decreases competition between mobile browsers on privacy features on iOS.
MIR’s Final Report
We wholeheartedly agree with the MIR’s conclusion that the WebKit restriction limits users’ choice, raises costs for developers and browser vendors, reduces the features and performance available to both users and developers, and undermines browser competition on iOS.
# Apple Security Justification for Banning Rival Browser Engines
Although the evidence provided by Apple shows that fragmentation is a problem on Android, and increases the risk of n-day attacks, we note that the appropriate benchmark to the WebKit restriction is not one where there are no restrictions placed on browser vendors to manage the risk from fragmentation. Instead, Apple could use alternative safeguards, such as managed entitlements, or requirements for browser vendors to update their browser engines in a timely manner, to reduce the risk from fragmentation.
Second, as described above, Apple has submitted that WebKit has certain security advantages as a browser engine on iOS compared to any potential alternative browser engines, given integration between software and hardware, coordination between Apple’s engineering functions, and Apple’s ongoing security analyses.
However, we note that as part of the measures Apple has announced in response to the DMA, Apple has made some of these security features available to other browser engines, such as Pointer Authentication Codes, demonstrating that benefits of hardware integration could potentially be extended to other browser engines.
Evidence also indicates that all the major browser engines take a stringent approach to testing for and fixing security vulnerabilities. Apple’s submissions that it is the only browser engine developer that could be trusted to perform this function on iOS therefore seems weak.
Although some of the evidence cited above is from several years ago, it nonetheless indicates that alternative browser engines undertake security testing at a similar level to Apple, and we have not seen evidence to suggest that this has changed since then. MIR’s Final Report
We are delighted that the MIR team has seen through Apple’s plausible-sounding but ultimately weak arguments that only they can be trusted to implement a browser with its own engine on iOS. In particular their refutation of the argument that Safari would have superior security due to a refusal by Apple to share certain iOS hardware security APIs such as Pointer Authentication Codes. This argument has been undone by the EU’s Digital Markets Act forcing Apple to share this functionality.
New features and improvements are a key parameter of competition between browsers. We conclude that by preventing, or making it more difficult, for browser vendors to implement new features and improvements, Apple’s WebKit restriction limits the ability of rival browser vendors to compete on iOS. We have seen evidence of limitations impacting security, privacy, and performance improvements, and support for other features, notably those important for web apps and PWAs.
We consider that limited competition in the markets for browser engines and mobile browsers on iOS has led to worse outcomes for web developers than we would expect in a well-functioning market. There is evidence that WebKit has been slower to support new mobile browser features, particularly in relation to web apps, and that this is a particular concern for developers interested in more innovative features such as those for web apps. MIR’s Final Report (emphasis added)
We agree with the MIR team’s assessment that the WebKit restriction has been particularly damaging to the feature set and performance of Web Apps and that this is the result of it limiting competition in the markets for mobile browsers on iOS.
We conclude that the evidence demonstrates that Safari has or has had wider and more immediate access to functionalities on iOS than other mobile browsers. MIR’s Final Report
While a more minor issue compared to the total ban on porting browser engines to iOS, we agree with the MIR team that Apple should not be able to reserve iOS functionality for Safari or delay sharing it with third-party browsers.
We conclude that the ISA revenue shares are significant and that therefore their impact on Apple’s and Google’s financial incentives to compete in the supply of mobile browsers on iOS is also significant.
We conclude that the ISA revenue sharing arrangements significantly reduce Apple’s and Google’s financial incentives to compete, including via investing in Safari and Chrome respectively, and therefore adversely impact competition in the supply of mobile browsers on iOS.
We conclude that the ISA does not give rise to rivalry-enhancing efficiencies that are able to offset the negative impact on competition of the ISA’s revenue-sharing provisions. MIR’s Final Report
For those wanting more details about the Apple-Google Search deal (ISA), worth $20 billion annually, the report is often hilariously (and annoyingly) vague due to confidentiality:
Screenshot of section of MIR Final Report on the Apple-Google Search Deal
However, we entirely support the MIR in their assessment that Google paying Apple for Google Search Revenue in iOS Chrome significantly undermines browser competition. We would go further and say that this is bordering on a non-compete agreement for browsers on iOS between Apple and Google.
We conclude that Apple’s practices of pre-installing only Safari contributes to low user awareness of other mobile browsers.
We conclude that the added friction involved in accessing a third-party browser app impacts usage and retention and that differences of approach to the placement of Safari and alternative mobile browsers on a device home screen limit the ability of rival mobile browsers to compete with Safari on iOS.
We conclude that Apple’s choice architecture practices in the device factory settings that are presented to users when they first use a new mobile device, limit mobile browser competition on iOS. MIR’s Final Report
We agree with these assessments and support the proposed remedies such as a choice screen on start up and granting the chosen browser a spot in the hotseat/dock.
We conclude that users’ inability to uninstall Safari is unlikely to impact users’ ability to download an alternative mobile browser given that users are able to remove Safari from the default home screen, and therefore, this is unlikely to limit competition between mobile browsers on iOS. MIR’s Final Report
This is disappointing, as it would have been easy to implement, especially since the DMA already requires it. We believe that allowing Safari (and Chrome on Android) to be uninstalled is important psychologically as it indicates to users it is just another app that can be replaced.
Note the operating system webview, i.e., WkWebView and Android WebView do not need to be uninstallable.
We conclude that Apple’s ban on alternative browser engines for in-app browsing on iOS reduces competition in the market for the supply of in-app browsing technology on iOS as it prevents app developers such as Meta from introducing an IAB based on an alternative to Apple’s WKWebView.* MIR’s Final Report
Our viewpoint on this is complex and not easily summarized.
The MIR has approached the issue on in-app browsers from the view that app developers should be able to choose which browser (and which browser engine) handles outbound links to third-party websites clicked on in that non-browser app.
Our view is that the user's chosen browser (i.e. their default browser) should always handle those links and at the very least the app should have to ask permission to override the users default browser.
We consider that remote tab IABs would be similar to SFSafariViewController in that they are low-cost and easy-to-implement for the app developer. Remote tab IABs would, therefore, represent an avenue via which alternative in-app browsing technology providers such as browser vendors could exert competitive pressure on Apple’s own in-app browsing technology offering
We further note that enabling remote tab IABs on iOS would also provide the option for app developers to call upon a user’s default browser for in-app browsing if they wish
Second, the inability of browser vendors to offer remote tab IABs also harms their ability to compete in the market for mobile browsers on iOS as it prevents them from accessing a sizeable and likely growing proportion of web traffic. Indeed, offering remote tab IABs would allow browser vendors to benefit from this traffic, which would translate into increased usage (and better web compatibility with their underlying browser engine), would drive increased engagement with and brand awareness of their browsers, and would allow them to support their existing customers better by providing a more ‘consistent’ web browsing experience on the device. This would increase competitive pressure on browsers on iOS, including Safari. MIR’s Final Report
We raised a key concern that SFSafariViewController is effectively hardwired to Safari, unlike Android Custom Tabs, which, unless explicitly overridden, respects the user’s default browser choice. Our proposal to the MIR team was straightforward: Apple should be required to upgrade SFSafariViewController so it always uses the user’s default browser, while Google should be prohibited from hard-coding Android Custom Tabs to Chrome in apps like the Android Google Search app.
The user’s choice of default browser is meaningless if non-browser apps can ignore it when opening web links. If links from apps don’t open in the default browser, then what exactly is being defaulted?
The above evidence does not show that Chrome has greater access to functionalities required to implement user-facing features relative to third-party mobile browsers, with the exception of WebAPK minting. However, given the availability of alternative methods for installing web apps on Android, our view is that this does not impact competition. For the other functionalities considered, the evidence suggests that third-party mobile browsers have equivalent access. MIR’s Final Report
This is disappointing, and we disagree with the MIR team's assessment. Alternative methods for installing Web Apps do not integrate well with Android, as evidenced by Google needing to implement WebAPK minting for Chrome. We do not believe that Google should be able to reserve important functionality for its own browser. We have written extensively about this topic and will continue to advocate to force Google to share WebAPK minting under the DMCC.
We conclude that a recommendation to the CMA Board in the manner expressed in the Our remedy sub-section above is the most appropriate way to address effectively and comprehensively the AECs we have identified. MIR’s Final Report
In our response paper we were concerned that there could be a significant delay caused by the MIR not using its powers to fix the most critical issues it had identified. That said, we understood the appeal of the DMCC ability to monitor and enforce requirements. We proposed implementing the most critical remedies now using the MIR’s powers and having the DMCC as a monitoring and enforcement body.
OWA suggested implementation of a minimum ‘core set of the most critical remedies’ (eg to address the WebKit restriction) at the conclusion of the market investigation. Once the DMCC Act was in force, the DMU could take over responsibility for ongoing enforcement, addressing any remedies that have been ‘bypassed or whose objectives remained unfulfilled’. MIR’s Final Report
We are deeply appreciative of the MIR team's detailed and convincing arguments as to why handing on these recommendations onto the CMA to implement under the DMCC will be effective, less risky and not result in significant delay. This is significantly strengthened by the CMA’s investigation into Apple’s and Google’s Strategic Market Status (SMS) directly incorporating the MIR’s core recommendations, making it clear the CMA intends to act quickly once designation is complete, expected within nine months.
In any event, we do not consider that interventions which the CMA may decide to impose under the DMCC Act powers would necessarily take significantly longer to implement than the remedies which could be imposed via the EA02 remedy-making powers. In particular, we note that:
(a) As set out in the Digital markets competition regime sub-section above, the CMA commenced SMS designation investigations on 23 January 2025 to assess whether to designate Apple and Google with SMS.
(b) The DMCC Act allows for SMS designation assessments to be conducted in parallel with designing CRs, meaning that they could in principle be imposed at the end of a designation investigation, which is subject to a nine-month statutory deadline. In this context, we note the CMA’s stated intention to start considering potential interventions in parallel with its work on whether to designate Apple and/or Google, whilst recognising that any decisions on such interventions will be dependent on the designation decisions.
(c) Remedies imposed by orders or undertakings following a market investigation may, depending on their complexity, also take some time to devise and implement. The EA02 provides for a remedy implementation phase to make the order or accept undertakings of up to six months (extendable by up to four months) after the final report is published. This may then be followed by a further phase before such remedies take effect.
We consider that the likelihood of the CMA Board acting on our recommendation in a timely manner is high. In particular, and as set out above, we note that:
(a) On 23 January 2025 the CMA opened SMS investigations into Apple and Google in respect of their mobile ecosystems (including mobile browsers, browser engines and in-app browsing technology);
(b) In its ITC, published on the same day, the CMA noted that it would be able to consider this final report once it is published.
MIR’s Final Report
A requirement for Apple to allow use of alternative browser engines on iOS with access granted to iOS to browser vendors using alternative browser engines on equivalent terms to that made available to WebKit, Safari or third-party applications.
Equivalence of access is clarified to include:
(a) enabling access in a way which respects the technical architecture of alternative browser engines;
(b) enabling access to all of the current operating system-level features and functionalities that WebKit and Safari currently use;
(c) enabling access to all other current operating system-level features and functionalities that exist on iOS and are available for use by third-party applications, but which WebKit and Safari currently do not use;
(d) enabling access to future operating system-level features and functionalities available to WebKit, Safari, or third-party applications, whether or not WebKit and Safari choose to use them;
(e) enabling access to the required iOS functionality to allow browser vendors using alternative browser engines to install and manage progressive web apps (PWAs) using alternative browser engines; and
(f) enabling access to the required functionality to allow browser vendors using alternative browser engines to check whether their mobile browser has been set as default
# Interopability Requirements for WebKit Browsers on iOS
An interoperability requirement mandating Apple to: (i) grant equivalent access to functionality used by Safari to browser vendors using the version of the WebKit engine as specified by Apple on iOS; and (ii) grant such access within a reasonable timeframe.
# Allow In-App Browser to use their Own Browser Engine
(a) A requirement for Apple to: (i) allow native app developers on iOS in the UK to use their choice of browser engine for in-app browsing within their native app (a ‘bundled engine’); and (ii) provide interoperability with bundled engines for in-app browsing (‘bundled engine IAB’)
(b) A requirement for Apple to allow sufficient cross-app functionality to enable native apps to invoke third-party browsers (regardless of the browser engine they use) to support in-app browsing.
(a) A requirement for Apple to ensure the use of a browser choice screen at device set-up.
(b) A requirement for Apple to ensure the placement of a default browser selected by the user in the ‘application dock’/‘hotseat’ or on the default home screen at device set-up.
(c) A requirement for Apple to ensure the use of a browser choice screen after device set-up.
(d) A requirement for Apple to share user data on default browser settings with browser vendors.
(e) A requirement for Apple to ensure that the frequency of default browser prompts and notifications is limited across multiple access points
(a) A requirement for Google to ensure the use of a browser choice screen at device set-up.
(b) A requirement for Google to ensure the placement of a default browser selected by the user in the ‘dock’/‘hotseat’ or on the default home screen at device set-up.
(c) A requirement for Google to ensure the use of a browser choice screen after device set-up.
(d) A requirement for Google to ensure that the frequency of default browser prompts and notifications is limited across multiple access points.
For those only loosely following, or just tuning in, this is the culmination of a multi-year series of regulatory events which OWA has been heavily involved in.
OWA was formed on the 12th of March 2021 due to dissatisfaction with the slow pace of features being added to iOS Safari and the excessive number of bugs. We realized, after a series of unsuccessful attempts to woo Apple to voluntarily start work on these features and increase Safari’s budget, that the problem was two-fold. A total absence of browser competition on iOS due to Apple’s ban of rival browser engines and that Apple was actively disincentivized to allow Web Apps to effectively compete with apps sold via their own App Store.
On the 15th June 2021, the UK’s Competition and Markets Authority (CMA) launched a market study into mobile ecosystems, attempting to assess potential sources of harm to consumers within 4 broad themes:
Competition in the supply of mobile devices and operating systems.
Competition in the distribution of mobile apps.
Competition in the supply of mobile browsers and browser engines.
The role of Apple and Google in competition between app developers.
In early October 2021 we had a meeting with the CMA to explain how effective browser competition was being prevented on iOS and how this was harming both consumers and developers by preventing Web Apps from being a viable competitor to native app stores. The meeting consisted of three presentations by Alex Moore, Stuart Langridge and Bruce Lawson. These presentations were primarily focused on iOS Safari's (and by extension all browsers on iOS) lack of support for push notifications.
Two weeks later (and after more than a decade of refusing to do so), Apple quietly began work on push notifications for iOS Safari.
In this report the CMA came to several critical conclusions including:
As a result of the WebKit restriction, there is no competition in browser engines on iOS and Apple effectively dictates the features that browsers on iOS can offer (to the extent that they are governed by the browser engine as opposed to by the UI).
Importantly, due to the WebKit restriction, Apple makes decisions on whether to support features not only for its own browser, but for all browsers on iOS. This not only restricts competition (as it materially limits the potential for rival browsers to differentiate themselves from Safari on factors such as speed and functionality) but also limits the capability of all browsers on iOS devices, depriving iOS users of useful innovations they might otherwise benefit from. Interim Report into Mobile Ecosystems (emphasis added)
They also noted that Apple has two perverse incentives to hold back WebKit and to hinder Web Apps’ ability to compete with the iOS App Store:
First, Apple receives significant revenue from Google by setting Google Search as the default search engine on Safari, and therefore benefits financially from high usage of Safari. Safari has a strong advantage on iOS over other browsers because it is pre-installed and set as the default browser. The WebKit restriction may help to entrench this position by limiting the scope for other browsers on iOS to differentiate themselves from Safari (for example being less able to accelerate the speed of page loading and not being able to display videos in formats not supported by WebKit). As a result, it is less likely that users will choose other browsers over Safari, which in turn secures Apple’s revenues from Google.
Second, and as discussed in Competition in the distribution of native apps, Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
Interim Report into Mobile Ecosystems (emphasis added)
You can see our response to the report here. Including our Walled Gardens Report where we laid out the case that Apple’s ban of third-party browser engines was effectively a ban on third-party browsers.
In addition to our own response, a large number of developers wrote in, many answering our call to submit their views. You can read their responses expandable below:
We are deeply grateful for this as it gave the case for pursuing remedies to fix browser and Web App competition immense weight.
The CMA issued their Final Report into Mobile Ecosystems on the 10th June 2022 and announced it was considering opening a market investigation reference (a serious investigation where the CMA has strong evidence of anti-competitive behaviour and sets out to fix it).
On the 31st of March 2023, the MIR was suspended following a Competition Appeal Tribunal judgment and order. Unfortunately, they delayed starting the investigation while waiting to see if the UK government was going to pass new laws granting them stronger powers to deal with anti-competitive behaviour by tech giants. These laws were working their way through parliament at the time and were expected to be passed into law in 2024.
Due to this, Apple managed to successfully get the MIR dismissed, not by arguing before the tribunal that the CMA was substantially wrong about any of its anti-competitive behaviour, but on the legal technicality based around the timing of the opening of the investigation.
While the paper contains a number of excellent remedies, not least of which is prohibiting Apple from banning browser engines from iOS, we were deeply concerned that the MIR will fail in its goal of allowing third-party browsers to enable effective competition from Web Apps.
This goal was highlighted in the opening statement in the MIR:
We all rely on browsers to use the internet on our phones, and the engines that make them work have a huge bearing on what we can see and do. Right now, choice in this space is severely limited and that has real impacts – preventing innovation and reducing competition from web apps. We need to give innovative tech firms, many of which are ambitious start-ups, a fair chance to compete.
Andrea Coscelli - Chief Executive of the UK's Competition and Markets Authority (emphasis added)
Specifically, we were concerned there was no remedy that would allow browsers to install and manage Web Apps using their own engine. That is, Apple would be able to lock all browsers (including ones with their own engine) into using their current WebKit implementation of installed Web Apps. We wrote an article at the time titled: “UK’s Browser and Cloud Investigation may fail to allow Web App competition” explaining our concerns and asking interested parties and developers to write in.
We are delighted to say that the MIR team has listened to both us and all of the many many businesses and web developers who wrote in. A huge thank you to every developer and business that took the time to write in and explain their concerns, it really makes a difference!
For example, ‘equivalence of access’ would need to include enabling third-party browsers using alternative browser engines to install and manage PWAs (rather than relying on WebKit to support parts of this process), including enabling mobile browsers using alternative browser engines to implement installation prompts for PWAs. MIR - Provisional Decision Report
Additionally, the MIR team stated that they were not intending to implement any remedies directly but would make recommendations to the CMA to be implemented under the DMCC.
The Digital Markets, Competition, and Consumers Act (DMCC) 2024 came into effect on the 1st of January 2025, granting the UK regulator authority to designate companies with Strategic Market Status (SMS). This can be thought of as the UK’s equivalent to the EU’s Digital Markets Act, although it has differences in how it is implemented as covered in this article.
On the 23rd of January 2025, the CMA opened an investigation to designate Apple and Google as having SMS status under the DMCC. You can see their request for comment here and our response here.
Importantly the key remedies from the MIR appear directly in the SMS, indicating the CMA intends to tackle them immediately upon successful designation. Designating Apple and Google will take approximately 9 months and should be completed before the end of 2025.
This brings us to the present and the MIR’s Final Report, published on March 12, 2025, exactly four years since OWA’s founding and after four years of near-continuous advocacy.
The remedies set out in the final report are pivotal, with the most critical being a full reversal of Apple’s browser engine ban. Importantly, the report includes a specific remedy ensuring that third-party browsers can install and manage Web Apps using their own engines, an essential step toward restoring competition between Web Apps and gatekeepers' app stores.
We want to extend our deepest thanks to the MIR team for their tireless work over the past 15 months on an issue that is both technically complex and highly nuanced. While we may differ on a few sub-topics, there is no question that these recommendations will have a profound, lasting and positive impact on the mobile browser and Web App markets.
These remedies have not been set aside. Many of them have been carried directly, almost word for word, into the CMA’s SMS investigations into Apple and Google. We call on the CMA, under the DMCC regime, to swiftly designate both companies with Strategic Market Status and move quickly to implement these critical remedies.
This has always been a long fight, but this report marks a major victory on the path toward fair and open browser competition. We are incredibly grateful for the support we’ve received, both financial and volunteer, and we remain committed to seeing this through. We’ll keep pushing until browsers and Web Apps can compete on a level playing field across all operating systems, everywhere.
]]>
SLAP and FLOP: Apple's Lack of Full Site Isolation and iOS Browser Ban Puts Users at Risk2025-02-04T00:00:00Zhttps://open-web-advocacy.org/blog/slap-and-flop--apples-lack-of-full-site-isolation-and-ios-browser-ban-puts-users-at-risk/TL:DR; Yet again Apple’s ban on third-party browser engines weakens security
rather than strengthens it.
Researchers from the Georgia Institute of Technology and Ruhr University Bochum have published papers describing two attacks dubbed SLAP and FLOP that impact Apple’s latest chipsets.
These attacks share conceptual similarities with the Spectre exploits, which affected most pre-2019 processors by exploiting speculative execution. While Spectre targeted branch prediction, SLAP and FLOP exploit load address and value prediction in Apple's latest chips.
For SLAP, Apple requested an extended embargo beyond the typical 90-day window, and the researchers ultimately waited 250 days before publishing. For FLOP, the researchers notified Apple 148 days prior to publication. In both cases, Apple has not provided any timeline for implementing mitigations to the researchers or the public.
The SLAP attack targets Apple-designed processors, such as the M2, A15, and newer models that have a Load Address Predictor (LAP), which predicts the memory addresses of subsequent load instructions to optimize performance.
According to the paper, visiting a malicious website could potentially allow an attacker to access data from another arbitrary page on a different domain.
In their example in the paper, confidential email subject lines from Gmail can be accessed through a third-party website.
"We assume the target is authenticated to Gmail, and visits the attacker webpage. The attacker webpage allocates 1.7 MB of filler and training strings, and then calls window.open on Gmail’s inbox page when the mouse cursor is placed over itself. As Gmail loads, JavaScript in the page starts rendering the inbox, whose content is personalized to the target. Over repeated trials, we show that the subject line and the sender’s identity can land in the reachable out-of-bounds region of the LAP, allowing for recovery by the adversary in Figure 17."
SLAP: Data Speculation Attacks via Load Address Prediction on Apple Silicon
SLAP: Data Speculation Attacks via Load Address Prediction on Apple Silicon - Figure 17
This attack only works in Safari (and all browsers on iOS due to Apple's browser engine ban) running on devices with newer Apple-designed processors, such as the M2 and A15.
This attack does not work on other major browsers such as Chrome, Firefox, Edge, Opera, and Vivaldi on platforms where they can use their own browser engines.
This is due to a feature called site isolation which separates each domain into its own process, preventing malicious websites from accessing or stealing information from other sites.
"We emphasize the importance of site isolation [55], a mechanism preventing webpages of different domains from sharing rendering processes. Site isolation is already present in Chrome and Firefox [42, 55], preventing sensitive information from other webpages from being allocated in the attacker’s address space. While its implementation is an ongoing effort by Apple [3, 4], site isolation is not currently on production releases of Safari."
SLAP: Data Speculation Attacks via Load Address Prediction on Apple Silicon
The researchers indicated that they disclosed the vulnerability to Apple on 24th of May 2024 (250 days prior to publication) under responsible disclosure:
“The researchers disclosed their findings to Apple on May 24, 2024. Apple’s Product Security Team acknowledged the report and proof-of-concept code, requesting an extended embargo beyond the typical 90-day window. At the time of writing, Apple has not shared a schedule regarding mitigation plans concerning the results presented in this paper.”
SLAP: Data Speculation Attacks via Load Address Prediction on Apple Silicon
All browsers on iOS devices are affected by this exploit due to Apple's policy requiring all browsers to use the WebKit engine, effectively making them Safari under the hood. This means iOS users cannot switch to alternative browsers that might not be affected by SLAP.
The FLOP (False Load Output Prediction) attack exploits a different aspect of speculative execution in Apple's M3+ processors. Specifically, it targets the Load Value Predictor (LVP), which predicts the outcome of data dependencies to improve performance. If the LVP predicts incorrectly, it can lead to the execution of instructions using incorrect data, potentially allowing an attacker to access sensitive information.
Unlike SLAP, FLOP affects all browsers. However, due to site isolation in browsers like Chrome and Firefox, the attack is limited to working between subdomains of the same site, rather than between completely unrelated websites. This does not entirely defeat the exploit but it does make FLOP significantly less concerning than SLAP on browsers other than Safari.
In Safari, an attacker could potentially gain access to data from any arbitrary website through a malicious site on an affected device. For example, data could potentially be accessed from gmail.com via exploit code running on attacker.com. On other browsers (using either Gecko or Blink) it would only be able to potentially gain access to data on other subdomains for example from attacker.example.com to target.example.com. This greatly limits the attack's scope.
Again, all browsers on iOS are impacted by this exploit, as users cannot take advantage of other browser engines' superior protections due to Apple’s browser engine ban.
Responsible Disclosure. We disclosed our results to Apple’s Product Security Team on September 3, 2024 upon completing the initial version of the writeup. Apple has acknowledged our writeup, and after an internal investigation, communicated that they plan to address this in an upcoming security update without sharing further details.
FLOP: Breaking the Apple M3 CPU via False Load Output Predictions
The researchers disclosed this vulnerability to Apple on September 3, 2024 (148 days before publication) but did not notify Google or other browser vendors, possibly viewing the threat as minor due to existing mitigations in those browsers, meaning such notification was not necessary or warranted.
Site isolation was introduced in Blink (Chrome, Opera, Vivaldi, Brave) in July 2018 as a security feature to mitigate Spectre-style attacks, and Edge since 2020. It was added to Gecko (Firefox) in December 2021 with Project Fission. It is still being implemented for Firefox Android.
Full site isolation requires additional memory to keep different domains in separate processes. As a result, all browsers make trade-offs and do not enforce full site isolation in every scenario. For example, Chrome disables site isolation on devices with less than 2GB of RAM and, on Android devices, primarily applies it to sites where it can detect that the user is logged in.
While Safari has some level of process isolation, it lacks full site isolation and does not as aggressively keep processes separate between different domains as other browsers. As a result Apple lags several years behind in this important protection and has prevented any rival from bringing this security feature to iOS via its browser engine ban.
On affected devices, Safari users should be aware that malicious websites could potentially steal data from other domains. On macOS, users can switch to alternative browsers while waiting for Apple to implement site isolation or similar protections.
Apple has repeatedly claimed that allowing other browser engines onto iOS will weaken security for iOS users. Apple claims that its unilateral control over the only browser engine on iOS allows it to minimize the patch gap for all browsers on iOS and thus improve security.
Apple recalls that the WebKit requirement provides a high base level of stability, security, and
privacy that is more effective than Android for a variety of reasons, including because it does not
result in a ‘patch gap’ which in turn gives rise to 'significant security risks'.
Apple’s response to CMA provisional decision report
In this case, not only has Apple failed to patch SLAP on iOS, despite having 250 days advanced notice, but they have also blocked all other vendors from doing so.
On iOS, changing browsers offers no protection from this exploit since all browsers must use the same WebKit engine. At the same time, this shields Apple from losing market share, as no tech professional or tech website will recommend switching browsers on iOS in this case, given that all browsers on iOS are essentially Safari under the hood. As a result, competitive pressure to quickly address vulnerabilities is eliminated. Competition and the fear of losing market share are powerful forces for improving security, but for browsers on iOS, they have been entirely nullified.
]]>
Digital Markets Act: Europe’s Digital Competitiveness at Stake2025-01-29T00:00:00Zhttps://open-web-advocacy.org/blog/digital-markets-act--europes-digital-competitiveness-at-stake/
Open Web Advocacy has joined forces with industry associations, civil society organizations, and businesses to call on the European Commission to take urgent and decisive action in enforcing the Digital Markets Act (DMA). This landmark regulation was designed to curb the power of dominant gatekeepers and foster a more open, competitive digital landscape. However, without proper enforcement, the DMA risks falling far short of its intended impact.
The open web could be a superior alternative to closed, proprietary mobile operating systems that restrict interoperability and impose unjustified fees on developers and businesses. However, these same gatekeepers have restricted the web's ability to compete fairly in contravention of the DMA.
If the web were able to compete fairly and effectively with native app stores, these gatekeepers would not be able to demand a 30% cut of all third-party software. Gatekeepers obtain this cut not through merit but simply by blocking all alternative means of running third-party software, such as Web Apps.
Critically, the DMA contains important rules allowing browsers and web apps to compete fairly.
The DMA was created to put an end to these unfair practices in the European Union. Once effectively implemented, it will set a global precedent, prompting regulators in other regions to demand similar protections for competition and consumer choice. Enforcement is critical. Without it, these same entrenched gatekeepers will continue to exploit their market power, stifling innovation and harming both developers and consumers.
Now, more than ever, the European Commission must remain firm in its commitment to enforcing the DMA. It is not enough to pass legislation; real change will only happen when the rules are actively upheld and violators are held accountable. The web must be allowed to compete on a level playing field.
We urge the European Commission to act decisively and ensure that the DMA fulfills its promise.
Read our joint letter below:
# Digital Markets Act: Europe’s Digital Competitiveness at Stake
Dear President von der Leyen, Executive Vice-President Ribera, Executive Vice-President Virkkunen,
We represent a diverse group of global businesses, developers, civil society organisations, consumer organisations and associations from various sectors including music streaming, gaming, news publishers, online dating, tourism, broadcast media and online marketplaces.
We write to you today with urgent concerns about certain designated gatekeepers’ disregard for the effective implementation of the Digital Markets Act (DMA), and the devastating impact this is having on the EU’s tech sector’s competitiveness and potential for growth.
The DMA was a landmark achievement for the EU, designed to unlock the immense potential of the European digital single market. It promised to break the stranglehold of a few powerful companies, fostering a vibrant ecosystem of innovation where businesses of all sizes could fairly compete. Consumers would benefit from greater choice and more innovation in online markets.
Nine months after the implementation deadline, these promises remain unfulfilled. Some gatekeepers actively circumvent the law, employing sham compliance strategies and even outright defiance, suffocating innovation and preventing growth of companies of all sizes, including SMEs and startups. The Commission rightly decided to open non-compliance investigations into such gatekeepers, but this has not led them to comply with the law. It’s time to adopt non-compliance decisions which deter gatekeepers from disregarding the law.
We urge the European Commission to take immediate and decisive action, by first concluding the ongoing non-compliance investigations and by using all the tools it has available in the DMA. Breaking the law should no longer be a profitable business strategy. The DMA represents a historic opportunity. Swift and vigorous enforcement would strengthen the EU’s position as a global leader in technology, drive economic growth across the continent and unlock the next generation of European tech champions. With free and fair markets, new businesses will flourish, consumers will win and Europe will be home to more innovation.
Competition policy has been a fundamental driver of the success of the EU single market, which has largely benefitted gatekeepers as well. The EU should not compromise on this fundamental cornerstone of its Treaties because of defiance from certain powerful companies. Otherwise, the whole credibility of the DMA, EU competition, and the Commission’s effective enforcement will be at risk.
We trust in your commitment and stand ready to work together towards a fair and competitive digital market where innovation and consumer choice thrive.
This falls under the newly passed Digital Markets, Competition and Consumers Act (DMCC), which came into force on January 1, 2025. The investigations place significant focus on web apps, browser engines, and browsers.
Being declared an SMS under the DMCC can be seen as equivalent to being designated a gatekeeper under the EU's Digital Markets Act (DMA).
Web apps, which are separate apps that can be saved to a user’s home screen from a browser, are generally not considered by app developers to be a realistic alternative to listing native apps on the App Store, due to the limited features and functionalities available for web apps on iOS; which in turn, is determined by Apple through rules that require all browsers on iOS to use its own browser engine, WebKit.
Apple SMS Investigation
Apple’s requirement that all mobile browsers on iOS use its WebKit browser engine also means that WebKit does not face any competition from rival browser engines on iOS.
Apple SMS Investigation
As a result of the Android Licence Agreements between Google and OEMs, Google’s Chrome is pre-installed, prominently placed, and set as the default mobile browser for many Android devices, creating barriers to entry and expansion for competing mobile browsers.
Google SMS Investigation
This can be thought of as the UK’s equivalent to the EU’s Digital Markets Act, although it has differences in how it is implemented as covered in this article. The DMCC (the written UK Act) mostly leaves it up to the CMA (the agency) to decide what rules are appropriate to impose; the DMA (the written EU Act) dictates it rules with significantly less room for flexibility
Firms with Strategic Market Status (SMS) designation will be required to adhere to one or more tailored conduct requirements (CRs). The DMCC Act provides a structured framework for the Competition and Markets Authority (CMA) to follow when implementing these requirements.
Non-compliance with a conduct requirement could result in substantial penalties, amounting to up to 10% of the company’s global turnover. It will likely take until the end of the year (9 months from initiation) to designate the first batch of SMS companies.
As readers may recall, the UK Competition and Markets Authority launched a Market Investigation Reference (MIR) into mobile browsers and cloud gaming on June 10th 2022.
From our extensive work in supporting the Mobile Ecosystems Study, we know the key reason the Market Investigation Reference into Browsers and Cloud Gaming was launched was to enable the free, open and interoperable ecosystem of the web to contest Apple’s and Google’s app stores, reducing costs for UK’s consumers and businesses. While regulators across the world were focused on app stores, the UK was the only regulator that was looking towards the web and web apps to solve these issues on mobile ecosystems. This aim was made clear by the opening statements of the Browsers and Cloud MIR:
We all rely on browsers to use the internet on our phones, and the engines that make them work have a huge bearing on what we can see and do. Right now, choice in this space is severely limited and that has real impacts – preventing innovation and reducing competition from web apps. We need to give innovative tech firms, many of which are ambitious start-ups, a fair chance to compete.
Andrea Coscelli - Chief Executive of the UK's Competition and Markets Authority
(emphasis added)
For example, ‘equivalence of access’ would need to include enabling third-party browsers using alternative browser engines to install and manage PWAs (rather than relying on WebKit to support parts of this process), including enabling mobile browsers using alternative browser engines to implement installation prompts for PWAs.
MIR - Provisional Decision Report
(emphasis added)
In the provisional decision report, the MIR team has opted not to use the powers of the MIR but instead to hand over its findings to the CMA who will use the DMCC as the enforcement and oversight mechanism.
In order to enforce any of the remedies of the MIR under the DMCC on Apple and Google, Apple and Google must first be declared SMS under the DMCC. To do this, the CMA needs to hear from you about your views on browsers, browser engines, and web apps; please consider responding to this request for comment.
]]>
Open Web Advocacy 2024 in Review2025-01-08T00:00:00Zhttps://open-web-advocacy.org/blog/owa-2024-review/
As 2025 begins, it's a perfect moment to reflect on 2024’s developments, achievements, and what lies ahead regarding regulators, browsers, and web applications.
Last year was incredibly busy, and together with you, we have made real tangible progress toward a more competitive browser and Web App ecosystem.
If there’s one key takeaway from 2024, it’s this: advocacy works. When those who love what makes the web amazing come together, we can achieve wonders!
If you’re new to Open Web Advocacy (OWA) we are a non-profit organization committed to pushing greater competition within the browser and Web App ecosystems. Our objectives are:
Ensuring fair and effective competition for browsers across all operating systems.
Enabling Web Apps to compete fairly and effectively with native apps, in particular by advocating for feature parity with native apps where technically feasible.
Our primary focus is to ensure what made the web great on desktop, happens for mobile. Users should be able to access web apps and websites freely, without the excessive control, fees, and restrictive interfaces imposed by gatekeepers. This vision for the future is one that drastically decreases the cost of development and increases the pace of innovation while enhancing functionality, security and privacy for everyone.
Imagine, a future where developers and businesses can write their software once, deploy to any device without the gatekeepers… this is a future worth fighting for.
If you love what we're doing and would like to support our work, please consider
making a donation.
OWA is a registered not-for-profit fighting for the Web against heavily financed gatekeepers
to ensure the future of Browser competition and Web Apps
Last year we worked extensively with multiple regulators, and our allies around the world towards our common goals. The core of our focus was in the EU with the implementation of the Digital Markets Act and the UK with the Browsers and Cloud Gaming Market Investigation Reference. Additionally, we participated in several technology and regulatory conferences to explain the critical issues that need to be addressed and how the web can fundamentally change the software industry if it was allowed to compete fairly.
In particular these three 2024 papers are worth a read for those interested in browser and Web App competition:
At times it can seem that work in the regulatory space is slow, but together with the developer community, critical advocacy from allies, and excellent work by key regulators we achieved some significant victories and tangible progress in 2024.
Out of all the things we achieved this year, the absolute biggest was saving mobile Web Apps and we couldn't have done it without the enormous support of the developer community and the hard work of the EU commission.
So what happened and why was this victory so critical in protecting the Web App ecosystem?
On 28th of January 2024, Apple broke all Web Apps in the EU in the iOS 17.4 beta, by converting all Web Apps to simply bookmarks which would then open in a browser tab ensuring that all local data would be lost, notifications would no longer work and the Web App would no longer work as a separate app.
Initially, they tried to keep it a secret. Extraordinarily, there was no mention of this in their DMA compliance plan, the iOS beta notes or the Safari beta notes. Given how detailed these typically are and the magnitude of the change, it is impossible that this was an oversight. Clearly Apple was attempting to sneak this past the developers, users and regulators to provide everyone minimal time to respond.
After 2 weeks, in the face of steadily increasing developer and media backlash, Apple was forced to rush out a statement where they confirmed they were deliberately breaking Web Apps and that it had been planned:
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 APls 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 align 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.
Apple (Since Deleted)
OWA and others in the industry recognized that if this change were implemented, it would almost certainly spell the end of mobile web apps. With the EU being such a critical market and significant concerns that Apple might replicate the change in other regions, the move would effectively end any future investment in the sector.
We, of course, had to act. We immediately informed the DMA team and then launched a series of surveys to demonstrate how detrimental this would be to businesses and users in the EU. We had over a thousand responses in a few short days and this allowed us to hand the EU excellent information about the immediate cost of Apple breaking Web Apps.
We then worked shifts around the clock to launch our incredibly successful open letter to Tim Cook. The letter gained worldwide support support and has had 4264 individuals and 441 organisations sign. Signatures include two European MEPs (Karen Melchior & Patrick Breyer); a number of significant EU companies such as social media platform Mastodon; and individuals (advocating in their personal capacity) who work for SwissLife, Tchibo, W3C, Mozilla, Google, Microsoft, Vivaldi, BBC, Financial Times, Red Hat, Oracle, Amazon, Wikimedia, Vercel, Netlify, Shopify, Spotify, AirBNB, Berlin University of the Arts, Open State Foundation - Netherlands, Cloudflare, Meta, Chase, Squarespace, Reddit, Atlassian, Maersk, Paypal, Salesforce, block, Adobe, ebay, Zynga, booking.com and thoughtworks; and many other developers and organisations from over 100 countries.
On the 1st of March 2024, Apple cancelled its plans to break Web Apps in the EU, issuing a statement:
UPDATE: Previously, Apple announced plans to remove the Home Screen web apps capability in the EU as part of our efforts to comply with the DMA. The need to remove the capability was informed by the complex security and privacy concerns associated with web apps to support alternative browser engines that would require building a new integration architecture that does not currently exist in iOS and iPadOS.
We have received requests to continue to offer support for Home Screen web apps in iOS and iPadOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU. This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS and iPadOS.
Developers and users who may have been impacted by the removal of Home Screen web apps in the beta release of iOS and iPadOS in the EU can expect the return of the existing functionality for Home Screen web apps with the availability of iOS 17.4 and and iPadOS 17.4 in early March.
Apple
We would like to say a massive thank you to the DMA team as Apple's decision is no doubt related to the investigation they had opened and our most heartfelt thanks to the thousands of developers and individuals who took the time to fill in our survey and sign the open letter. We are grateful for your help and no doubt will need it again. Know that your voices were heard and made a difference.
# Successfully pushed Apple to remove its problematic line about dual engine browsers
For 16 years, Apple has enforced a ban on third-party browser engines, limiting competition in the browser market. Now that this ban has been lifted in the EU, browser vendors must be allowed to gradually roll out their own engines through phased implementation and multi-variant testing. Deploying a new engine on an unfamiliar operating system is a complex task, requiring careful, incremental progress to identify bugs and performance issues.
As a result, it is essential that all browser vendors be allowed to ship dual engine browsers. That is, browsers that can use both the system provided WKWebView and their own engine within a single binary. However, Apple had added a rule in their contract to explicitly ban this:
This restriction lacks clear or reasonable justification and appears to conflict with the DMA, which allows API restrictions only when they are justified on strictly necessary and proportionate security grounds.
On October the 23rd, the contract was updated to remove that single line. Apple also announced the change in this blog post:
Developers of apps that use alternative browser engines can now use WebKit in those same apps. Apple - Blog on iOS 18.2
While this is a step forward, Apple still has other rules in place that make it difficult for browser vendors to port their own engine to iOS. For example, browser vendors are forced to ship it as a separate browser app for the EU, which means their users in the EU will not be automatically updated to the browser with its own engine. Browsers will then need to reacquire all of their existing users, asking them to switch to the EU-only version of the browser and uninstalling the existing one. This is a confusing and high friction process for users.
This will also need to be fixed to make it viable for browser vendors to ship their browsers in the EU. There are three main ways that Apple can fix this:
Allow browser vendors to use their own engine globally.
Allow browser vendors to ship a different binary in the EU under the same bundle id.
Provide a system flag to allow the browser vendor to know if we are allowed to use these APIs and their own engine. The browser will then use the APIs and their own engine in the EU but then use the WKWebView exclusively outside the EU. Apple also has the technical ability to block access to these APIs outside the EU.
Without implementing one of these solutions, the burden on browser vendors will remain excessively high, undermining competition in the browser market in the EU. We are of the opinion that no browser vendor will be willing to ship with this problem unresolved.
# Got Apple to let browser vendors test their own browsers
Astonishingly, Apple decided earlier this year to make it impossible for browser vendors to test their own browsers (that wished to use their own engine) if the developers were not physically located in the EU.
The Register has learned from those involved in the browser trade that Apple has limited the development and testing of third-party browser engines to devices physically located in the EU. That requirement adds an additional barrier to anyone planning to develop and support a browser with an alternative engine in the EU.
It effectively geofences the development team. Browser-makers whose dev teams are located in the US will only be able to work on simulators. While some testing can be done in a simulator, there's no substitute for testing on device – which means developers will have to work within Apple's prescribed geographical boundary. Thomas Claburn - The Register
This was clearly ridiculous. We had extensively covered and pushed for this issue to be resolved, and since the release of iOS 18.2, Apple now allows not only browser vendors, but all app developers (wherever they are in the world), to test their own apps which use APIs or functionality that Apple currently reserves for itself outside the EU.
However, there is still no solution proposed by Apple to allow web developers outside the EU to test and maintain their websites and Web Apps for EU consumers on third-party browsers which use their own engine. This is and will remain a significant barrier to browser competition on iOS.
Our proposal is that web developers outside the EU should be able to download test-versions of EU browsers via an Apple Developer Account for the purpose of testing their own products.
# Made Apple fix their trick of hiding the Default Browser Option if Safari was the Default
Earlier this year we reported on a deceptive pattern that Apple had hard-coded into iOS, which made it harder for users to change their default browser if your current default browser was already Safari.
UK Regulator's Screenshots of the Issue - Working Paper 5
Apple told MacRumors that Open Web Advocacy's allegation that Apple is misleading the Competition and Markets Authority (CMA) is inaccurate. Apple says it told the CMA that the design of the identified browser setting was changed in a recent software update. The design was apparently never intended to discourage users from setting third-party browsers as the default. Apple - Responding to MacRumours
Apple has declined to elaborate on what its purpose was (if it wasn’t to make it harder for users to switch browsers) and why they stated our initial report was false rather than that they had simply fixed the issue we had identified.
# Secured Hotseat Placement on the EU Choice Screen
If Safari is currently in the user’s Dock or on the first page of the Home Screen and the user selects a browser that is not currently installed on their device from the choice screen, the selected browser will replace the Safari icon in the user’s Dock or in the Home Screen Apple - About the browser choice screen in the EU (2024-08-19)
Previously, being selected as the default browser did not grant the hotseat. This means it is entirely possible, and in fact likely, that many existing users who have set a third party browser as their default browser will still have Safari or Chrome on certain versions of Android in the hotseat.
Only about half (52%) of people understand that their default browser is opened when they, for example, click on a link in an email or document.
Changes like this will not push the needle overnight, so what does success look like?
There are two forms of success in choice architecture. One is removing behaviour that is blatantly unfair or manipulative. The removal of the behaviour is a success in its own right, regardless of any outcome.
The second is in allowing space for new and smaller browser vendors to thrive. Even the most perfect choice screen will not wildly change user preference over night. The biggest names in browsers are the ones that will be picked the most and the browser of the operating system will still have a significant advantage. What choice screens need to do to succeed, is inform the user that they have a choice and create an opening for third-party browser vendors to get a foothold.
If third-party browsers managed to gain an additional 10% of the total market share on iOS or Android, that would be a resounding success.
There are still a vast amount of issues to fix here, and we will continue to work with regulators around the world until all these issues are fixed globally. A non-exhaustive list of the issues we are aiming to fix is below.
In the EU, the landmark Digital Markets Act came into force on 7th March 2024.
It contained 3 incredibly important passages for browsers and Web Apps.
First, prohibiting browser engines is banned:
Article 5(7) The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services. Digital Markets Act - Article 5(7)
(emphasis added)
Second, the DMA explicitly states why gatekeepers can not ban third-party browser engines: Gatekeepers should not be able to dictate the functionality of Web Apps:
When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsersand, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users. Digital Markets Act - Recital 43
(emphasis added)
Third, gatekeepers must provide access to all the same APIs that are available to the gatekeepers own apps and services. This access may be subject to strictly necessary, proportionate and justified security conditions:
Article 6(7) The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services.
The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper. Digital Markets Act - Article 6(7)
(emphasis added)
Finally the DMA comes with real teeth. It grants the Commission the power to fine gatekeepers found not to be in compliance up to 10% of global revenue, which in Apple’s case would be up to $39 billion USD per offence.
The Commission has opened a specification proceeding into Apple's interoperability request process. The proposed measures include increased upfront transparency of internal iOS and iPadOS features, timely communication and updates, fair and transparent handling of rejections and a more predictable timeline.
A proceeding has been opened into Meta for its recently introduced “pay or consent” model in the EU. The Commission is assessing whether this complies with the DMA’s requirement that gatekeepers secure user consent before combining or cross-using personal data.
However, despite the DMA being in force since March 2024, not a single browser vendor has been able to ship a browser using its own engine.
Two big barriers, not allowing browser vendors to test their own browsers outside the EU and preventing browser vendors from also using the WkWebView, have both been resolved.
The primary remaining barrier to this is Apple insisting that these browser vendors ship a new browser in the EU, rather than upgrade its existing one, forcing them to reacquire all their EU users from scratch.
Instead, transaction and overhead costs for developers will be higher, rather than lower, since they must develop a version of their apps for the EU and another for the rest of the world. On top of that, if and when they exercise the possibility to, for instance, incorporate their own browser engines into their browsers (they formerly worked on Apple's proprietary WebKit), they must submit a separate binary to Apple for its approval. What does that mean exactly? That developers must ship a new version of their app to its customers, and 'reacquire' them from zero. Alba Ribera Martínez - Deputy Editor at Kluwer Competition Law Blog
(emphasis added)
The United States v. Google LLC is a federal antitrust case brought by the Department of Justice (DOJ) against Google that started on October 20th, 2020. The suit alleged that Google had violated the Sherman Antitrust Act by illegally monopolizing the search engine market.
The DOJ has published a list of outlined potential remedies that they are seeking. The list is dense and the DOJ is considering a lot of different and overlapping remedies.
Of the over twenty five remedies that the DOJ are proposing, we are concerned by the significant potential harm to the Web from just two of the proposed remedies. They are: a total ban on revenue sharing with browser vendors in return for setting Google as the default search engine and a forced sale of Chrome by Google. These remedies strike at the heart of the web platform's funding model and will do unintended but severe damage.
This will be a major focus of OWA in 2025 due to its potential to severely undermine our goals and damage the open web. Our aim in relation to this case is to ensure that the DOJ addresses Google’s monopolistic practices effectively while safeguarding the web as a vital resource for billions of consumers and millions of businesses around the world. If your business relies on the web and are concerned about these two remedies please contact us.
The DOJ is expected to deliver their updated remedies on March 7th 2025 and a remedies trial is expected to be held in April.
In 2024 the Department of Justice (DOJ) launched a lawsuit against Apple arguing that they have illegally monopolized the US smartphone market. The government claimed Apple broke the law by maintaining a closed ecosystem for the iPhone in pursuit of profits and at the expense of consumers and innovation.
The essence of the DOJ case is that Apple has made iPhones worse for US consumers in order to increase lock-in, reduce interoperability and block competitors from competing. The DOJ also argues that Apple uses security and privacy as a shield to justify its anticompetitive conduct.
Apple wraps itself in a cloak of privacy, security, and consumer preferences to justify its anticompetitive conduct. Indeed, it spends billions on marketing and branding to promote the self-serving premise that only Apple can safeguard consumers’ privacy and security interests. Apple selectively compromises privacy and security interests when doing so is in Apple’s own financial interest DOJ vs Apple
The DOJ has a number of examples of how Apple has done this, including discussing Apple's ban on third party browser engines and how lack of visibility for Web Apps on iOS makes them unviable.
Developers cannot avoid Apple’s control of app distribution and app creation by making web apps—apps created using standard programming languages for web-based content and available over the internet—as an alternative to native apps. Many iPhone users do not look for or know how to find web apps, causing web apps to constitute only a small fraction of app usage. Apple recognizes that web apps are not a good alternative to native apps for developers. As one Apple executive acknowledged, “[d]evelopers can’t make much money on the web.” Regardless, Apple can still control the functionality of web apps because Apple requires all web browsers on the iPhone to use WebKit, Apple’s browser engine—the key software components that third-party browsers use to display web content. DOJ vs Apple
(emphasis added)
It is worth noting that one of the reasons that many users on iOS are unaware of how to install Web Apps is Apple has for years refused to implement install prompts and hidden away the mechanism for installing them on the share menu. At the same time, Apple has gone to great lengths to make it easy to link to and install Apple’s own iOS app store native apps from Safari.
This case is in its early stages and will likely run for several years.
This can be thought of as the UK’s equivalent to the EU’s Digital Markets Act, although it has differences in how it is implemented as covered in this article. The primary difference is that the DMCC is less proscriptive than the DMA and allows the CMA to impose bespoke conduct requirements on each SMS firm.
Firms with Strategic Market Status (SMS) designation will be required to adhere to one or more tailored conduct requirements (CRs). The DMCC Act provides a structured framework for the Competition and Markets Authority (CMA) to follow when implementing these requirements.
Non-compliance with a conduct requirement could result in substantial penalties, amounting to up to 10% of the company’s global turnover.
It will likely take till towards the end of the year (9 months from initiation) to designate the first batch of SMS companies.
As readers may recall, the UK Competition and Markets Authority launched a Market Investigation Reference (MIR) into mobile browsers and cloud gaming on June 10th 2022.
From our extensive work in supporting the Mobile Ecosystems Study, we know the key reason the Market Investigation Reference into Browsers and Cloud Gaming was launched was to enable the free, open and interoperable ecosystem of the web to contest Apple’s and Google’s app stores, reducing costs for UK’s consumers and businesses. While regulators across the world were focused on app stores, the UK was the only regulator that was looking towards the web and web apps to solve these issues on mobile ecosystems. This aim was made clear by the opening statements of the Browsers and Cloud MIR:
We all rely on browsers to use the internet on our phones, and the engines that make them work have a huge bearing on what we can see and do. Right now, choice in this space is severely limited and that has real impacts – preventing innovation and reducing competition from web apps. We need to give innovative tech firms, many of which are ambitious start-ups, a fair chance to compete.
Andrea Coscelli - Chief Executive of the UK's Competition and Markets Authority
(emphasis added)
When we last wrote about this investigation, we were concerned that the MIR might fail in its goal of allowing third party browsers to enable effective competition from Web Apps and that the focus on web apps had been lost.
Specifically we were concerned there was no remedy that would allow browsers to install and manage web apps using their own engine. That is Apple would be able to lock all browsers (including ones with their own engine) into using their current WebKit implementation of installed Web Apps.
We are delighted to say that the MIR team has listened to both us and all of the many many businesses and web developers who wrote in. A huge thank you to every developer and business that took the time to write in and explain their concerns, it really makes a difference!
For example, ‘equivalence of access’ would need to include enabling third-party browsers using alternative browser engines to install and manage PWAs (rather than relying on WebKit to support parts of this process), including enabling mobile browsers using alternative browser engines to implement installation prompts for PWAs.
MIR - Provisional Decision Report
(emphasis added)
The provisional decision report is exceptionally long but worth a read if you have time.
Overall we support the vast majority of the proposed remedies and believe that the MIR team have done an incredible job given the vast array of complex issues related to browsers and web apps that they have tackled. We do have a number of concerns that we will cover in more detail in future blog posts but which are contained in our full response paper and our remedies response paper for those who wish to read about them now.
In the provisional decision report, the MIR team has opted not to use the powers of the MIR but instead to hand over its findings to the CMA who will use the DMCC as the enforcement and oversight mechanism.
The MIR team has a statutory deadline of March 16th 2025 to publish their final report.
The bill aims to promote fair and free competition on smartphones by preventing large tech companies from abusing their position as providers of platforms to block or advantage their own services.
Violators will face fines equivalent to 20% of the domestic revenue of the service that violated the law. The rate of the fine can be increased to 30% for repeated violations.
The final bill contains a number of interesting articles relevant to browsers and Web Apps:
Banning browser engines is prohibited.
Must share APIs and services of the operating system to the same level as the services used by the designated providers. Justifiable measures may be applied.
Designated providers shall make it easy to change the default settings of the operating system.
Designated providers shall provide a choice screen for browsers.
When a designated business operator sets or changes the specifications, sets or changes the conditions for use, it must take necessary measures, such as securing a period for the business operator specified in each item to smoothly respond to the measure, disclosing information, and establishing a necessary system, as specified by the Fair Trade Commission rules.
The code of conduct for mobile OS services could require Designated Digital Platforms to allow third-party browser engines to be used on their mobile OS. This could allow third-party providers of browsers and web apps to compete on their merits.
We also consider that the additional competition measures should include the ability to provide third-party providers of apps and services with reasonable and equivalent access to hardware, software and functionality through their mobile OS.
The Australian Treasury department is conducting consultation on the proposal paper and submissions can be made until 14 February 2025.
# Advocating for a Fairer and More Competitive Web in 2025
2025 promises to be a pivotal year, making it more important than ever for both developers and consumers to have strong advocacy for browser and Web App competition. We sincerely thank everyone who generously contributed their time and expertise, whether through drafting or reviewing regulatory submissions, enhancing and building our website, engaging in detailed discussions, providing invaluable feedback, or participating in conferences and meetings; and especially those who helped provide financial support in 2024. You made the web a fairer, more competitive and more exciting platform.
A special thank you goes to startsmall for their exceptionally generous donation in 2023, which continues to fund a significant portion of our work today.
If you have the opportunity, please join us in 2025!
If you love what we're doing and would like to support our work, please consider
making a donation.
OWA is a registered not-for-profit fighting for the Web against heavily financed gatekeepers
to ensure the future of Browser competition and Web Apps
]]>
iOS age restriction blocks all browsers except Safari, breaks choice screen2024-11-15T00:00:00Zhttps://open-web-advocacy.org/blog/ios-age-restriction-blocks-all-browsers-except-safari-breaks-choice-screen/Share and join the conversation: X/Twitter, Mastodon, LinkedIn and Bluesky.
Note: Throughout this article, references to iOS also encompass iPadOS.
Apple is currently failing to comply with its obligations under Article 6(3) of the Digital Markets Act (DMA) regarding the provision of the browser choice screen. The iOS browser choice screen is currently broken for any user with age restrictions for apps enabled, effectively preventing them from selecting any browser other than Safari.
Furthermore, Apple has been preventing the use or installation of third-party browsers when age restrictions for apps are enabled. This is despite the fact that Apple has exempted Safari from these restrictions and that parental content restrictions for the Web are handled by an entirely separate mechanism.
While all browsers on iOS, including Safari, are rated 17+, Safari benefits from two exemptions:
As a pre-installed browser, Safari doesn't require users to actively download it.
Apple has implemented specific code that exempts Safari from age restrictions, allowing it to be displayed and opened despite being rated 17+. All other browsers are hidden when age restrictions are applied.
We estimate that this issue impacts 11-15% of EU iOS users, significantly undermining the effectiveness of Apple's compliance with Article 6(3).
Finally, Apple has yet to provide an API for third-party browsers using their own engines to support and interoperate with parental control features for web browsing, currently implemented via the WkWebView.
To rectify this situation and be compliant with the DMA we believe that Apple should:
Remove the 17+ age rating from browser apps.
Allow all browsers listed on the choice screen to be selectable, installable, and usable even if age restrictions for apps is enabled.
Create an API that empowers third-party browsers using their own engines to effectively support parental control features.
Apply age restrictions for apps equally to Apple’s own apps.
On iOS, there are two independent parental supervision settings available to parents:
Web Content Restrictions
This allows parents to restrict their childrens’ access to adult websites. This setting is respected by all browsers across iOS (Safari, and all competing third-party browsers). Currently this is implemented via the WkWebView and thus is automatically applied to all browsers that are currently available on iOS.
Apple will need to provide an API to third-party browsers using their own engine to allow them to effectively support this feature and for Apple to comply with their Article 6(7) obligations.
Age Restrictions for Apps
This allows parents to restrict their childrens’ access to apps that are rated above the age-limit they've chosen. So if an app in the App Store is rated 17+, and parents set the age restriction to <17, this effectively makes it so that their child cannot download apps that are 17+, or if these apps are already downloaded, the child can't use/launch these 17+ apps, as their icons are hidden.
On Apple's App Store, all browsers (including Safari, despite it being preinstalled) have a 17+ age restriction, under the justification that they provide "Unrestricted Web Access". So if parents set app age restrictions on their children's devices, they cannot download or launch already installed competing third-party browsers. However, as discussed in the introduction, Safari is exempted from this.
We would like to clarify that on iOS, at the moment, parents are free to set age restrictions for apps to 4+ years old (i.e. only apps that Apple believes are suitable for 4 year olds - 8 year olds), yet still allow unrestricted internet access to all websites. These two mechanisms are entirely independent of each other.
To emphasize the distinction, the age restrictions for apps setting has nothing to do with unrestricted internet access (i.e. to adult websites etc) — the restriction only affects which apps young users are allowed to download or use.
This issue with age restrictions for apps also breaks the browser choice screen. We've discovered that for iOS users with age restrictions enabled, the browser choice screen is completely broken:
The screen displays a list of browsers to choose as the new system default.
Upon selecting a third-party browser other than Safari, the system initiates a download process.
Once the download reaches 100%, the screen becomes unresponsive, trapping the user without any further actions or navigation options. The user's only choice is to quit the choice screen.
Quitting the screen reveals that the chosen browser has not been installed, leaving Safari as the only available browser.
This effectively breaks the choice screen and denies that choice for all European Residents who are iOS users with age restrictions for apps turned on.
We do not have precise figures on the number of users that switch on age restrictions for apps but the following pieces of data give us a rough idea:
This survey states 39% of parents report using parental controls for blocking, filtering or monitoring their teen’s online activities.
This study states 59.5% of them actively use parental controls on their child’s iPhone.
This study states 72% use parental controls to restrict time on devices.
By combining the figures we can estimate that Apple is blocking its choice screen from working for approximately 11-15% of EU residents who use iOS, which is a significant percentage of the population.
Apple effectively prevents users with age restriction for apps turned on from being able to download and use competing third-party browsers.
Yet, on that same device, despite the fact that Safari itself has the same 17+ age restriction in the App Store, users can continue to use Safari without any restrictions or issues, and so can continue to access the web through Safari with no restrictions, including adult websites.
Conversely, if the parent turned off age restriction for apps but enabled web content restrictions then adult websites would be blocked in all browsers on iOS.
This is due to the fact that, as we mentioned earlier, the web content restriction settings are in fact independent from the age restriction settings.
Currently, Safari having an exception effectively prevents all third-party browser competition on iOS for a significant segment of the European population (approximately 11-15% of EU iOS users). This practice not only significantly undermines the effectiveness of the browser choice screen but also more broadly stifles browser competition. In the next 5 - 10 years, the effect of these restrictions could mean the majority of young users will grow up without being aware of alternative browsers or the features they offer.
Finally, as an example of how this behavior could impede third parties contesting Apple’s app store, this will likely have a major impact on the online gaming industry. Once third-party browser engines start to make their way onto iOS, it will pave the way for an explosion in the online gaming industry. We can already see this from the vast number of online cloud-streaming game services that rely on web technologies.
By gating young users' access to alternative browsers and browser engines behind an age restriction, Apple effectively forces the future of online gaming to take place in their browser, with its limited number of APIs and features, which nudges developers to instead build native apps and users to choose native games from which Apple can and will profit greatly from.
# 5. Apple Agrees that Users should have at least One Browser
When attempting to delete the only browser on iOS, Apple will display the following message:
Download Browser App
At least one browser app is required on iPhone. Download another browser app, then you can delete “Safari”.
[Open App Store] [Cancel]
Apple's error message for deleting only browser.
However, Apple currently maintains this requirement by granting Safari a special exemption from its own age restrictions for apps. This exemption highlights the inconsistency in Apple's approach, as it recognizes the need for browser availability while simultaneously imposing barriers on third-party browsers.
It's worth noting that if a user installs a third-party browser, deletes Safari, and then enables age restrictions, they will be left without any browser options, as the icons for all the third-party browsers will be removed and it will be hidden from search. This scenario further emphasizes the limitations of Apple's current system and the need for a more consistent and equitable approach.
# 5. Apple's Inconsistent and Poorly Designed Age Ratings
Apple has the following age rating settings available:
Apple's age rating settings and explanation.
Bizarrely, Apple lacks an "Everyone" or G rating. This could be a strategic move by Apple to potentially claim that all apps are intended for users aged 4 and over. This approach might shield Apple from potential legal liabilities arising from younger children's use of apps.
They also explain their age rating system on their website. At the end, they snidely claim that adult content is only accessible on alternative app marketplaces or websites within the European Union.
Possibly this is an attempt to cast alternative app stores as being unsavory but is odd in the context of 18+ (depending on country) films such as “Deadpool & Wolverine” being billion dollar box office hits, immensely popular and available on the iOS App Store via Disney+.
Disney Plus has a 4+ rating, yet one of the first things advertised on its app store page is the Deadpool & Wolverine film, which is rated for 14+ and 18+ (varies by country).
Teaching App for Babies and Kindergarten with 4+ rating
For example, this app is marketed as being to help “2,3,4 and even 5 year olds” learn. Despite this it has a 4+ rating (the lowest rating that Apple will allow). It is not clear why apps like this should not have a G rating and if they are unsuitable for under 4 year olds, why they should be allowed to market themselves as being for that demographic.
Again, adult content is not filtered by the age rating setting for apps. Any apps that contain links (for example messaging and social media apps) will not be blocked by the age rating setting for apps, nor does this affect their age rating.
For example adult websites can be visited in apps with low age ratings (such as Instagram which is rated 12+) by using Apple’s in-app browser SFSafariViewController:
A link being opened in a 12+ app to an adult website.
This highlights why age ratings on apps with links to the web doesn’t make sense: it is the web content restriction setting which actually prevents in-app browsers from visiting known adult websites. The age rating setting is ineffective here, as can be seen in these screenshots.
Disney+ is 4+ but Netflix and Apple TV are 12+. However, both contain between 15-18+ content and all three have built-in parental controls.
Most messaging apps are 12+, some are 17+ but iMessage and Facetime are 4+ despite all messaging apps having the ability to transmit 18+ content.
Large numbers of apps that should be G rated are assigned a 4+ rating.
# 5.5. More Apple Apps Outright Ignoring the Rating System
iMessage, Facetime, Apple Books and Apple TV all outright ignore the age restrictions for apps. That is, unlike other apps, they are not hidden and disabled when users turn on age restrictions for apps to an age below their rating.
iMessage and Facetime (both rated 4+ but having the ability to display 18+ content) will continue to function if the age restriction for apps is set to “Don’t Allow” (a setting that seemingly disables all apps), despite being listed on the app store with age ratings.
This is still problematic as Netflix also has such controls, but setting the age restrictions for apps to 4+ will remove the icon for the Netflix app and make it impossible to open it. This is clearly an unfair, unhelpful and anti-competitive way to implement age controls.
A more sensible solution, which would actually help parents who want to use such a setting, would be to:
Have a G-rating (or Everyone rating).
Acknowledge that the app store has 18+ content, and where necessary assign that rating to apps. Simply pretending it does not exist is not helpful. While films and TV shows vary in rating from country to country, to our knowledge Apple does not block these TV shows/films in countries where they are rated 18+.
Let apps have the lowest rating of all (or as much as reasonably possible) of the content on the app can be filtered using parental controls within each app.
Apply the ratings consistently to Apple’s apps. If that is a significant issue, then it's an indication the age rating system is not designed properly.
Have an allow and block list (like for the web content restriction setting) so that parents can individually allow or block apps that Apple has inappropriately or incorrectly rated.
As it is, Apple, by their misdesign of the system, is not only harming competition, but is actively preventing parents from using these age restriction controls by making them difficult to use. A parent, upon discovering that their Netflix app will no longer function, despite it being set to only allow childrens content, might avoid using the setting altogether.
In order to be in full compliance with Articles 6(3) and 6(7) of the DMA in relation to this issue, Apple must take the following steps:
Remove Age Ratings from Browsers
Given that parental controls for web browsing operate independently of app age ratings, Apple should remove age ratings from browsers. The 17+ age rating on browsers serves no significant purpose, exceptto hinder competition from third-party browsers, as evidenced by Apple's exemption of Safari from these restrictions.
All browsers that support Apple’s existing system of web content restrictions (currently all browsers on iOS, as it is implemented via the WkWebView) should be allowed with G rating or given a 4+ rating. EU users should have the option of setting both “web content restrictions” and “age restriction for apps” for their children and still be able to use third-party browsers.
Compliant Browser Choice Screen
The browser choice screen must be accessible to all EU residents regardless of their age, or whether they have age restriction for apps turned on, and the users must be able to select, install and use any browser from that choice screen. This must be fixed before the general roll out of the updated choice screen, or in the case it is not, be rerun on all of those devices after the fix has been applied.
Third-Party Browser Support for Parent Controls
Apple should develop an API that allows third-party browsers using their own engine to effectively support parental control features. This should be relatively straightforward for Apple to implement.
Age Restrictions for Apps should apply equally to Apple’s own Apps
Apple should not exempt its own apps from the setting. Where this causes problems Apple should carefully redesign the system. Fixing the system, but doing so only for Apple’s apps, is not acceptable under the DMA.
By compelling Apple to implement these remedies, the EU Commission can help ensure equal treatment of all browsers and remove these barriers to choice. This benefits individual consumers by allowing them to make informed decisions about the software they use. Additionally, it stimulates innovation and competition among browser vendors, leading to a better user experience and a more diverse digital ecosystem.
]]>
Apple implements six of OWA's DMA compliance requests2024-10-25T00:00:00Zhttps://open-web-advocacy.org/blog/apple-implements-six-of-owas-dma-compliance-requests/TLDR: Apple has fixed 6 important issues with allowing browsers and Web Apps to compete on iOS (including allowing browser vendors to test their own browsers outside the EU) but a massive list of issues remain to be fixed in order to be in compliance with the DMA.
Most importantly, there is no indication that Apple will allow Web Apps to run in a browser's own engine despite the newsreports OR that browsers will be able to use their own engine without being forced to lose their existing customers.
Readers Note: When you see the term "EU Only" in this article it's important to recognize this as a reflection of Apple's anti-competitive practices. Such measures should ideally be implemented on a global scale, promoting fair competition for all their users in all jurisdictions.
Apple has announced a series of changes in iOS 18.2 related to third-party browsers in the EU.
Following feedback from the European Commission and from developers, in these releases developers can develop and test EU-specific features, such as alternative browser engines, contactless apps, marketplace installations from web browsers, and marketplace apps, from anywhere in the world. Developers of apps that use alternative browser engines can now use WebKit in those same apps.
Apple - Blog on iOS 18.2
Due to Apple’s 16 year ban of third-party browser engines, browser vendors will need to gradually phase in their own engines over time using phased roll-outs and multi-variant testing. Deploying an engine to a new operating system is a complex process and has to be done in a slow and methodical manner to identify bugs and performance issues.
As a result, it is essential that all browser vendors be allowed to ship dual engine browsers. That is, browsers that can use both the system provided WKWebView and their own engine within a single binary. The binary would only contain the code for a single engine, the one the browser vendor provides, since the WKWebView is an operating system provided component.
Browser vendors also need to be allowed to keep their existing EU users. Allowing dual engine browsers also makes this simple by letting browser vendors simply toggle their own engine on or off depending on if Apple allows them to use it in a particular jurisdiction.
However, Apple had added a rule in their contract to explicitly ban this:
To our knowledge there was no reasonable or rational reason to impose this restriction. It would also appear to be in violation of the DMA which only allows APIs to be restricted on the grounds of strictly necessary, proportionate and justified security grounds.
On October the 23rd, the contract was updated to remove that single line.
Apple also announced the change in this blog post:
Developers of apps that use alternative browser engines can now use WebKit in those same apps.
Apple - Blog on iOS 18.2
Importantly this means that browser vendors currently need two browsers. A Webkit only one for outside the EU and their existing EU customers, and a new one that uses their own engine (and can now also use the WebKit engine).
# Allowing Browser Vendors to Test their own Browsers Outside the EU
Astonishingly, Apple decided earlier this year to make it impossible for browser vendors to test their own browsers if the developers were not physically located in the EU.
The Register has learned from those involved in the browser trade that Apple has limited the development and testing of third-party browser engines to devices physically located in the EU. That requirement adds an additional barrier to anyone planning to develop and support a browser with an alternative engine in the EU.
It effectively geofences the development team. Browser-makers whose dev teams are located in the US will only be able to work on simulators. While some testing can be done in a simulator, there's no substitute for testing on device – which means developers will have to work within Apple's prescribed geographical boundary.
Thomas Claburn - The Register
This was clearly ridiculous. With iOS 18.2, Apple now allows not only browser vendors but all app developers (wherever they are in the world) to test their own apps which use APIs or functionality that Apple currently restricts to the EU.
However, there is still no solution proposed by Apple to allow web developers outside the EU the ability to test and maintain their websites and Web Apps for EU consumers on third-party browsers which use their own engine. This is and will remain a significant barrier to browser competition on iOS.
Our proposal is that web developers outside the EU should be able to download test versions of EU browsers via an Apple Developer Account for the purpose of testing their own products.
In August Apple announced that they were making this change for the EU. Now, this change is being rolled out globally. Our assumption is that Apple struggled to explain to other regulators worldwide why this change, already implemented for EU users, should be withheld from global users.
# Browsers can Detect if Default Browser (EU ONLY)
Browsers can now detect if they are the default browser once per year.
In iOS 18.2 and iPadOS 18.2, a new API will allow a browser app to check if it is currently the default browser app. To reduce the likelihood that users will face continuous requests to set a browser as their default, this API will only tell the browser app if it is the default once per year. This API will be further documented in an upcoming beta release of iOS 18.2 and iPadOS 18.2.
Apple - Default Apps
While there is some rationale for preventing browsers from repeatedly asking users, it is not clear that it is necessary to limit the ability to check the current status. Apple has for example felt there is no need to add a limit on the number of times a native app can check if they have permission to use notifications.
We’ll be checking in with the browser vendors and pro-consumer groups to see what they think of the once per year limit, to work out our own opinions as to whether this is reasonable consumer protection measure or if it’s simply anti-competitive. Safari pulls in $20 billion USD annually for Apple and 14-16 percent of Apple's annual operating profits, so any decisions like this have to be examined with a fine-tooth comb.
# Prompt for Default Browsers missed in Previous Choice Screen to be Placed in the Hotseat/HomeScreen (EU ONLY)
If Safari is currently in the user’s Dock or on the first page of the Home Screen and the user selects a browser that is not currently installed on their device from the choice screen, the selected browser will replace the Safari icon in the user’s Dock or in the Home Screen
Apple - About the browser choice screen in the EU (2024-08-19)
One issue with this, which we wrote about at the time, is it does not apply to browsers which are already installed. Apple needed to update this to move already installed browsers onto the hotseat to replace the Safari icon when it had been selected on the choice screen.
Apple have now update the policy with the following relatively complex paragraphs:
If Safari is currently in the user’s Dock or on the first page of the Home Screen and the user selects a browser that is not currently installed on their device from the choice screen, the selected browser will replace the Safari icon in the user’s Dock or in the Home Screen. If the user selects a browser that is currently installed on their device from the choice screen but not on the first page of the Home Screen or the Dock, the selected browser will replace the Safari icon in the user’s Dock or in the Home Screen.
If Safari is currently in the user’s Dock or on the first page of the Home Screen and the user had previously selected another other browser as their default from the choice screen before updating to iOS 18.2, they will be prompted once upon first launch of Safari about whether they want to swap Safari’s icon with the icon of their default browser. This is only if their default browser is not on the first page of the home screen or the Dock.
Apple - About the browser choice screen in the EU
This means that any browser chosen on the choice screen will replace Safari on the dock/first home screen if it is there.
For browsers that were already installed prior to the previous choice screen, chosen as default on the choice screen (and which Apple decided not to move onto the dock/first home screen), these browsers will now prompt the user if they would like to swap with Safari’s icons location on first launch of Safari.
Prompting the user when they are trying to open Safari feels like an attempt to get the user to dismiss the prompt, as they are likely midway through a task; and it’s hard to see a reason for this other than an anti-competitive attempt to add friction to the user switching which browser they primarily use. This prompt should happen as part of the iOS 18.2 update process.
Apple will now let EU users uninstall Safari. This is psychologically important as it indicates to users that Safari is just another app on their phone that can be uninstalled and replaced, just like any other non-Apple app.
This is a change that is required by the DMA and that we argued in favour of earlier this year. Importantly, the WKWebView and SFSafariViewController should be treated as system components, and it should not be possible to uninstall them.
# Browsers still can't install Web Apps powered by their Own Engine
With the release of the first beta of iOS 18.2 to developers on Wednesday, Apple has published documentation for a new API that will let third-party browsers add web apps to the iPhone Home Screen using their own custom engine. This means that the entire web app experience will run using the same engine as the browser through which it was added.
Of course, there’s a catch. Currently, only web browsers distributed in the EU can have a custom engine. In the rest of the world, Apple still requires web browsers for iPhone and iPad to use Safari’s WebKit. Unsurprisingly, the new API for web apps is also only available in the EU.
Filipe Espósito - 9to5mac (emphasis added)
When we first saw the article headline we were incredibly excited, as this would finally be a key step into unlocking Web Apps. Web Apps are amazing because you only have to code them once, they work on every device, have significantly better security, and don't require you to pay excessive rents to gatekeepers.
However, having looked through Apple's documentation we believe this functionality won't allow third-party browsers to install web apps powered by their own engine, and will simply continue to exclusively offer Apple's WebKit based Web Apps in contravention of the DMA.
We have contacted Filipe Espósito from 9to5mac to request that he verify this statement with Apple and the other major browser vendors. At the time of publishing this article, we have yet to receive a response.
# Browser Vendors are still Obligated to Ship a Brand New App
Apple has chosen to restrict browser competition on iOS to the EU. Apple’s actions seek to force third-party browser vendors to build, develop, and maintain two versions of their apps for iOS while Apple’s own Safari bears no such costs.
Apple’s rules appear to force browser vendors to ship a brand new version of their app in the EU, rather than update existing apps to use their own engines. This will cause browser vendors to lose existing customers, as consumers will need to manually download the new browser.
This complexity and friction is a direct result of Apple’s own anti-competitive actions over the past 16 years. Apple’s insistence that competitors will be allowed to compete on a level playing field (with their own engines) only in the EU is already a high burden, and this rollout plan would levy additional transition costs on competitors. It is reasonable and proportionate that Apple takes steps to mitigate the damage they appear intent on causing.
Forcing browser vendors to ship two distinct products in Europe will lead to end user confusion and significant harm to these browser vendors. We do not believe that such an approach would be either fair or compliant with the DMA.
Apple should not be forcing browser vendors to reacquire existing users. Apple will need to implement a solution where browser vendors can use their own engines and keep their existing EU users.
Absent the real good faith solution of just allowing browser competition globally, there remains a simple solution: to simply allow browser vendors to ship their browsers globally under a single bundle ID with both Webkit and their own engines and let them know if that user is allowed to use the browser’s own engine with a true/false environment variable or equivalent.
Additional complexity and questions arise when users move in and out of the EU, will their browser continue to work when they are on holiday? How does data transfer work (cookies, Indexeddb, localstorage etc) internally between the WebKit version and the browsers own engine’s version. These are challenging issues that arise from Apple's reluctance to address anti-competitive behaviour except in jurisdictions where they are compelled to do so.
While today's news are important steps to allowing fair and effective browser and web app competition on iOS, a great many DMA compliance issues remain, including:
The EU Commission seems to be a slow-moving, but unstoppable, force. Despite the DMA having no legal power outside of the EU, this is already having a global impact with beneficial changes being exported worldwide such as Apple allowing game emulators and the new fairer centralised defaults screen.
When Apple said that iPhone owners in the EU would be able to set new default apps for things like calling and messaging, it sounded a lot like only people in the EU would get that option.
That’s not the case
[...]
But the big stuff, like support for alternative app stores and browser engines, has mostly been confined to the EU. A side effect is that a European iPhone was starting to look quite a bit different from one in the US, which was weird. But by spreading some of these new options across borders, Apple will maintain better consistency in its product. At the very least, it’s a little more fun.
Allison Johnson - The Verge
We wholeheartedly agree with the Verge, more competition and more ability for developers to innovate is more fun and, most importantly, it’s what is best for consumers.
]]>
It's time for a fairer, more competitive app ecosystem2024-10-24T00:00:00Zhttps://open-web-advocacy.org/blog/its-time-for-a-fairer-more-competitive-app-ecosystem/
Today, together with many others, we have co-signed this important letter addressing the urgent need for DMA enforcement.
The Digital Markets Act (DMA) aims to restore contestability, interoperability, choice, and fairness to digital markets within the EU. These fundamental principles of a well-functioning digital market have been compromised by the excessive power gatekeepers exert through their control of "core platform services."
The lack of competition in mobile ecosystems is fundamentally structural. Gatekeepers wield immense power due to the security model upon which these devices are built. Traditionally, on operating systems like Windows, macOS, and Linux, users can install any application they choose without interaction from the operating system gatekeeper, either by the business or the end user. Users can then grant these programs the necessary permissions to perform their desired functions.
While restricting what applications can do, such as limiting their access to certain APIs behind user permissions, is not inherently anti-competitive and can offer legitimate security benefits, its implementation on mobile devices is both self-serving and significantly damaging to competition in its current form.
This anti-competitive behaviour, hindering both browser and Web App competition, has and continues to cost consumers billions of dollars annually.
This is not an exaggeration; if the Web were able to compete fairly and effectively with native app stores, these gatekeepers would not be able to demand a 30% cut of all third-party software. Gatekeepers obtain this cut not through merit but simply by blocking all alternative means of running third-party software, such as Web Apps.
The harm extends beyond these taxes extracted through lock-in. It also damages the ecosystem in four other key ways:
Increased development costs
The ability to block competitors or entire categories of apps
Higher costs and friction associated with market entry, leading to fewer apps
Deprivation of new mobile device ecosystems from a library of apps, blocking a new competitor to iOS and Android from emerging.
The DMA was passed into law on 1st of November 2022 and its grace period for gatekeepers ended on March 7th 2024, more than 6 months ago. Despite this, gatekeepers (in particular Apple) are still not fully complying with either the letter or spirit of the DMA.
For this reason we are adding our voice to many others asking for a fairer, more competitive app ecosystem. Enforcing the DMA is the quickest way to get there.
We urge MEPs of the ECON and IMCO Committees to hold the gatekeepers accountable for compliance with the DMA.
]]>
Interop 2025 must drop secret vetos2024-10-10T00:00:00Zhttps://open-web-advocacy.org/blog/interop-2025-must-drop-secret-vetos/TLDR: Interop uses secret vetos, mobile NOT included in interop scores, Critical Safari scroll issues need fixing.
The voting process for Interop proposals is done in secret and each browser vendor involved can veto any feature without any transparency. Browser Vendors can sift through interop proposals and exclude items they believe are too difficult or don’t match their internal corporate goals. This is bad for the web and against the principle of openness and transparency that web standardization efforts rely on.
We propose that any votes or vetoes are made public with attribution, and any reasons for not proceeding with a particular feature are posted in the github issue along with attribution.
Interop is a collaborative project between browser vendors to reduce compatibility issues between browsers so the code we write works the same on all devices and all browsers.
The web is amazing. It makes collaborating, learning, and connecting easy for billions of people, because it’s intentionally designed to run on radically different devices.
It’s your job as a web developer to ensure your project works in every browser and for every user — and that can be hard to do. It’s a far easier undertaking when browsers have identical implementations of the web technology you use.
Webkit blog on the aim of Interop(emphasis added)
We believe that standards based efforts between browser vendors such as Interop should be transparent and public.
As mentioned above the current interop veto process is secret, leading to lack of transparency over why issues are not included or not included.
This lack of transparency has already been negatively received by developers and has been a source of mistrust and dissatisfaction with the Interop process:
That's it? That's the response to what is, by several times, the most requested feature in Interop 2024? No explanation for rejecting the feature that got 4.5x more support than the runner-up? Really?
Tibet Tornaci
A more open voting process ensures that decisions are made in the best interest of the broader developer and user community, helping to ensure that the web evolves in a way that is fair, inclusive, and sustainable.
Currently the Interop process misleadingly implies that the scores cover mobile browsers.
Given that mobile devices make up the vast majority of all personal computers and accounts for the majority of global web traffic, the test results for mobile are significantly more important than the desktop results.
We believe that Interop 2025 should include:
Building and Running Mobile Test Harnesses for WPT
The inability to reliably block body scroll in Safari/Webkit and have a consistent scrolling experience across browsers on mobile devices is a very significant long-standing issue which greatly increases the difficulty of building advanced user interfaces and remains a significant compatibility issue between browsers.
This is critical to building native-like or more complex interfaces on iOS.
This issue isn’t posted by OWA but is an important one to allow for improved browser testing.
WebDriver BiDi is a new protocol for browser automation. It extends the “classic” WebDriver protocol by introducing bidirectional communication. In place of the strict command/response format of WebDriver, this permits events to stream from the browser to the controlling software, better matching the evented nature of the browser.
Primarily this will lead to better testing for browsers and hopefully less bugs for the rest of us. It is also the only thing that will allow for testing of some of the more advanced browser features.
Please 👍 and/or comment on these tickets. If you have expertise or knowledge that will improve these issues please either email us or comment on the issue.
]]>
Stuart Langridge: The Mazy Web2024-10-08T00:00:00Zhttps://open-web-advocacy.org/blog/stuart-langridge-the-mazy-web/
If you have a spare half hour, we highly recommend listening to Stuart Langridge's insightful and eloquent talk about why the open web is special. Stuart shares his passion for the internet and its incredible potential. In his talk, he delves into the unique qualities that make the web such a powerful tool and why it's crucial for us all to advocate for and explain its significance.
https://www.youtube.com/watch?v=Mn2YFU_UkEI
If you understand why the open web unlocks doors and what makes it is special, please advocate on its behalf and help spead that message.
]]>
Webventures: An Abridged History of Safari Showstoppers2024-09-25T00:00:00Zhttps://open-web-advocacy.org/blog/webventures-an-abridged-history-of-safari-showstoppers/
This week, Webventures published an article outlining various bugs and problems in iOS Safari over the last several years that were absolute showstoppers for the Web being a competitive constraint and substitute for mobile app stores.
iOS Safari is more than an inconvenience for developers, it's the fundamental reason interoperability has been stymied in mobile ecosystems; frequent showstopping bugs, a large patch gap, and lack of competing engines ensures the web is not a credible competitor to native. Here are the receipts to prove it
Webventures
Web Apps are being held back as businesses and developers can not be confident that they will consistently work on iOS, a platform no business can ignore without losing (in many cases) more than half their customers.
The critical issue here is that regulators can not regulate a browser not to have bugs or to fix them quickly. Browsers are complex and some level of bugs is to be expected. Browser vendors also need to work out which bugs to prioritise. The problem here is lack of effective browser competition on iOS.
When a critical bug breaks Web Apps on iOS for months, Apple has no great fear it will lose Safari users to rival browsers because they are introducing the exact same bugs into their rivals browsers via imposing their browser engine on third-party browsers. Rival browser vendors have very little control here when it comes to stability on iOS. This lack of fear of losing users removes a powerful incentive to be better.
The solution is clear: fair and effective browser competition on iOS globally. This involves both allowing browser vendors to port their browsers, removing rules that prevent them from competing and giving the software and hardware API access they need to implement and compete in features, stability, performance security and privacy. This will place great pressure on Apple to improve and improve fast. It also provides an alternative for both developers and consumers should they fail to do so.
Already we can see that regulatory pressure has led to some improvement but in order to be truly effective the underlying competition issues need to be fixed, and fixed globally.
If you spot any mistakes or have additional issues that you believe should be included please contact the author. If any of the unfixed tickets referenced in the article are important to you or your team, please comment on them; this is important as it's evidence to both Apple and regulators that these issues are important and need to be fixed. If you're active on social media, you can point Safari developer relations to the link to your comment, too.
As an organisation, our aim is to allow fair and effective browser and Web App competition on all major consumer operating systems. OWA has so much more work to do advocating for the web all over the globe.
We will always need your support, and you can do that in many ways:
]]>
Google must share the ability to install Web Apps in Android2024-09-19T00:00:00Zhttps://open-web-advocacy.org/blog/google-must-share-the-ability-to-install-web-apps-in-android/TLDR: For 7 years, Google has failed to keep its commitment to share the ability to install Web Apps with third-party browsers on Android, despite public requests from Samsung, Microsoft, Brave & Kiwi browser. With regulatory intervention from the EU, Japan and the UK that may be changing.
In 2015, Google introduced a method on Android to install Web Apps and subsequently replaced it with a better system called "WebAPK minting" in 2017. This system allows Chrome on Android to install Web Apps that integrate well with the operating system. At the time, now more than 7 years ago, Google promised to share this with third-party browser vendors. However, as of today this functionality is still exclusive to Chrome on most Android devices (Note: Samsung has implemented their own version for Samsung Internet on Samsung devices).
QUESTION: I am a developer of another browser on Android, can I have this seamless install process?
We are working on it. We are committed to making this available to all browsers on Android and we will have more details soon.
Google - On WebAPK minting (7 years ago)
A WebAPK is a thin wrapper Native App that provides a splash screen, system launcher integration, and system settings configuration points. When launched, a WebAPK essentially starts a tab in the browser which installed the WebAPK, loading the specific URL the Web App developer configures.
All native apps on Android are packaged as APKs, either via an app store such as Google Play or via sideloading. WebAPKs allow Web Apps to be integrated into the OS for the purposes of discoverability, permissions management, shortcut creation, registering url with the operating system (so links will open in the web app instead of a browser tab) and uninstallation. This means that web apps installed as WebAPKs are able to be shown in Android’s app drawer and search, system app pages such as apps, storage, screen time and battery usage, and shown without a browser badge.
Left to right: narrow.one installed on Chrome, Firefox & Edge. Only the WebAPK version is able to be shown anywhere other than this homescreen.
Android’s security model is built around signed native APKs. In order for Web Apps to integrate properly on Android without significant architectural changes, Web Apps need to be wrapped in a signed native APK. This allowed Google to support Web Apps across existing versions of Android without having to introduce a new architecture to support Web Apps and wait for years for it to be updated.
First, this damages competition between browsers on Android. By controlling WebAPK minting, Google stifles innovation in the browser market. Other browsers cannot offer the same seamless and native-like PWA install experience as Chrome on Android, limiting their ability to compete. This behaviour unfairly allows Google to provide better functionality for Chrome than other browsers on Android phones. It also means that only Google can decide what functionality Web Apps should have and makes it impossible for other browsers to effectively compete in the provision of Web App features.
Second, this limits the end user's choice of browser when it comes to Web Apps. They are essentially forced to use Chrome if they want the best Web App experience. Users should be free to choose browsers that offer better Web App functionality, but this is impossible if other browsers are prevented from installing them.
Finally, this damages the Web App ecosystem. Web Apps are the only open and interoperable competitor to the Android and iOS app stores. Allowing them to flourish will apply significant competitive pressure on the mobile app stores.
Opening up WebAPK minting would benefit developers and businesses by making it easier for them to reach a wider audience with their Web Apps. This can result in cheaper, higher quality software that automatically works on all major platforms.
Web Apps installed through other browsers are not as integrated with the Android system as those installed through Chrome. This can lead to a less user-friendly experience for consumers. Some features of Web Apps do not work as well or at all when installed through other browsers. This can limit the functionality and usefulness of Web Apps for consumers.
One of Google's stated goals is to promote open web standards, and they are a supporter of the open web foundation, yet they contradict this by keeping WebAPK minting closed and exclusive to Chrome.
Google’s refusal to provide competitors a method of minting WebAPK’s prevents competing browsers from producing viable Web Apps.
Walled Gardens Report (2021)
This work is showing signs of significant progress.
First, Google's behaviour appears to be explicitly banned by the Digital Markets Act and Japan's new Smartphone Act. Specifically rules that Gatekeepers such as Google must share APIs with rivals.
OWA submitted that on Android devices running the Google Play store, only Chrome has the ability to mint (create) WebAPKs (except on Samsung devices). OWA submitted this prevents competing browsers from producing viable web apps.
[...]
Google submitted that the WebAPK minting service provides WebAPK minted apps with certain additional functionality. Google submitted that it has not yet deployed a way for other browsers to use the WebAPK minting service.
[...]
Overall, the evidence available to date indicates that Google engages in self-preferencing less, in respect of access to functionalities on Android compared to Apple’s approach on iOS. Lack of access to WebAPKs, which is essential for installing PWAs, is the main issue highlighted by third parties (see paragraphs 4.6 to 4.7). Whilst Google has acknowledged this restriction, its latest submission to the CMA indicates that it is working to resolve it.UK Browsers and Cloud MIR - WP3) (emphasis added)
While we are delighted that Google has indicated to the CMA that they will fix the issue, we request that any regulators reading this legally compel Google to do so on a reasonable timeline (within 6 months). We are concerned that this could be strung out for years or even eventually cancelled when the regulatory heat dies down.
Importantly, given this service is provided by Google Play Services, Google should be able to provide this on almost all existing Android devices (Play Services currently goes back to Android 5.0 - 2014, so includes around 99.6% of users). This fix should not be restricted to new Android updates.
To Google, we request that they fix this promptly, globally and fairly. We ask that Google not play any regulatory games by only fixing it where they are legally compelled to do so and at the earliest possible date publicly publish a full plan on how they intend to share this functionality. We ask that they reach out and talk to interested browser vendors directly.
We would also like to thank everyone who supports us for making our work possible. Without it we would not be able to apply this pressure to improve competition for both browsers and Web Apps.
]]>
Apple appears to mislead UK Regulator over deceptive default browser user interface2024-09-04T00:00:00Zhttps://open-web-advocacy.org/blog/apple-appears-to-mislead-uk-regulator-over-deceptive-default-browser-user-interface/
TLDR: Apple seems to have tried to mislead the UK regulator that a deceptive pattern they had previously implemented for picking default browsers, in fact, never existed.
Earlier this year (2024-03-28) we reported on a deceptive pattern that Apple had coded into iOS which made it harder for users to change their default browser, if your current default browser was already Safari.
UK Regulator's Screenshots of the Issue - Working Paper 5
"Apple engineers added code to the Safari's settings page to hide the option to change the default browser if Safari was the default but then to prominently show it if another browser was the default." You can test this on an iPhone by scrolling to Safari under Settings. If Safari is not the default browser, there will be an option for "Default Browser App" where you can easily set Safari as the default. But if Safari is set as the default, this option disappears. For every other browser installed, the option remains to switch the default, whether that browser is set as the default or not.
Ashley Belanger - Ars Technica
This interesting design foible was picked up by Ars Technica 2 weeks later and was subsequently fixed by Apple. We are uncertain exactly which version of iOS Apple fixed it in as they neglected to include it in the release notes. We noted that this had been fixed in our review of Apple's compliance with the EU's Digital Markets Act on 2024-07-21.
OWA thought: Amazing! One problem down! Well done Apple for fixing it without being directly compelled to and for doing so globally.
However... according to Apple, none of the above ever happened and we collectively imagined the design!
In Apple's response (published 2024-08-01) to the CMA's working paper 5, they respond directly. First, Apple accurately describes the issue both the CMA and OWA indicated:
The UK's Competition and Markets Authority (CMA) analysis also appears to rely on an OWA report concerning an alleged ‘dark pattern’ involving the use of different UIs in order to preference Safari is set as the default browser (paragraph 3.48) by not displaying the default browser setting in the Settings app’s Safari tab where the default browser is Safari.
Apple - Response to Working Papers 1 to 5
They then state:
This is not correct. The default browser app setting in the Safari tab is clearly visible when the user has set Safari as the default.
Apple - Response to Working Papers 1 to 5
What does "This is not correct." mean in this context?
The only realistic interpretation is that statements made by the CMA and OWA on this topic are "not correct" or false. That is, at the time either OWA or the CMA’s statements were written, Apple was not employing a deceptive pattern to hide the option to switch default browser if Safari was the default. This is certainly a bold claim given this was independently verified by us, ArsTechnica and the CMA. This verification included screenshots, documents and a video of the whole process. Apple presumably also retains copies of the original code that implement this "functionality" and can easily replicate the issue.
What Apple could, and should have said, here is that "This is no longer correct, as we fixed it in iOS 17.x". Instead they appear to have, bafflingly, chosen to mislead the regulator about the existence of the issue entirely.
Before accusing Apple of seeking to mislead the CMA, it's worth interrogating the alternatives:
1. Apple is correct and this behaviour never took place.
This isn't plausible as multiple parties independently checked this.
2. Apple's lawyers writing this section didn't check or the staff they asked didn't know.
This option at least makes Apple merely incompetent, rather than actively seeking to mislead a regulator but is it really plausible that the lawyers writing this part of the response didn’t ask the team at Apple that implement/maintain the iOS Safari settings page whether these accusations had any basis in truth and/or that that team didn’t remember that they updated the page, fixing the behaviour, a mere 2-3 months earlier.
Ultimately, what makes this situation egregious is that this is not some off-the-cuff remark in a verbal setting or a carefully constructed non-statement, it is a direct denial of specifically alleged past anti-competitive behaviour presented in a formal (and presumably carefully reviewed) response by a multi-trillion dollar organisation to an ongoing investigation conducted by a regulator. This can have serious consequences.
In practice, the CMA expects, and normally receives, full co-operation from those involved in an investigation, and does not generally use the formal powers available to it. Where necessary, however, it does do so. It should also be noted that the provision of false or misleading information to the CMA by a party or its advisers is a criminal offence, punishable by a fine and/or up to two years in prison.Ashurst - Quick guide to competition law investigations by UK authorities
If we were the CMA, we would have a number of questions for Apple, such as:
Is Apple claiming that at no point in the past has the behaviour described taken place?
How would Apple account for the various screenshots and videos (some of which were taken by the CMA)?
What steps did Apple take internally to verify this quoted paragraph was neither false nor misleading?
Can we be provided copies of all emails/messages/documentation related to writing the quoted paragraph?
Can we be provided copies of all internal tickets/emails/documentation related to changes to the default browser setting in the iOS Safari setting panel over the last year?
Can we be provided copies of the code related to the default browser setting in the iOS Safari setting panel including all versions and changelogs over the last year?
There was no particular need for a direct response to this line item, so the choice to re-write history seems especially odd. They had after all already globally fixed it at the time of their submission.
We believe that tech giants shouldn't be allowed to lie to or mislead regulators and that appropriate enforcement action should take place when they can be proven to have done so. We intend to continue calling out and questioning behaviour like this.
]]>
Apple adopts 6 of OWA's Choice Architecture Recommendations2024-08-23T00:00:00Zhttps://open-web-advocacy.org/blog/apple-adopts-6-owa-choice-architecture-recommendations/Today, in a step forward for user choice and browser competition, Apple has adopted 6 out of 11 of our recommendations to comply with the EU's Digital Markets Act in relation to browser defaults and choice screens. In addition Apple has fixed two severe and deliberate deceptive patterns that we campaigned to fix including at the DMA's workshop.
In March the EU Commission opened an investigation into Apple for non-compliance with the Digital Markets Act related to user choice obligations. Since that time we have been working to ensure that all gatekeepers comply with the DMA with respect to browsers and Web Apps.
According to Apple’s announcement the following recommendations will be implemented on iOS (including on iPads). We will need to observe the implementation for additional issues but this is a positive step forward for browser competition and Apple's compliance with the Digital Markets Act.
The user’s choice of default browser must be used for In-App Browsing (SFSafariViewController) Currently most In-App browsing on iOS is locked to Safari which provides Apple a very significant advantage and a lot of traffic. It is critical for browser choice that if a user decides on a particular browser, that browser is then used for web browsing by default across the OS including in In-App Browsers.
Browsers on the choice screen shouldn't be Locked to the Gatekeeper’s app store Browser vendors should be able to choose if they want to have their browser distributed directly or via the AppStore, including if they also distribute via the AppStore. The choice-screen should not force any browser vendor to have to distribute via Apple’s designated core platform service and thus lock them into Apple’s unfair contracts and rules + 30% of any In-App payments.
Apple has indicated they are open to collaborating on this recommendation however we are concerned that browser vendors are in essence locked into Apple’s app store and are not able to distribute their browser directly as they do on desktop operating systems.
Specifically, we believe that the Core Technology Fee should be removed as this is a punitive fee on businesses daring to list any of their apps outside of Apple’s app store. The EU should consider solving the issues of alternative app distribution (including core-technology fee) so that browser vendors have the option of direct distribution. If these issues are not solved before the choice screens are rolled out then a key opportunity for browser vendors to offer their browsers directly to users would have been lost.
Apple should also not be allowed to put up scare screens to dissuade users from directly downloading browsers.
Browsers should be allowed to know if they are the current default browser. It is important that browsers can detect whether or not they are the default in order to provide sensible prompts to users to set their browser as the default. Apple has argued that they do not provide this information to Safari but that is irrelevant as Safari is set as the default in factory settings.
We will be engaging with the DMA’s investigation into defaults and choice screens about these issues as we believe they are justified and that Apple is obligated to implement them under the text of the DMA.
# Hotseat not granted to already installed browsers and browsers set as default outside the choice screen.
If Safari is currently in the user’s Dock or on the first page of the Home Screen and the user selects a browser that is not currently installed on their device from the choice screen, the selected browser will replace the Safari icon in the user’s Dock or in the Home Screen
Apple - On Browser Choice Screens
(emphasis added)
One issue with Apple's implementation is it does not apply to browsers which are already installed. Apple needs to update this to move an already installed browser onto the hotseat to replace the Safari icon when it is selected in the choice screen.
We believe that browsers that are downloaded outside of the choice screen should also replace Safari in the hotseat upon being set as default browser.
This is important as these are both common scenarios. Any friction that OS gatekeepers can introduce to make it harder for users to use a browser other than theirs undermines browser competition. Friction is a powerful force to block competition.
The deceptive pattern of hiding the option to change default browser in Safari settings if Safari is the default outlined in this article has also been removed by Apple globally.
Additionally, the deceptive pattern of triggering the choice screen when Safari is not the default browser (typically because it still occupies the hotseat) has been fixed. That is Apple was triggering the choice screen in the hope that users will change from a third-party browser back to Safari.
These changes are EU only. Apple's users in other countries do not gain any direct benefit from these remedies. We urge regulators in other countries to carefully examine these changes and consider compelling Apple to implement them in their own jurisdictions. It should be noted that the effort for Apple to implement the choice screen in other jurisdictions will now be minimal.
While the changes the EU have made are excellent, they are limited in pursuing the optimal solution by the very specific text of the DMA.
In addition to the unimplemented recommendations above we would recommend several important improvements including:
The choice screen should be moved to device setup or upon device update rather than upon first use of the gatekeepers browser.
The gatekeepers browser, if not selected, should be uninstalled from the device
or virtually uninstalled, i.e. hidden from the user, if the gatekeeper can demonstrate that is not practical because of technical limitations.
We have not yet seen the implementation of the choice screen. For OWA, browser vendors and others to provide feedback to the EC we need to be able to see it in action (video) and be able to test it. This needs to be done well in advance of any browser choice screen rollout in the EU so there is time to make changes based on feedback.
The outside of the Apple AppStore workflow for the choice screen is unknown. We'd like to know what the outside of the AppStore install process would look like, and a confirmation that browser developers can opt to have their "non-appstore" version installed if they would like.
Additionally, developers who make their browsers available outside the App Store should contact their Apple representative or dma-data@apple.com to collaborate on including their browser in the choice screen.
For example, can Brave/Firefox/Edge/Opera/DuckDuckGo/Chrome/Vivaldi offer from the choice screen, a version of their browser which is directly distributed from that browser vendor?
For testing the choice screen, Apple should provide a way to trigger the choice screen multiple times without having to factory reset a device. A “choice screen” button in settings somewhere would do the trick. To test it properly we need to launch it many times.
# What does success for Choice Architecture look like?
There are two forms of success in choice architecture. One is removing behaviour that is blatantly unfair or manipulative, the removal of the behaviour is a success in its own right regardless of any outcome.
The second is in allowing space for new and smaller browser vendors to thrive. Even the most perfect choice screen will not wildly change user preference over night. The biggest names in browsers are the ones that will be picked the most, the browser of the operating system will still get a significant boost. What choice screens need to do to succeed is let users know that they have a choice and create an opening for smaller browser vendors to get a foothold on mobile.
If third-party browsers managed to gain an additional 10% of the total market share on iOS or Android that would be a resounding success. As a point of context Google is paying Apple $20 billion USD per a year for being the default search engine. That means every 1% is worth $200 USD million annually.
That 10% is enough to support 8 Mozilla’s across iOS and Android. That is something worth fighting for.
]]>
UK’s Browser and Cloud Investigation may fail to allow Web App competition2024-08-20T00:00:00Zhttps://open-web-advocacy.org/blog/uk-browser-and-cloud-investigation-may-fail-to-allow-web-app-competition/TL;DR: We believe the UK Market Investigation Reference is missing critical remedies. Most importantly "Apple shall allow third-party browsers to install and manage Web Apps using their own browser engine.". We need YOU to write to the CMA (before August 29th) and provide feedback on why allowing browsers to compete in providing Web App functionality is important.
From our extensive work in supporting the Mobile Ecosystems Study, we know the key reason the Market Investigation Reference into Browsers and Cloud Gaming was launched was to enable the free, open and interoperable ecosystem of the web to contest Apple’s and Google’s app stores, reducing costs for UK’s consumers and businesses. While regulators across the world were focused on app stores, the UK was the only regulator that was looking towards the web and web apps to solve these issues on mobile ecosystems. This aim was made clear by the opening statements of the Browsers and Cloud MIR:
We all rely on browsers to use the internet on our phones, and the engines that make them work have a huge bearing on what we can see and do. Right now, choice in this space is severely limited and that has real impacts – preventing innovation and reducing competition from web apps. We need to give innovative tech firms, many of which are ambitious start-ups, a fair chance to compete.
Andrea Coscelli - Chief Executive of the UK's Competition and Markets Authority(emphasis added)
Last week the browsers and cloud MIR released their remedies paper outlining their initial thoughts on remedies and asking for feedback. While the paper contains a number of excellent remedies, not least of which is prohibiting Apple from banning browser engines from iOS, we are deeply concerned that the MIR will fail in its goal of allowing third party browsers to enable effective competition from Web Apps.
A1 - Requirement for Apple to grant access to alternative browser engines to iOS.
A2 - Requirement for Apple to grant equivalent access to iOS to browsers using alternative browser engines.
A3 - Requirement for Apple to grant equivalent access to APIs used by WebKit and Safari to browsers using alternative browser engines.
Issue 2 – Apple’s and Google’s control over supply of browser engines to restrict access to functionalities
A4 - Requirement for Google to grant equivalent access to APIs used by Chrome.
Issue 3 – Apple preventing all rival browser vendors from offering remote tab IABs on iOS
B1 - A requirement for Apple to enable remote tab IABs for WebKit-based browsers.
B2 - A requirement for Apple to enable remote tab IABs for browsers wishing to use alternative browser engines.
Issue 4 – Apple preventing rival browser engines from offering nonWebKit based webview IABs, including bundled engine IABs to app developers on iOS
B3 - A requirement for Apple to allow alternative webviews to Apple’s iOS WKWebView.
Issue 5 – on Android, default settings and preinstallation of Android WebView make it difficult for app developers to use IABs based on alternative webviews
No remedies proposed.
Issue 6 – Apple’s and Google’s IAB policies offer users limited choice and control in relation to which browser is used for IAB implementation in native apps
B4 - A requirement for Apple and Google to implement remote tab IABs using the default browser.
B5 - A requirement for Apple and Google to make users aware of being in an IAB by implementing changes to the interface or implement disclosures.
B6 - A requirement for Apple and Google to implement opt-out settings for in-app browsing.
Issue 7 - Apple’s and Google’s control of choice architecture in factory settings
C1 - A requirement for Apple and Google to ensure that multiple browsers are pre-installed, using defined criteria.
C2 - A requirement for Apple and Google to ensure the use of browser choice screens at device set-up.
C3 - A requirement for Apple and Google to ensure the placement of a default browser selected by the user in the ‘dock’ / ‘hot seat’ or on the default home screen at device set-up.
C4 - A requirement for Apple and Google to ensure that a user’s choice of default browser is always followed across all browser access points.
Issue 8 - Apple’s and Google’s use of certain choice architecture practices after device set-up
C5 - A requirement for Apple and Google to ensure the use of browser choice screen(s) after device set-up.
C6 - A requirement for Apple and Google to make adaptations to the user journey for changing their default browser.
C7 - A requirement for Apple and Google to share user data on default browsers settings with browser vendors.
C8 - A requirement for Apple and Google to ensure that the frequency of default browser prompts and notifications is limited.
C9 - A requirement for Apple and Google to allow users to uninstall Safari browser app on iOS and Chrome on Android devices.
Issue 9 – Apple’s App Store policies in relation to cloud gaming services
D1 - A requirement for Apple to review and amend its Guidelines to remove the specific restriction identified as restrictive and a prohibition on Apple introducing new restrictions with equivalent effect.
D2 - A requirement for Apple to enable cloud gaming native apps to operate on a ‘read-only’ basis (i.e. with no ingame purchases or subscriptions) so that games do not need to be re-coded and no commission would therefore be payable to Apple).
Issue 10 – app store rules in relation to in-app payment systems for in-game transactions
D3 - A requirement for Apple and Google to allow CGSPs to incorporate their own or third party in-app payment systems for in-game transactions.
In the remedies the MIR team is proposing both removing Apple’s rule banning browsers from using their own browser engines and obligating Apple to provide equivalent iOS API access to third party browser vendors that Safari and WebKit have.
# 1. Browsers can’t Install Web Apps using their own Engine
The problem is that these do not fix the core issue, namely, can browsers compete in the provision of Web App functionality using their own browser engine. Apple could plausibly argue that allowing browsers to use their own engine and providing them access to the share menu to install Apple’s WebKit implementation of Web Apps satisfies both requirements.
This could lead to a situation where while browser engines such as Blink (Chrome, Edge, Opera, Vivaldi, DuckDuckGo, Brave) and Gecko (Firefox) could be ported to iOS, browser vendors would be unable to compete to improve the stability, functionality, security or privacy of Web Apps. This would still be under Apple’s sole control.
As noted in the CMA’s mobile ecosystems study, Apple is heavily incentivized not to support Web Apps to their full potential. Certain features such as install prompts that would allow Web Apps to compete more fairly with Apple’s own apps and app store, will almost certainly never be implemented by Apple.
By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
UK CMA - Interim Report into Mobile Ecosystems(emphasis added)
# 2. Browser Access to Software/Hardware APIs is Insufficient
Next, the wording on remedy A3 ("Requirement for Apple to grant equivalent access to APIs used by WebKit and Safari to browsers using alternative browser engines.") is scoped to only what Safari and WebKit have access to, which is a problem as that could allow Apple to set a ceiling by blocking Safari from having access to stuff Apple does not intend to implement for the Web, i.e. Bluetooth, USB etc. If Apple is not under any legal obligation to share needed Software/Hardware APIs required to support browser or Web App features that Safari does not support, they will not provide access to those APIs.
It is critical that Apple can not reserve functionality for its own apps, system services and apps delivered by its app store by blocking browser vendors access to the required hardware and software APIs. Where feasible browser vendors should have the right to provide feature parity to Web Apps.
# 3. Web Apps can’t succeed without Install Prompts
In order for Web Apps to have a significant opportunity to truly compete on iOS, Safari needs to implement install prompts (the ability for websites to prompt, or provide a button to install them as a Web App). Apple, understanding the importance of reducing friction, has implemented a large variety of ways to install apps from Apple’s app store via Safari including smart banners and app clips while keeping the method of installing Web Apps hidden away in the share menu.
We believe four additional remedies needed in order to allow the Web to compete fairly on iOS:
"Apple shall allow third-party browsers to install and manage Web Apps using their own browser engine."
"A requirement for Apple to implement Install Prompts for iOS Safari."
"A requirement for Apple to grant all software and hardware access to APIs to browsers using alternative browser engines that they require to port their engines and implement stability, functionality, security and privacy. Restrictions on this can be subject to only strictly necessary, proportionate and justified security grounds."
"Where feature parity between Web Apps and Native Apps is possible, Apple must technically enable it and it should not be artificially prevented either by OS rules or OS design. Apple must not self-preference their own Apps, Apps sold via their App Store or their own Services over Web Apps."
These remedies are required because Apple's actions not only hurt the Web ecosystem, third-party businesses (be they browser vendors or software developers), but also make their devices worse for their own consumers. By depriving their consumers of the choice and competition that fair and effective browser and Web App competition would bring, they are worsening the functionality, interoperability, stability, security, privacy, and price of services on their devices. This MIR has the power to fix this for the UK, which will be a significant step towards fixing the problem globally.
After 3 years of work from the CMA, it would be incredibly disappointing to get to the end of the investigation without resolving the anti-competitive behaviour that is preventing web apps from succeeding and unlocking innovation.
The CMA is asking for feedback by the end of Thursday August 29th 2024 from interested parties, developers and businesses. This is your opportunity to provide feedback to the MIR team.
We need YOU to write to the CMA, share your thoughts on the proposed remedies and any remedies you think may be missing.
If you share our concern that competition issues related to Web Apps will not be resolved by the remedies proposed, please state so in your letter and outline why this is important to you, your business and to the future of tech in the UK.
If possible, explain the harm that has been caused by browsers not being able to compete in the provision of Web App functionality on iOS.
While we encourage readers to write longer submissions, short but clear emails that explain the key points are still immensely helpful.
Please let the CMA know if your name, business or submission is confidential.
Please consider spending 15 minutes writing to the regulator. After years of campaigning, this is a critical moment to ensure the Web is able to thrive, and we will not be successful without your support!
Note: All mentions of iOS above including quotes from the MIR mean both iOS and iPadOS.
]]>
Browser and Cloud Gaming Market Investigation Update2024-06-27T00:00:00Zhttps://open-web-advocacy.org/blog/uk-cma-browser-cloud-gaming-progress-report/
The UK’s Competition and Markets Authority, Browser and Cloud Gaming Market Investigation has just released their progress report. Long time readers may remember that this investigation was restarted after a high court win against Apple.
The report delves into Apple’s rule that all browsers on iOS must use the version of WebKit bundled with iOS which is under Apple’s exclusive control.
The requirement that all browsers on the iOS operating system use a specific version of the WebKit browser engine controlled by Apple, means that there is no competition between browser engines on the platform. Browser vendors cannot switch to an alternative browser engine or make changes to the version of WebKit used on iOS. Similarly, consumers are unable to switch to a browser based on an alternative browser engine. We consider that the lack of competitive pressure is likely to reduce Apple’s incentives to improve WebKit.
In addition, we have obtained evidence indicating that browser vendors incur
additional costs from having to develop and support a version of their browser
based on WebKit, which they would not do if the restriction were not in place.
Evidence from browser vendors also indicates that Apple is difficult to engage with
regarding requests for fixes or the addition of new features to WebKit on iOS.
Whilst Apple has submitted that the WebKit restriction is necessary to ensure the
security, privacy, and performance of iOS devices, and that this is an important
aspect of competition between iOS and Android devices, the evidence we have
seen to date does not support this conclusion.
Interestingly the report also states that iOS and Android should be considered separate markets for browsers.
it is our emerging thinking that the supply of mobile browsers on iOS and Android should be considered as two separate product markets”
This market investigation reference was launched by CMA’s Market Study into Mobile Ecosystems. In the reference decision to the market investigation reference they listed the following potential remedies:
removing Apple’s restrictions on competing browser engines on iOS devices;
mandating access to certain functionality for browsers (including supporting web apps);
requiring Apple and Google to provide equal access to functionality through APIs for rival browsers;
requirements that make it more straightforward for users to change the default browser within their device settings;
choice screens to overcome the distortive effects of pre-installation; and
requiring Apple to remove its App Store restrictions on cloud gaming services.
Separately the powers of the CMA has just been significantly strengthened with the passing of the Digital Markets, Competition and Consumers Bill. This will allow them to impose “codes of conduct” on large tech firms with “strategic market status”. This is entirely separate from the market investigation reference, however they will likely read each other’s report.
We hope that the CMA will end Apple’s effective ban on third party browsers on iOS either via the MIR or the powers granted by the DMCC bill.
Right now, if competition was restored, 90% of the apps on your phone could be written as a Web App and would be indistinguishable, significantly cheaper and often BETTER than Native Apps. Native Apps will still have a lead in cutting edge graphics and gaming technology but if companies see the web platform as viable this gap will decrease over time.
It is for this reason that allowing browser competition on iOS is critical. Apple’s effective browser ban prevents the emergence of such an open and free universal platform for mobile apps. Unlike desktop, developers cannot build their application once and have it work across all consumer devices. Instead, these policies combine with Apple’s trailing and feature-poor engine to force companies to create separate applications for iOS, significantly raising the cost and complexity of development and maintenance. This severely undermines any interoperability advantages Web Apps have between iOS and Android. A single prominent OS holding back the Web is enough to undermine its entire value proposition as a frictionless, capable and secure distribution mechanism for Web Apps.
The fight to allow browser and Web App competition on iOS is not over. We would like to thank everyone for their support over the last 3 years and ask that consumers, developers and businesses write in and engage with the market investigation reference to arm them with all the data and information they need to successfully restore competition to a broken mobile ecosystem.
Stay tuned as we will be posting about its progress as more information becomes available.
]]>
Apple DMA Review2024-06-21T00:00:00Zhttps://open-web-advocacy.org/blog/apple-dma-review/
The Digital Markets Act (DMA) aims to restore contestability, interoperability,
choice and fairness back to digital markets in the EU. These fundamental
properties of an effectively functioning digital market have been eroded by the
extreme power gatekeepers wield via their control of “core platform services”.
The lack of competition on mobile ecosystems is, at its heart, a structural one.
Gatekeepers wield vast power due to the security model that these devices are
built on. Traditionally, on operating systems such as Windows, macOS and Linux,
users can install any application they want, with no interaction from the
operating system gatekeeper, either by the business or the end user. Users can
then grant these programs the ability to do anything they desire.
Locking down what applications can do, such as restricting which APIs they can
access behind user permissions, is not by itself anti-competitive and can bring
legitimate security advantages. However, the manner in which it has been
implemented on mobile devices is both self-serving and in its current form,
significantly damages competition.
This damage surfaces in several forms:
First, the gatekeeper can control what is allowed to be installed on devices
they have already sold to consumers, often for a significant profit. They
utilize this device-level control to demand a 30% cut of all third-party
software that the consumer installs, not on merit, but simply because they
control the only mechanisms available to businesses to release that software,
and can further block or hinder the consumer from using or acquiring services
outside of their app store.
The second is more subtle. In order to deliver their “native” apps to consumers
on Android or iOS, developers must create custom applications in specific
programming languages for each individual platform. Typically, companies will
require separate development teams for each OS. This not only multiplies
development and maintenance cost, but puts in place an invisible barrier to
interoperability. Even the built up expertise for creating software for a
specific platform provides significant lock-in advantages to the platform’s
gatekeeper.
Finally, even if a developer has no desire to interact with the gatekeeper, they
are forced into a commercial and legally binding relationship with them. This is
due to the fact that the gatekeeper inserts itself between the customer and
these third party developers. With smartphones now 15 years old, this may seem
normal to us now, but imagine if Microsoft demanded that every software provider
signed an onerous contract with them or be barred from releasing a product on
Windows. What would have been unacceptable, anti-competitive behavior to both
consumers, businesses and regulators on desktop, has been tolerated on mobile
simply because these computers were considered a “new” category.
Mobile devices are just small computers whose primary input is touch, there is
no sacred or magical property that means they have to run on a proprietary app
store model. Nothing is stopping mobile computers running on the open model that
desktop computers run on, just as there is nothing stopping a desktop computer
running the app store model. Inertia and great profits are however powerful
forces. Between them, Apple and Google have created a powerful and entrenched
duopoly.
Even with the DMA forcing Apple to open up the ecosystem to competition, Apple
is still inserting themselves front and center between consumers and app
developers. They insist all developers for iOS/iPadOS (including developers who
have no intention of using their app store) pay them $100 per year, that they
sign the full Apple developer program contract and submit themselves to what is
effectively app store review (although nominally locked to security). Worse,
they are attaching significant recurring penalty fees to developers who dare to
make their software available outside of Apple’s app store. Apple is using every
tool at their disposal to dissuade developers from leaving their app store and
to undermine the goals of the DMA.
Apple's key excuse to impose this control is security. Apple's argument is, in
essence, that only they can be trusted to vet what consumers are allowed to
install on their devices. All third parties must submit to their review.
What is needed is a way to securely run interoperable and capable software
across all operating systems. Luckily, such a solution already exists and is not
only thriving on open desktop platforms but is dominating, and that
dominance is growing every year. The solution is of course, the Web and more
specifically Web Apps. Today, more than 60% of users' time on desktop is done
using web technologies, and that looks set to only grow.
Web Apps have a number of properties that allow them to solve this critical
problem. They are run in the security of the browser's sandbox, which even
Apple admits is “orders of magnitude more stringent than the sandbox for native
iOS apps.”. They are truly interoperable between operating systems. They
don't require developers to sign contracts with any of the OS gatekeepers. They
are capable of incredible things and 90% of the apps on your phone could be
written as one today.
So why aren't they thriving on mobile? The simple answer to this question is
lack of browser competition on iOS and active hostility by Apple towards
effective Web App support, both by their own browser and by their OS. Apple's
own browser faces no competition on iOS, as they have effectively barred the
other browsers from competing by prohibiting them from using or modifying their
engines, the core part of what allows browser vendors to differentiate in
stability, features, security and privacy.
The DMA explicitly sets out to right this wrong by mandating that gatekeepers
can no longer enact such a ban:
In particular, each browser is built on a web
browser engine,
which is responsible for key browser functionality such as
speed, reliability and web compatibility. When gatekeepers
operate and impose web browser engines, they are in a position
to determine the functionality and standards that will apply
not only to their own web browsers, but also to competing web
browsers and, in turn, to >web software applications.
Gatekeepers
should therefore not use their position to require their
dependent business users to use any of the services provided
together with, or in support of, core platform services by the
gatekeeper itself as part of the provision of services or
products by those business users.
Digital
Markets Act - Recital 43
The intent stated for this in the DMA is to prevent gatekeepers from dictating
the speed, stability, compatibility and feature set of “web software
applications”.
Apple has announced new rules that would, at first glance, allow browser vendors
to port their real browsers to iOS. However, on closer inspection, this is a
mirage. Instead Apple appears intent on making it “as
painful as possible” for browser vendors to port their engines to
iOS/iPadOS. As we will outline in our paper, Apple's current proposal falls far
short of compliance. Apple is not only undermining browser competition on iOS,
but appears to be actively attempting to prevent the growth of an entire open
and interoperable ecosystem that could feasibly supplant and replace their app
store model.
Apple have seen the Web as a threat to their app store as far back as 2011, when
Philip Schiller internally sent an email to Eddie Cue titled “HTML5 poses a
threat to both Flash and the App Store”.
Food for thought: Do we think our 30/70% split will last forever? While I am a
staunch supporter of the 30/70% split and keeping it simple and consistent across
our stores, I don’t think 30/70 will last unchanged forever. I think someday we will
see a challenge from another platform or a web based solution to want to adjust our
model.
Phil Schiller - Apple Upper Management
Apple is very explicit in its public statement that they initially planned to remove the
functionality as the DMA would force them to share it with third-party browsers. Even in
their statement backing down, they make it clear they do not intend to allow third-party
browsers that use their own engine to be able to install and manage Web Apps. In both
statements, Apple cites "security" as the reason for their decisions.
Unfortunately for Apple, it has been unable to prove that Safari or WebKit are actually
more secure than its competitors. When obligated by the UK’s Competition and Markets
Authority to provide evidence to back up its assertion that WebKit was more secure than
Blink or Gecko, Apple failed to do so.
... the evidence that we have seen to date does not suggest that there are material
differences in the security performance of WebKit and alternative browser engines.
Overall, the evidence we have received to date does not suggest that Apple's
WebKit restriction allows for quicker and more effective response to security threats
for dedicated browser apps on iOS.
UK CMA - Interim Report into Mobile Ecosystems
Apple's actions not only hurt the Web ecosystem, third-party businesses (be they
browser vendors or software developers), but also make their devices worse for their own
consumers. By depriving their consumers of the choice and competition that fair and
effective browser and Web App competition would bring, they are worsening the
functionality, interoperability, stability, security, privacy, and price of services on their
devices.
A reasonable person might argue
Why would Apple make their own devices worse, surely
better devices means more hardware sales? This behavior comes, however, with key
advantages for Apple, even if they harm Apple's own consumers.
The UK regulator cites two incentives: protecting their app store revenue from
competition from Web Apps, and protecting their Google search deal from competition
from third-party browsers.
Apple receives significant revenue from Google
by setting Google Search as the
default search engine on Safari, and therefore benefits financially
from high usage
of Safari. [...] The WebKit restriction may help to
entrench this position by limiting
the scope for other browsers on iOS to differentiate themselves from Safari [...] As
a result, it is less likely that users will choose other browsers over Safari, which in
turn secures Apple’s revenues from Google.
[...]
Apple generates revenue through its App Store, both by charging developers for
access to the App Store and by taking a commission for payments made via Apple
IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring
all browsers on iOS to use the WebKit browser engine,
Apple is able to exert control
over the maximum functionality of all browsers on iOS and, as a consequence,
hold up the development and use of web apps. This limits the competitive
constraint that web apps pose on native apps, which in turn protects and benefits
Apple’s App Store revenues.
UK CMA - Interim Report into Mobile Ecosystems (emphasis added)
These two revenue streams are vast, even for a company of Apple’s size. Apple collected
$85 billion USD in App Store fees in 2022,
of which it keeps approximately 30%. Apple
reportedly receives
$18-20 billion USD a year from their Google Search engine deal,
accounting for 14-16 percent of Apple's annual operating profits.
A third and interesting incentive the CMA does not cite, but which the US's Department of
Justice does, is that this behavior greatly weakens the interoperability of Apple's devices,
making it harder for consumers to switch or multi-home. It also greatly raises the barriers
of entry for new mobile operating system entrants by depriving them of a library of
interoperable apps.
Apple has long understood how middleware can help promote
competition and
its myriad benefits, including increased innovation and output,
by increasing scale and interoperability.
[...]
In the context of smartphones, examples of
middleware include internet browsers,
internet or cloud-based apps, super apps, and smartwatches, among other products
and services.
[...]
Apple has limited the capabilities of third-party iOS web browsers, including by
requiring that they use Apple’s browser engine, WebKit.
[...]
Apple has sole discretion to review and approve all apps and app updates.
Apple
selectively exercises that discretion to its own benefit, deviating from or changing
its guidelines when it suits Apple’s interests and allowing Apple executives to control
app reviews and decide whether to approve individual apps or updates. Apple often
enforces its App Store rules arbitrarily.
And it frequently uses App Store rules and
restrictions to penalize and restrict developers that take advantage of
technologies that threaten to disrupt, disintermediate, compete with, or erode
Apple’s monopoly power.
DOJ Complaint against Apple (emphasis added)
Interoperability via middleware would reduce lock-in for Apple’s devices. Lock-in is a clear
reason for Apple to block interoperability, as can be seen in this email exchange where
Apple executives dismiss the idea of bringing iMessage to Android.
The #1 most difficult [reason] to leave the Apple universe app is iMessage ...
iMessage amounts to serious lock-in
Unnamed Apple Employee
The DMA has the power to fix all of these underlying issues and unleash a powerful,
open, interoperable and secure competitor to not only Apple's
app store but also Google's. Lack of
contestability for mobile app stores and mobile operating systems is
a key concern for the DMA that viable Web
Apps solve.
This will also remove a heavy burden from new entrants into the operating system
market; lack of apps. No longer will developers need to develop custom apps
for each operating system, any
operating system with good web app support and browser competition will support
all web apps automatically. Web
Apps support operating systems that developers have not even heard of.
The impact of allowing them to compete
fairly on mobile will be profound.
We request the Commission open a proceeding into Apple and investigate what we allege
is severe and deliberate non-compliance. The number of ways that Apple is not complying is so myriad that we,
recognising that the commision does not have infinite resources to pursue all of them simultaneously, have split
them into three tranches of remedies.
Some remedies require time and/or pre-requisite remedies in order to be effective.
Remedies in this document are ordered to ensure that either competitive benefits are delivered earlier or to
unlock future remedies. In this way, we propose a program of continual improvement in the competitive landscape,
delivering wins at every step along the path.
While we have attempted to be comprehensive, it is possible, and perhaps even likely,
that there will be infringements that we have not included or are not yet aware of.
Our proposed remedies include:
Restricting Apple's API contract for browsers down to strictly necessary,
proportionate and justified security measures.
Make clear what the security measures are for third party browsers using
their own engine by publishing them in a single up-to-date document.
Removing any App Store rule that would prevent third party browsers from
competing fairly.
Allow browser vendors to keep their existing EU consumers when switching
to use their own engine.
Removing the special placement of Safari.
Making Safari uninstallable.
Implementing Install Prompts in iOS Safari for Web Apps.
Allowing Browser Vendors and Developers to be able to test their browsers
and web software outside the EU.
Allowing Browsers using their own engine to install and manage Web Apps.
Make notarization a fast and automatic process, as on macOS.
Allow direct browser installation independently from Apple’s app store.
Allow users to switch to different distribution methods of a native
app and allow developers to promote that option to the user.
Don't break third party browsers for EU residents who are traveling.
Opt-Into Rights contract should be removed.
Core Technology Fee should be removed.
Apple should publish a new more detailed compliance plan.
Apple is obligated under Articles 5(7), 6(3), 6(4) and 6(7) to fix each
of the above issues. Apple has failed to achieve effective compliance
with these obligations contrary to Article 13(3). Further Apple has
taken numerous and significant steps that obstruct and undermine it in
contravention of Article 13(4). Apple has introduced conditions and
restrictions on DMA-conferred rights that have no legal basis in the
DMA and gone far beyond the restrictions that the DMA does allow by
introducing rules that have no basis in security or that are not justified,
strictly necessary or proportionate.
Successful resolution of these issues have an exceptional chance of becoming de facto global, as no jurisdiction will want to miss out on clear benefits being enjoyed by EU consumers. However, if Apple manages to successfully avoid complying with the DMA, these problems could persist indefinitely.
We urge the Commission to enforce the DMA and obligate Apple to allow
browsers and Web Apps to compete fairly and effectively on their mobile ecosystem.
This will unlock contestability, fairness and interoperability. Companies will then
have to compete for users on merit, not via lock-in or control over operating
systems. Consumers will benefit from choice, better quality and cheaper software,
interoperability, and the genuine ability to multihome across devices and operating
systems offered by different companies.
These changes can finally fix a mobile ecosystem that has been
structurally broken, and artificially hindered, for more than a decade.
In particular, it prohibits Apple’s ban of third party browser engines on iOS, which is an effective ban on browsers like Firefox, Chrome, Edge, Opera, Brave & Vivaldi. Apple bans these browser vendors from choosing and modifying their own engines, and instead forces them to use Apple’s browser engine which they can’t modify and have no control over. This then ensures that there is no effective browser competition on iOS and deprives Web Apps of the functionality they need to compete with native apps.
This is the second jurisdiction (after the EU in the Digital Markets Act) to explicitly codify this into law.
Article 1: In light of the role that smartphones play in Japan as the foundation of people's lives and economic activity, this Act aims to promote fair and free competition in the field of specific software by providing prohibitions on businesses that provide specific software that is particularly necessary for smartphone use from exploiting their position as businesses that provide specific software to give the products or services they provide a competitive advantage and from causing disadvantage to the business activities of businesses that use specific software, thereby contributing to the improvement of people's lives and the sound development of the national economy.
Bill on the Promotion of Competition for Specified Software Used in Smartphones
(machine translated)
The EU has pioneered new regulations in this field, and in order for the digital markets of the EU, US, and Japan to work in lockstep to set fair competition practices for platform operators, a new legal framework is also needed in the Japanese market to confront digital platform operators.
Japan Fair Trade Commision
The bill aims to promote fair and free competition on smartphones by preventing large tech companies from abusing their position as providers of platforms to block or advantage their own services.
Violators will face fines equivalent to 20% of the domestic revenue of the service that violated the law. The rate of the fine can be increased to 30% for repeated violations.
The final bill contains a number of interesting articles relevant to browsers and Web Apps:
Banning browser engines is prohibited.
Must share APIs and services of the operating system to the same level as the services used by the designated providers. Justifiable measures may be applied.
Designated providers shall make it easy to change the default settings of the operating system.
Designated providers shall provide a choice screen for browsers.
When a designated business operator sets or changes the specifications, sets or changes the conditions for use, it must take necessary measures, such as securing a period for the business operator specified in each item to smoothly respond to the measure, disclosing information, and establishing a necessary system, as specified by the Fair Trade Commission rules.
This law will go into effect at a date chosen by the government at least 1.5 years from signing. This would put the earliest date of being in force as December 12, 2025.
This is an important step to restoring browser competition to iOS and enabling Web Apps to succeed on mobile as the world's only truly interoperable app development platform. Each jurisdiction that enforces rules to enable browsers and Web Apps to compete fairly is an important step on the road to a global solution. Apple has taken some rather extreme measuresto geo-fenceand undermine the Digital Markets Act in the EU but as the number of jurisdictions grow, the benefits to consumers and business become clear and the scare tactics are shown to be groundless, the harder it will be to maintain and justify such tactics.
This victory wouldn't have been possible without your unwavering support. While we celebrate this important step, let's remember the fight for global browser competition continues. Stay tuned, and let's work together to ensure browser choice for all users, everywhere!
]]>
UK passes Digital Markets, Competition and Consumers Bill2024-05-23T00:00:00Zhttps://open-web-advocacy.org/blog/uk-passes-DMCC/# UK passes Digital Markets, Competition and Consumers Bill
On 23rd May, the Digital Markets, Competition and Consumers Bill was passed in Parliament. It is currently awaiting Royal Assent. As the UK Government explains, the Bill was introduced
to crack down on rip-offs, protect consumer cash online and boost competition in digital markets.
The CMA will be able to directly enforce consumer law rather than go through lengthy court processes…
As part of the Bill, a Digital Markets Unit (DMU) within the CMA will be given new powers to tackle the excessive dominance that a small number of tech companies have held over consumers and businesses in the UK…
For example, the biggest tech firms may be instructed by the DMU to provide more choice and transparency to their customers. If firms don’t abide by these rules, the DMU will have the power to fine them up to 10% of their global turnover.
OWA looks forward to continuing working with the CMA to bring about a fairer competitive landscape so that smaller British companies can serve their consumers as they wish to, rather than as Tech giants dictate.
# Update 28 May: CMA opens consultation on digital markets competition regime
]]>
Apple's one weird trick to stop you changing your default browser2024-03-28T00:00:00Zhttps://open-web-advocacy.org/blog/apples-one-weird-trick-to-stop-you-changing-your-default-browser/
https://www.youtube.com/watch?v=AiiU_zBirXc
But let's put that aside for now to discuss a different topic: defaults.
The Digital Market Act introduces obligations for gatekeepers to make it easy for users to change defaults including obligating a choice screen.
There is a common phrase about following the letter and spirit of the law: are you making good faith efforts to comply with the intent? In the case of the intent of the DMA you don't need to guess as the act itself contains 26 pages of recitals that in very clear language explain exactly what the act is trying to achieve via the letter of the law as spelt out in the articles.
In the case of the defaults the recitals have this to say:
Recital 49: A gatekeeper can use different means to favour its own or third-party services or products on its operating system, virtual assistant or web browser, to the detriment of the same or similar services that end users could obtain through other third parties.
...
Gatekeepers should also allow end users to easily change the default settings on the operating system, virtual assistant and web browser when those default settings favour their own software applications and services. This includes prompting a choice screen ...
On dark patterns the recitals had this to say:
Gatekeepers should not engage in behaviour that would undermine the effectiveness of the prohibitions and obligations laid down in this Regulation. Such behaviour includes the design used by the gatekeeper, the presentation of end-user choices in a non-neutral manner, or using the structure, function or manner of operation of a user interface or a part thereof to subvert or impair user autonomy, decision-making, or choice.
While on defaults Article 6(3) simply says:
The gatekeeper shall allow and technically enable end users to easily change default settings on the operating system, virtual assistant and web browser of the gatekeeper that direct or steer end users to products or services provided by the gatekeeper
In Apple's opening speech on changing defaults, Apple's spokesperson had this to say:
In this session we are going to provide a summary of what we are doing on the web browser choice screen and defaults pursuant to the DMA. Lets start with defaults and specifically the ability to select a default browser. For a long time Apple have made it easy for users to choose a browser in the settings app. Many users have already chosen to set a non-Safari default browser even before the DMA. They can do it in just a few taps.
This is a little surprising. Apple didn't even let users change the default browser until late 2020. When they did add the ability to do so the design was awkward and confusing. There is no centralised location to change defaults, no way of searching for the option in the OS settings and the option to change the default is inappropriately shown on each browser settings page. Further, they provide no API to allow newly installed browsers to prompt the user to switch default browser or even be aware that they are the default browser.
Now, some may think it is unfair to suggest that Apple deliberately designed it to be as awkward as possible to change the default browser but they went one critical step further that unambiguously shows that they maliciously intended to undermine user choice.
In an astonishingly brazen dark pattern Apple engineers added code to the Safari's settings page to hide the option to change the default browser if Safari was the default - but then to prominently show it if another browser was the default.
This video demonstrates it, and you can test it yourself right now.
https://www.youtube.com/watch?v=o6uwiG1nKK4
There is absolutely no plausible defence for this behaviour.
We had John ask Apple directly about this at Apple DMA Workshop.
I am going to continue to focus on one more question regarding the prompt to change the default browser. You mentioned earlier that users are always prompted to change their default browser. At the moment there is no way for browsers to detect if they are the default browser nor a one click system prompt to allow users to set the default browser. This is standard on all other major operating systems except iOS. The friction Apple has added to this process undermines users' switching to a new default browser that needs to be fixed in order for them to be in compliance with 6(3) and 13(4).
Similarly changing the default browser at the moment is quite difficult as well. Currently Apple does not have a centralised location to change the default browser in the settings. Searching "default" or "default browser" yields no results in settings and you can try it right now. Instead they have inappropriately placed it in each individual browser's settings page.
Astonishingly Apple has added custom code to hide the option to change default browser in the Safari settings if Safari is the default browser, and prominently show it if a different browser is default. We had thought that Apple would have fixed such an outrageous dark pattern prior to the DMA coming into force but in the latest version of iOS it is still present.
My question to Apple is, are they planning on addressing these or not?
Apple's spokesperson responded with:
In terms of the first question, the choice as required by the DMA is presented once to users. Obviously there are a ton of other ways in which users can choose different browsers, different default browsers if they so choose. We have worked to make this simple and straightforward. And we know from the experience over the last couple of years that millions of users around the world choose alternative browsers all the time. We also know that many of them will choose to make that browser their default one of choice. That happens all the time. In terms of what's being required here by the DMA our focus is on presenting this choice even more clearly to consumers the first time you use Safari. Obviously there are not choices being presented when you use other browsers on iOS. So we are complying from our perspective with the spirit here.
The video of John's question and the reply is at the top of the article.
Let's break down Apple's reply.
Obviously there are a ton of other ways in which users can choose different browsers, different default browsers if they so choose. We have worked to make this simple and straightforward.
This is clearly false, and does not address any of the specifics in John's question.
And we know from the experience over the last couple of years that millions of users arround the world choose alternative browsers all the time.
This phrasing is very carefully steps arround the fact that Apple only started letting users change the default browser in late 2020. Clearly it's embarrassing that for 13 years it was impossible to change the default browser on iOS.
We also know that many of them will choose to make that browser their default one of choice. That happens all the time.
Apple doesn't publicly share any aggregated data on browser defaults, so it's hard to check.
In terms of what's being required here by the DMA our focus is on presenting this choice even more clearly to consumers the first time you use Safari. Obviously there are not choices being presented when you use other browsers on iOS.
The framing here, again, is false. As Apple stated in their opening speech there are two aspects of the DMA they have to comply with. One: making it easy to change the default. Two: allowing a choice screen. Apple obviously has no defence on the first and so tries to deflect by focusing on the second.
So we are complying from our perspective with the spirit here.
The Commission has opened proceedings against Apple regarding their measures to comply with obligations to (i) enable end users to easily uninstall any software applications on iOS, (ii) easily change default settings on iOS and (iii) prompt users with choice screens which must effectively and easily allow them to select an alternative default service, such as a browser or search engine on their iPhones.
The Commission is concerned that Apple's measures, including the design of the web browser choice screen, may be preventing users from truly exercising their choice of services within the Apple ecosystem, in contravention of Article 6(3) of the DMA.
This is just one topic among many, but we should know more when the EU releases its non-confidential version of its initial findings and invites third parties to comment which according to the act could take up to 3 months.
In order to be compliant with this specific aspect of the DMA we believe Apple should make the following changes:
Remove the dark pattern of hiding the option to switch default browser if the default is Safari.
Move the option to change default browser out of the browser settings and into a centralised location.
Have this option visible even if Safari is the only currently installed browser.
Have this option show up in search if the user searches for "default", "browser" or "default browser".
Allow browsers to know if they are the current default browser
Provide a system prompt to browsers (with the usual anti-nagging protections on all permission prompts) that allows browsers to prompt the user to one click set them as the new default browser as is standard on all other operating systems.
]]>
In-App Browsers: The worst erosion of user choice you haven't heard of2024-03-26T00:00:00Zhttps://open-web-advocacy.org/blog/in-app-browsers-the-worst-erosion-of-user-choice-you-havent-heard-of/
https://www.youtube.com/watch?v=-6mFC__dMWM
In-App Browsers subvert user choice, stifle innovation, trap users into apps, break websites and enable applications to severely undermine user privacy. In-App Browsers hurt consumers, developers and damage the entire web ecosystem.
OWA recently met with both the Digital Markets Act team and the UK's Market Investigation Reference into Cloud Gaming and Browsers team to discuss how tech giants are subverting users' choice of default browser via in-app browsers and the harm this causes.
In-App browsers is a complex topic, so to outline our thoughts we wrote a detailed 61 page submission to the EU Commission which we are now publicly publishing today.
So what are In-App Browsers, and what problems do they cause?
An In-App Browser can open when users tap on links in a non-browser app. Rather than switching out of the app and to the user's default browser, in-app browsers open a pane within the host native app to render web pages. Hence the name, “in-app browser”.
When you click on a link to a third-party website, many popular apps ignore your choice of default browser and instead automatically and silently replace your default browser with their own in-app browser. Many users - likely most users! - are not aware that this switch has taken place.
Worst of all, this switch grants these apps the ability to spy and manipulate third-party websites. Popular apps like Instagram, Facebook Messenger and Facebook have all been caught injecting JavaScript via their in-app browsers into third party websites. TikTok was running commands that were essentially a keylogger. While we have no proof that this data was used or exfiltrated from the device, the mere presence of JavaScript code collecting this data combined with no plausible explanation is extremely concerning.
It is possible to use in-app browsers in a way that preserves privacy. Both iOS and Android provide a system components (SFSafariViewController and Android Custom Tabs respectively), which do not allow the hosting app to inject JavaScript or otherwise spy on the user. Android Custom Tabs solution also (by default) invokes the users default browser.
Thus, this behavior would be impossible if links were simply opened in the user's default browser or in the system provided in-app browser.
This is the reality users face on their phones today. It doesn't have to be this way. Mandating that apps respect browser choice isn't just a matter of convenience; it's about empowering both consumers and companies to thrive in a more open, stable, feature rich, secure and private digital ecosystem.
Disrespect of users' choice of browser also stifles innovation. The Web thrives when browsers compete on functionality and user experience. In-app browsers, however, don't compete as browsers. Many, perhaps even most, users are unaware they are being foisted upon them. They're also unaware of the quality, security and privacy risks associated with them. In-app browsers operate in a vacuum, immune from competitive pressure to improve.
This stagnation hurts everyone. Users are stuck with forgetful, subpar in-app browsers. Businesses struggle to reach and engage with audiences due to missing features and bugs in browsers that no one made an affirmative choice to use.
The solution is clear – respect the user's choice of browser.
Mandating that non-browser apps utilise a users' default browser for third-party websites will unlock a more vibrant and equitable digital landscape. Users will enjoy familiar tools they trust, experiencing websites as they were designed. Businesses and publishers will gain access to earned audiences, free from interference by native app developers.
The intrusion of in-app browsers, along with the significant bugs, missing features and critical privacy and data protection concerns they introduce should be addressed. The Digital Markets Act and the UK's MIR have all of the necessary enforcement powers to right this wrong.
Remote tab in-app browsers such as Android Custom Tabs are a potentially ideal solution for most users. Android Custom Tabs, by default, invokes the user's default browser and prevents the app injecting JavaScript. This is an interesting middle ground where the user (and the app) can benefit from not leaving the app context while still respecting the user's choice of default browser and preserving the user's privacy. However, it is currently possible for the hosting native app to lock Android Custom Tabs to a particular browser and override the user's choice of default browser. This ability needs to be removed.
While iOS's remote tab in-app browser (SFSafariViewController) prevents the app injecting JavaScript, it is locked to Safari (or more specifically the WkWebView) and thus overrides the user's choice of default browser.
We have proposed 6 remedies:
Designated Core Platform Services should respect the user's choice of default browser. (DMA specific)
App Store rules must mandate non-browser apps use the user's chosen default browser for http/https links to third-party websites/Web Apps.
Apple must update SFSafariViewController (Apple's system provided in-app browser for iOS) to respect the user's choice of default browser.
Third-Party businesses must be provided an explicit and effective technical opt-out from non-default In-App Browsers.
Operating systems must provide a global user opt-out. Apps must also request explicit permission from users in order to override their choice of default browser.
Google must remove the ability to override a user's choice of default browser via Android Custom Tabs (Google's system provided in-app browser for Android).
These remedies overlap, addressing different aspects of the problem. When effected, these remedies will prevent gatekeepers from subverting the user choice of browser, provide users enhanced control over their privacy and security, and make technical fixes to the underpinnings of how web pages are loaded. These fixes will project a user's choice of browser in non-browser apps they use, providing users the security, privacy, stability and features on which browser wars are legitimately fought. No longer will apps be allowed to syphon web traffic for their own enrichment at the detriment of the community at large.
We would in particular like to thank Lukasz Olejnik, Felix Krause, Jesper van den Ende, Stuart Langridge, Bruce Lawson and Adrian Holovaty for their work in helping make this case. We are also thankful for the broad support and feedback we have received from the web development and browser development community.
We will continue to pursue this matter until it is fixed globally. Users' choice of browser is only important if that choice is actually respected.
]]>
EU opens DMA investigations of Apple, Meta, Google2024-03-25T00:00:00Zhttps://open-web-advocacy.org/blog/eu-opens-dma-investigations/
This morning, the EU announced that
the Commission has opened non-compliance investigations under the Digital Markets Act (DMA) into Alphabet's rules on steering in Google Play and self-preferencing on Google Search, Apple's rules on steering in the App Store and the choice screen for Safari and Meta's “pay or consent model”.
The Commission suspects that the measures put in place by these gatekeepers fall short of effective compliance of their obligations under the DMA.
In addition, the Commission has launched investigatory steps relating to Apple's new fee structure for alternative app stores and Amazon's ranking practices on its marketplace.
We welcome the investigations, and it's telling that it comes after last week's compliance workshops, when gatekeepers were invited by the EU to answer questions on their compliance plans from stakeholders (but not from the EU themselves).
Certainly, in the case of Apple, we found their responses to questions to be just that: responses, rather than answers. See for yourself! Our very own John Ozbay asked why a user who selects Firefox from the browser choice screen will still see Safari in the 'hot seat' position.
Apple's legal team respond by telling us how customisable the home screen is. But they forget to tell us why they continue to give Safari the hot seat, rather than promote Firefox after the user chose it.
https://www.youtube.com/watch?v=_m6tQtDpSbM
John then asks why there is no centralised system on iOS to change the default browser. He notes that each browser's setting page has the option to change the default browser, except for Safari's which does not offer a change default, and asks
we had thought that Apple would have fixed such
a dark pattern prior to the DMA coming into force but in the latest version of iOS, it seems that it is still present. My question is, is Apple planning on addressing these or not?
Strangely, again, John's question is not answered. We are told that millions of people have changed their default browser (we know! choice is good!) and
we are complying from our perspective with the spirit here.
From our perspective, this is not complying.
https://www.youtube.com/watch?v=AiiU_zBirXc
This pattern of forgetting the question continues. John notes Apple's DMA compliance plan includes a Browser Entitlement Contract full of legal traps for competing browsers, effectively making it impossible for competing browser vendors to sign the contract and ship their browser engines on iOS for their EU users. John asked
Will you at least make them minimally viable in the EU by enabling browsers to ship their own engines under a single app ID and rewrite your contract so that they're both reasonable and compliant with the DMA?
https://www.youtube.com/watch?v=s41Ha8lZ0Zk
Apple's reply was that the changes required under the DMA are "a very massive complicated engineering effort". We don't doubt that; luckily, Apple employs very talented engineers and probably has enough money in the bank to employ a few more.
But after this uplifting tale of Herculean efforts undergone in Cupertino, John's questions were not answered–even after another questionner asked
Is it admissible that I give my speaking time back
to refer to the questions that the colleagues from the Open Web Advocacy had asked about the contracts and the possibility that those are incompatible with DMA, because those haven't been answered at all?
Another workshop attendee and John asked whether Apple would abide by the DMA and allow Progressive Web Apps (in Apple parlance, Home Screen Apps) to use third-party engines.
Amazingly, the Apple representatives forgot that a direct queston had been asked of them a mere 23 seconds previously, merely noting that Home Screen Apps will work "as before" (only with WebKit, so presumably: "no").
https://www.youtube.com/watch?v=yHdG_3sSSqQ
Towards the end of the workshop, John noted that Apple's 12 page compliance report was immensely lighter in detail than Microsoft's 421 pages or Google's 271 pages, and asked
does Apple honestly believe their 12-page document enables third parties like us to comprehensively assess whether they comply with all of the obligations laid down in the DMA?
This at least got a straight answer:
I think everyone in this room understands what Apple has done to comply with the DMA. So I think we've accomplished our goal there.
https://www.youtube.com/watch?v=aR83Cs47A-Y
Sadly, however, not everyone in the room understood what Apple has done to comply with the DMA, hence today's announcement.
Ultimately, of course, our hope is that the investigations don't take 12 months and result in fines.
The better outcome would be for Apple to acknowledge that their initial compliance plans do not come near to meeting the intent of the DMA, and for them to re-think and submit detailed plans, with timings, on how they will provide customers with a fair, genuine browser choice.
We would also like to understand if, how and when Apple intends to fix their ridiculous and clearly non-compliant contractual terms that make it as Mozilla put it "as painful as possible" for browser vendors to port their real browsers to iOS.
]]>
US Department of Justice files Antitrust lawsuit Against Apple2024-03-21T00:00:00Zhttps://open-web-advocacy.org/blog/us-doj-files-apple-antitrust-case/
Today, the contents of the US Department of Justice antitrust lawsuit against Apple were revealed. The DOJ along with 16 State's Attorneys General are co-litigants against Apple, claiming a series of unlawful behaviours by the tech giant.
The suit is wide sweeping, and takes issue with Apple's monopolising tactics in the smartphone market. But, flipping to page 22, we see details of particular interest to OWA and the #AppleBrowserBan:
"Developers cannot avoid Apple’s control of app distribution and app creation by making web apps—apps created using standard programming languages for web-based content and available over the internet—as an alternative to native apps. Many iPhone users do not look for or know how to find web apps, causing web apps to constitute only a small fraction of app usage. Apple recognizes that web apps are not a good alternative to native apps for developers. As one Apple executive acknowledged, “[d]evelopers can’t make much money on the web.” Regardless, Apple can still control the functionality of web apps because Apple requires all web browsers on the iPhone to use WebKit, Apple’s browser engine—the key software components that third-party browsers use to display web content."
The entire suit is fantastic reading for anyone fed up with the bullying tactics of Apple. With this news following so tightly on from the EU's Digital Markets Act coming into effect, the dominos are beginning to fall in favour of a fairer, better Open Web!
]]>
The Digital Markets Act is in force! What happens now?2024-03-07T00:00:00Zhttps://open-web-advocacy.org/blog/the-digital-markets-act-is-in-force-what-happens-now/
The Digital Markets Act (DMA) grace period for gatekeepers to comply has now ended.
The DMA is EU legislation that came into law on the 1st of November 2022 that aims to improve fairness, contestability and interoperability in very large platforms that operate in the EU that have significant and durable market power. In order to not impose expensive compliance obligations on small and medium businesses, the act only applies to truly massive companies with significant revenue that operate platforms used by tens of millions of EU consumers.
The DMA comes with serious teeth, they have the power to fine gatekeepers up to 10% of global revenue repeatedly until they comply with the act. For reference Apple had a global revenue of $383 billion USD in 2023 and their net profit was $100 billion USD, meaning that the maximum cost of a single fine under the DMA is $38.3 billion USD, a sum any gatekeeper would surely blink at. In the case of repeated non-compliance they can fine up-to 20% of global revenue in a single fine.
Currently there are six gatekeepers who have been designated: Amazon, Apple, ByteDance, Google, Meta, and Microsoft. Reportedly X (formerly Twitter) and travel website group Booking could be added to the list in the near future.
These gatekeepers have a number of “core platform services” that have been formally designated under the DMA. To be automatically designated the service must have at least 45 million users in the EU and at least ten thousand business users. Further they need to be of a type of platform covered by the act. Currently the types listed in the act are:
Being designated means that the gatekeeper must make sure the designated core platform service is fully compliant with the DMA before the end of the 6 month grace period. That grace period ended today. The DMA is ex-ante which means it is the gatekeepers responsibility to make sure and show that they are in compliance.
The core platform services that have been designated, split by type are:
That grace period has now officially ended, so what happens now? First each of the gatekeepers is required to have submitted a compliance report to the Commission as well as a public summary. Then, likely for the first few weeks nothing. The EU Commission is an evidence based organisation and will need time to assess how well each of the gatekeepers are complying with the DMA and select the highest priority targets to start proceedings against first.
Many observers, including us, believe that Apple due to its combative and belligerent approach will be the first to be hit, likely with multiple proceedings. Indeed fireworks came early with Apple’s attempt to sabotage Web Apps in the EU prior to the DMA coming into force.
Luckily for the web, Apple’s plan faced massive backlash. Our open letter to Tim Cook on the subject had 4640 individuals and 483 organisations sign. Signatures included two European MEPs (Karen Melchior & Patrick Breyer); a number of significant EU companies such as social media platform Mastodon; and individuals (advocating in their personal capacity) who work for SwissLife, Tchibo, W3C, Mozilla, Google, Microsoft, Vivaldi, BBC, Financial Times, Red Hat, Oracle, Amazon, Wikimedia, Vercel, Netlify, Shopify, Spotify, AirBNB, Berlin University of the Arts, Open State Foundation - Netherlands, Cloudflare, Meta, Chase, Squarespace, Reddit, Atlassian, Maersk, Paypal, Salesforce, block, Adobe, ebay, Zynga, booking.com and thoughtworks; and many other developers and organisations from over 100 countries.
Three days later Apple caved and reversed their decision to break all Web Apps in the EU for millions of consumers.
The EU Commission said in a statement that:
“Contrary to Apple’s public representation, the removal of Home Screen Web Apps on iOS in the EU was neither required, nor justified, under the Digital Markets Act,”
Three European parliament MEPs — Karen Melchior, Tiemo Wölken, and Patrick Breyer — said in a statement to the Financial Times that it would be “in flagrant violation of the spirit, and likely the word of the DMA”, and reminded the company of the EU’s power to enforce fines of up to 10 percent of a company’s annual turnover under the new rules.
Given Apple is not a company that backs down easily or quickly, the only plausible explanation is that Apple’s lawyers decided that the plan to sabotage Web Apps in the EU (and in effect globally) would subject Apple to immediate and serious legal risk, and recommended reversing course. This is important as it shows that public outreach combined with regulatory intervention can curb the worst of Apple’s anti-competitive behaviour and not even their billion dollar a year legal budget is sufficient to maintain it. The combination of strong laws and advocacy can protect the open web.
Our non-profit organisation has two aims:
Fair and effective browser competition on all general purpose operating systems
Fair and effective Web App competition on all general purpose operating systems, in particular we are aiming for feature parity between Web Apps and Native Apps.
For readers who are unaware, Apple has effectively banned third party browsers on iOS for the last 15 years by preventing them from using their own browser engine. Instead third party browsers vendors were forced to build a thin user interface shell around the WebKit WkWebView shipped with iOS, making them reskinned versions of Safari.
With that context and these aims in mind, it's worth exploring the DMA and what changes it brings to the EU in relation to browsers, Web Apps and Web and what exactly the gatekeepers are obligated to do.
When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications.
Digital Markets Act - Recital 43
This section is particularly important as it outlines what the DMA’s purpose is in prohibiting banning browser engines. Specifically it is to prevent gatekeepers from blocking competitors from providing functionality to competing browsers and to “web software applications”.
This was likely, at least in part, based on the conclusions of the UK regulator who stated:
Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
UK CMA - Interim Report into Mobile Ecosystems
(emphasis added)
Articles 5(7) The gatekeeper shall not require end users to use, or business users to use, to offer, or to interoperate with, an identification service, a web browser engine or a payment service, or technical services that support the provision of payment services, such as payment systems for in-app purchases, of that gatekeeper in the context of services provided by the business users using that gatekeeper’s core platform services.
Digital Markets Act - Article 5(7)
(emphasis added)
This is the specific part of the act that actually prohibits gatekeepers from imposing browser engines. It does not allow the gatekeeper any leeway to prevent this.
Article 6(7) The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services.
The gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.
Digital Markets Act - Article 6(7)
This article states that designated operating systems must provide API access to third parties for the purpose of interoperability (i.e. making their software/hardware work on or with the device). Importantly it states that this must be provided “free of charge”.
The “free of charge” appears to throw a spanner in the works of Apple’s Core Technology Fee which is a 50c per user per year fee for API access that Apple will charge for all app downloads (including app downloads from Apple’s App Store) of any developers that dares to list their app on a different app store on iOS. It’s hard to see how Apple’s lawyers possibly thought this would be compliant but does give some insight as to the level of hubris and belligerence that Apple is operating at here.
Gatekeepers are only allowed strictly necessary, proportional and justified security measures to prevent compromising “the integrity of the operating system”. Justified here means that the burden of proof is on the gatekeeper to show that the measure is strictly necessary and proportional.
A gatekeeper can use different means to favour its own or third-party services or products on its operating system, virtual assistant or web browser, to the detriment of the same or similar services that end users could obtain through other third parties.
Digital Markets Act - Recital 49
In such situations, the gatekeeper should not engage in any form of differentiated or preferential treatment in ranking on the core platform service, and related indexing and crawling, whether through legal, commercial or technical means, in favour of products or services it offers itself or through a business user which it controls. To ensure that this obligation is effective, the conditions that apply to such ranking should also be generally fair and transparent. Ranking should in this context cover all forms of relative prominence, including display, rating, linking or voice results and should also include instances where a core platform service presents or communicates only one result to the end user.
Digital Markets Act - Recital 52
(emphasis added)
Article 6(5) The gatekeeper shall not treat more favourably, in ranking and related indexing and crawling, services and products offered by the gatekeeper itself than similar services or products of a third party. The gatekeeper shall apply transparent, fair and non-discriminatory conditions to such ranking.
Digital Markets Act - Article 6(5)
These recitals and articles state that the gatekeeper can not self-preference themselves in various forms of ranking. This could apply to the user interface design of iOS where in the settings Apple’s apps get special locations, various undermining of browser choice by Microsoft on Windows or Google prompting users to download Chrome on google.com or youtube.com in locations that competitors can not. All of these behaviours are now prohibited in the EU.
Article 6(3) The gatekeeper shall allow and technically enable end users to easily un-install any software applications on the operating system of the gatekeeper, without prejudice to the possibility for that gatekeeper to restrict such un-installation in relation to software applications that are essential for the functioning of the operating system or of the device and which cannot technically be offered on a standalone basis by third parties.
The gatekeeper shall allow and technically enable end users to easily change default settings on the operating system, virtual assistant and web browser of the gatekeeper that direct or steer end users to products or services provided by the gatekeeper. That includes prompting end users, at the moment of the end users’ first use of an online search engine, virtual assistant or web browser of the gatekeeper listed in the designation decision pursuant to Article 3(9), to choose, from a list of the main available service providers, the online search engine, virtual assistant or web browser to which the operating system of the gatekeeper directs or steers users by default, and the online search engine to which the virtual assistant and the web browser of the gatekeeper directs or steers users by default.
Digital Markets Act - Article 6(3)
This article mandates browser and search engine choice screens in the EU. Mozilla recently did a study that showed a well designed choice screen could cause significant changes in market share, specifically Firefox could increase its market share to 20%.
Article 6(4) The gatekeeper shall allow and technically enable the installation and effective use of third-party software applications or software application stores using, or interoperating with, its operating system and allow those software applications or software application stores to be accessed by means other than the relevant core platform services of that gatekeeper. The gatekeeper shall, where applicable, not prevent the downloaded third-party software applications or software application stores from prompting end users to decide whether they want to set that downloaded software application or software application store as their default. The gatekeeper shall technically enable end users who decide to set that downloaded software application or software application store as their default to carry out that change easily.
The gatekeeper shall not be prevented from taking, to the extent that they are strictly necessary and proportionate, measures to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper.
Furthermore, the gatekeeper shall not be prevented from applying, to the extent that they are strictly necessary and proportionate, measures and settings other than default settings, enabling end users to effectively protect security in relation to third-party software applications or software application stores, provided that such measures and settings other than default settings are duly justified by the gatekeeper.
Digital Markets Act - Article 6(4)
This article states that operating system gatekeepers need to allow third parties to be able to install their apps both by other app stores and directly (i.e. via a link over the internet).
The gatekeeper is allowed to take strictly necessary, proportional and justified security measures to protect the integrity of the hardware or operating system.
Article 6(12) The gatekeeper shall apply fair, reasonable, and non-discriminatory general conditions of access for business users to its software application stores, online search engines and online social networking services listed in the designation decision pursuant to Article 3(9).
For that purpose, the gatekeeper shall publish general conditions of access, including an alternative dispute settlement mechanism.
The Commission shall assess whether the published general conditions of access comply with this paragraph.
Digital Markets Act - Article 6(12)
This states that the terms of the app stores shall be fair, reasonable and non-discriminatory. It seems likely the exact meaning of “fair” will be extensively litigated in the EU. The act contains this paragraph to explain what “fair” means in more detail:
Pricing or other general access conditions should be considered unfair if they lead to an imbalance of rights and obligations imposed on business users or confer an advantage on the gatekeeper which is disproportionate to the service provided by the gatekeeper to business users or lead to a disadvantage for business users in providing the same or similar services as the gatekeeper. The following benchmarks can serve as a yardstick to determine the fairness of general access conditions: prices charged or conditions imposed for the same or similar services by other providers of software application stores; prices charged or conditions imposed by the provider of the software application store for different related or similar services or to different types of end users; prices charged or conditions imposed by the provider of the software application store for the same service in different geographic regions; prices charged or conditions imposed by the provider of the software application store for the same service the gatekeeper provides to itself
Crucially the terms the gatekeeper is allowed to set is for being on the app store, not being on the operating system. Gatekeepers have no ability under the act to set terms for being on the operating system beyond strictly necessary, proportional and heavily justified security measures.
Article 13(4) The gatekeeper shall not engage in any behaviour that undermines effective compliance with the obligations of Articles 5, 6 and 7 regardless of whether that behaviour is of a contractual, commercial or technical nature, or of any other nature, or consists in the use of behavioural techniques or interface design.
Digital Markets Act - Article 13(4)
This article grants the commission extremely broad powers to prevent gatekeepers seeking to avoid their obligations via “malicious compliance”. Clearly it was anticipated that at least a few of the gatekeepers would seek to undermine and circumvent the act.
Article 13(6) The gatekeeper shall not degrade the conditions or quality of any of the core platform services provided to business users or end users who avail themselves of the rights or choices laid down in Articles 5, 6 and 7, or make the exercise of those rights or choices unduly difficult, including by offering choices to the end-user in a non-neutral manner, or by subverting end users’ or business users' autonomy, decision-making, or free choice via the structure, design, function or manner of operation of a user interface or a part thereof.
Digital Markets Act - Article 13(6)
This article is to prevent gatekeepers from circumventing obligations by degrading the core platform service. It seems likely that this applied to Apple’s attempt to remove Web App installation in the EU as a method to avoid sharing it with third party browsers using their own engines, thus circumventing their obligations under Article 5(7). Apple essentially admitted this was the purpose of removing the functionality in their initial statement where they stated:
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.
Apple's statement on breaking Web Apps in the EU
(emphasis added)
Article 30(1) In the non-compliance decision, the Commission may impose on a gatekeeper fines not exceeding 10 % of its total worldwide turnover in the preceding financial year where it finds that the gatekeeper, intentionally or negligently, fails to comply with:
(a) any of the obligations laid down in Articles 5, 6 and 7;
(b) measures specified by the Commission in a decision adopted pursuant to Article 8(2);
(c) remedies imposed pursuant to Article 18(1);
(d) interim measures ordered pursuant to Article 24; or
(e) commitments made legally binding pursuant to Article 25.
Digital Markets Act - Article 30(1)
This article outlines the fines the commission can impose on gatekeepers that violate any part of Article 5, 6 or 7. In this case the maximum individual fine is 10% of global revenue.
Article 30(2). Notwithstanding paragraph 1 of this Article, in the non-compliance decision the Commission may impose on a gatekeeper fines up to 20 % of its total worldwide turnover in the preceding financial year where it finds that a gatekeeper has committed the same or a similar infringement of an obligation laid down in Article 5, 6 or 7 in relation to the same core platform service as it was found to have committed in a non-compliance decision adopted in the 8 preceding years.
Digital Markets Act - Article 30(2)
This article states that if the gatekeeper commits the same violation twice the commission can fine them up to 20% of global revenue in a single fine.
OWA is a global organisation and in order for both browser and web app competition to be both fair and effective these changes need to happen in as many jurisdictions as possible, and push for global uniformity.
That said, securing these changes in the EU will be a massive win for two reasons. First EU consumers and businesses can experience the benefits of increased competition and interoperability. Second, every major regulator on the planet is looking carefully at the DMA and planning their own regimes. Any success in the EU will provide these regulators with a mountain of evidence and a blueprint to force these gatekeepers to behave.
Some important aims that could be achieved under the DMA are:
Allow other browsers to compete fairly and effectively on iOS with their own engine
Currently Apple’s browser engine entitlement contract (a contract specifically for allowing API access) is riddled with outrageously unfair terms and given that Apple is only allowed to have strictly necessary, proportional and heavily justified security clauses in the contract it will need to be rewritten in order to be compliant with the DMA.
Force both Apple and Google to let other browsers install web apps powered by their own engine
Currently Apple does not let browsers install web apps on iOS powered by the browsers own engine at all. Google does not let other browsers install web apps properly to achieve full system integration via WebAPK minting which is locked to Chrome. Both companies must open this up to third party browsers to be compliant with the DMA.
Ensure users choice of default browser is respected
In many cases on both iOS and Android the user’s choice of default browser is completely ignored. The default browser should be opened or invoked when the user clicks on a link in a non-browser app. Instead in many cases it is silently hijacked and replaced by a completely different in-app browser. Neither the operating system or the non-browser apps on it should engage in browser-jacking.
Stop Apple from preventing browsers being listed on third party app stores on iOS
As discussed earlier, Apple’s Core Technology Fee for API access is clearly designed to prevent developers from listing their apps on third party apps stores on iOS. Given that API access is mandated to be “free of charge” under the act, Apple will need to update this in order to be in compliance with the DMA.
Further having a separate alternative contract with which developers can opt into their rights under the DMA at different fee structures is both bizarre and ridiculous.
Stop companies self preferencing their own browser by their core platform services
Apple, Google and Microsoft have all engaged in behaviours and dark patterns to self preference their browsers by their various designated core platform services. These behaviours are now prohibited in the EU by the DMA.
Safari needs to allow fair competition of competing payment providers
Currently Safari only supports Apple Pay, as a core platform service Apple is obligated to update it so that the user can choose alternative payment providers.
Reduce the power of default browser with a choice screen
Ensure that both Apple and Google implement effective designs for their browser choice screens. Specifically the choice screen should not self preference their own browsers, should grant the chosen browser the “hotseat” and should appear on all existing devices once and all new devices (including after backup and restore).
Ensure that backups and restore works for Web Apps
Currently on both iOS and Android Web Apps are not included in device backups. This puts Web Apps at a disadvantage to Native Apps and needs to be fixed by both Apple and Google.
To be clear these obligations needed to have been already met by today, the fact they aren't means that they are already in breach of the DMA. From OWA’s perspective we will lodge complaints about gatekeepers who have not met their obligations unless they are making timely good faith efforts to push as quickly as possible towards compliance.
If fair and effective competition for both browsers and Web Apps was allowed, 90% of the apps on your phone could be written as a Web App and would be indistinguishable, significantly cheaper and often better than native apps. Native Apps will still have a lead in cutting edge graphics and gaming technology but here’s the thing, if companies see the Web platform as viable, they’ll invest in it and this gap will get narrower and narrower.
Over the next ten years the Web will provide more and more for consumers. Simply put, what the Web “can't do” is shrinking while its advantages are only increasing.
But for certain clear anti-competitive behaviour, mobile Web Apps would already be viable and thriving. Absent laws to prevent them from doing so, large gatekeepers are incentivized to block products they can’t excessively tax OR that compete with their own products.
The Web can do so much more on mobile, we just have to let it.
]]>
Apple backs off killing web apps, but the fight continues2024-03-01T00:00:00Zhttps://open-web-advocacy.org/blog/apple-backs-off-killing-web-apps/
In a huge relief to developers and supporters of the open web, and under immense backlash, Apple has cancelled its plan to sabotage Web Apps!. This ends weeks of fear and uncertainty for developers and users.
We would like to say a massive thank you to the DMA team as Apple's decision is no doubt related to the investigation they had opened. But our most heartfelt thanks are to the thousands of developers who took the time to fill in our survey and sign the open letter, to show Apple that developers and businesses can't be used as pawns. We are grateful for your help and no doubt will need it again - know that your voices were heard in Brussels and Cupertino, and have made a difference.
The battle is not over, This simply returns us back to the status quo prior to Apple's plan to sabotage Web Apps for the EU. Apple’s over a decade suppression of the web in favour of the AppStore continues worldwide, and their attempt to destroy web apps in the EU is just their latest attempt. If there is to be any silver lining, it is that this has thoroughly exposed Apple’s genuine fear of a secure, open and interoperable alternative to their proprietary App Store that they can not control or tax.
The Digital Markets Act (DMA) became law on 14 September 2022 and designated gatekeepers were given a 6 month grace period to comply with the regulations. Since Apple was certain to be designated this means they had almost one and half years to make the required changes.
However over the last 5 months, Apple took a different approach, one where it has continuously tried to undermine the DMA at every step, including:
On 28th of January 2024, they pulled a new trick: break all Web Apps in the EU entirely. We first noticed it in the first beta for iOS 17.4.
Initially they tried to keep it a secret. Extraordinarily there was no mention of this in their DMA compliance plan, the iOS beta notes or the Safari beta notes. Given how detailed these typically are and the magnitude of the change, it is impossible that this was an oversight. Clearly Apple was attempting to sneak this past the developers, users and regulators to provide everyone minimal time to respond.
After 2 weeks, in the face of steadily increasing developer and media backlash, Apple was forced to rush out this statement where they confirmed they were deliberately breaking Web Apps and that it had been planned. Astonishingly the iOS and Safari release notes have still not been updated.
We, of course, had to act. We immediately informed the DMA team and then launched a series of surveys to demonstrate how detrimental this would be to businesses and users in the EU. We had over a thousand responses in a few short days and this allowed us to hand the EU excellent information about the immediate cost of Apple breaking Web Apps.
We then worked shifts around the clock to launch our incredibly successful open letter to Tim Cook. The letter has already garnered worldwide support and has had 4264 individuals and 441 organisations sign. Signatures include two European MEPs (Karen Melchior & Patrick Breyer); a number of significant EU companies such as social media platform Mastodon; and individuals (advocating in their personal capacity) who work for SwissLife, Tchibo, W3C, Mozilla, Google, Microsoft, Vivaldi, BBC, Financial Times, Red Hat, Oracle, Amazon, Wikimedia, Vercel, Netlify, Shopify, Spotify, AirBNB, Berlin University of the Arts, Open State Foundation - Netherlands, Cloudflare, Meta, Chase, Squarespace, Reddit, Atlassian, Maersk, Paypal, Salesforce, block, Adobe, ebay, Zynga, booking.com and thoughtworks; and many other developers and organisations from over 100 countries.
While this is a stunning victory for the web, it is just one part of a longer battle.
Since iOS’s inception Apple has essentially banned third party browsers from competing on iOS. All browsers currently on iOS are essentially re-skinned versions of Safari.
Further Apple has set a ceiling on Web App functionality by denying them access to key features they need to compete. Apple has deliberately ensured that web apps are hidden in the operating system, and have not provided the ability to show an install button as they do with native apps.
Combined with significant bugs, this has suppressed the uptake of Web Apps on mobile devices globally. Despite this, a significant number of consumers and organisations use them as a secure, open, interoperable and untaxed alternative to Apple’s and Google’s proprietary App Stores.
This has also been noted by multiple regulators world wide:
Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
UK CMA - Interim Report into Mobile Ecosystems
(emphasis added)
The code of conduct for mobile OS services could require Designated Digital Platforms to allow third-party browser engines to be used on their mobile OS. This could allow third-party providers of browsers and web apps to compete on their merits.
The Australian Competition and Consumer Commission
Mandatory use of WebKit and reluctance to support web apps in browsers (Apple)
Third-party browsers are forced to provide services based on WebKit, which lacks support for web apps, and competition through ingenuity among browsers may be impeded.
Japan’s Headquarters for Digital Market Competition
The reason the DMA states to open up browser engine competition (and iOS is the only major consumer operating system that bans competing engines) was to prevent gatekeepers from stopping third party browsers using their own engines to bring features to “web software applications”. This is stated in the act itself:
When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications.
Digital Markets Act
(emphasis added)
The fight is not over and will not be over until Apple allows both browsers and web apps to compete fairly on all their platforms globally. OWA will continue to work with both the EU Commision and regulators worldwide.
The enormous impact we’ve had over the last few weeks could not have been achieved without your support! Thank you to everyone who submitted a response to a survey, signed the letter or shared our calls to action on social media. We couldn’t have done this without you.
Behind the scenes, a small team of dedicated volunteers have worked almost non-stop for the past month to build and launch our surveys, open letters, social media campaigns, translate content, provide technical advice and write multiple lengthy regulatory submissions.
We’d like to personally thank, John Ozbay, Jasper Van den Ende, Lukasz Olejnik, Bruce Lawson, Runos, Mysk, and Stuart Langridge for their support and we’d like to especially thank the open letter team, for putting in near full-time hours to keep the letter up and running 24/7, namely, Art Müller, Steven Beshensky, Jasper Van den Ende, Nick Chomey, Roderick Gadellaa and Angela Ricci. We’d like to say thank you to so many people at different organisations, who also fought hard on our side.
OWA is incredibly grateful for your time and dedication and the web will be forever in your debt.
We’d also like to thank everyone who has donated time or money, and all of our friends, family and colleagues who have allowed us the space and time to dedicate ourselves to this work in this extremely high-pressure moment. Thank you. ❤️
]]>
It’s Official, Apple Kills Web Apps in the EU2024-02-16T00:00:00Zhttps://open-web-advocacy.org/blog/its-official-apple-kills-web-apps-in-the-eu/
If you ship a Web App in the EU and will be impacted by this, please sign our open letter to Tim Cook. It is critical that we gather as much evidence as possible to prevent Apple from breaking Web Apps in the EU.
Nearly two weeks ago we discussed a bug on iOS Beta 17.4 breaking Web App installation in the EU. Yesterday we raised the alarm that this appeared to be not a bug but a deliberate choice on Apple’s part. Today Apple officially confirmed our suspicions in an update to their compliance proposal.
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.”
This is emphatically not required by the EU’s Digital Markets Act (DMA). It’s a circumvention of both the spirit and the letter of the Act, and if the EU allows it, then the DMA will have failed in its aim to allow fair and effective browser and web app competition.
It’s telling that this is the feature that Apple refused to share. And it makes sense: the idea that users could install safe and secure apps that Apple can’t tax, block or control is terrifying to them.
The legal obligation to allow third-party browsers onto iOS removes their ability to set a ceiling on web app functionality via their control of Safari and the WKWebView. Suddenly Web Apps would be a viable competitor. It is particularly galling for them to cite low adoption when they have had their thumb on the scale suppressing them for over a decade.
The DMA compels them to allow third party app stores, but Apple’s plan is to cripple them with their hardware and software API fee (Core Technology Fee) and their ludicrous “opt-in to your legal rights” at a different price alternative contract.
But web apps are much harder to stop. Even Apple admits WebKit’s sandbox is, to quote them ”orders of magnitude more stringent than the sandbox for native iOS apps”. They tried claiming to the UK regulator that Safari is more secure than other major browsers but decisively lost that argument.
So this is their new tactic: Kill off a competitor while saying the EU made them do it.
Apple has had 15 years to allow third party browsers the ability to compete in web app functionality and nearly 2 since they knew they would be legally compelled to do so.
Apple also makes tenuous, bordering on laughable, claims regarding web app security. In addition to unwarranted and unjustifiable attempts to project their own model onto competing browsers, Apple makes claims that ignore the history of web applications and browsers in providing strong privacy and security separation. Apple offers no evidence to back these assertions, and ignores the long track record of superior security of PWAs on other OSes.
Again and again, Apple has offered paper-thin fig-leaf arguments based on security to duck regulation, only to have these ploys rejected in nearly every jurisdiction where evidence is critically examined. This appears to be another instance of the same willfully misleading pattern. If security posturing is the backbone of Apple’s attempt to duck conformance with the DMA, the EU must reject the proposal and find Apple willfully non-compliant.
Apple also makes a self-fulfilling argument regarding the low use of iOS homescreen web apps. This is a situation of Apple’s own making and, indeed, a large part of why OWA has invested so much in reversing Apple’s history of self-preferencing towards native apps that Apple can tax through its App Store monopoly. Instead of offering equivalent affordances for websites looking to compete with App Store alternatives, Apple’s answer is to remove the capability, destroy critical features, and engender data loss for users and businesses that had invested in the web as a platform. Malicious destruction may be Apple’s attempt at an answer, but it is not a solution.
The next question is: Why all the secrecy? There was nothing in their compliance plan, Safari’s release notes or the beta’s release notes. Given that they are now stating they knew all along, it seems they wanted to see if they could sneak this past.
Clearly the backlash has caught them off guard and that’s why they had to rush out this panicked response, the only significant update they have made to their compliance proposal.
We always assumed that the commission would have to fine Apple billions to force them to allow the web to compete fairly and effectively with their App Store but it’s still incredibly disappointing to see Apple behave like this.
This is a message in a bottle to regulators world-wide: Apple will stop at nothing to protect its app distribution monopoly and the rent that comes with it, including removing critical features from its OSes without the slightest care for its users. It will not act in good faith, it must be forced.
We will continue to work with the EC to ensure that Web Apps can remain first-class citizens for iOS users, businesses, and competing browser vendors.
]]>
Apple on course to break all Web Apps in EU within 20 days2024-02-15T00:00:00Zhttps://open-web-advocacy.org/blog/apple-on-course-to-break-all-web-apps-in-eu-within-20-days/
In 2011, Philip Schiller internally sent an email to Eddie Cue to discuss the threat of HTML5 to the Apple App Store titled “HTML5 poses a threat to both Flash and the App Store”.
Food for thought:
Do we think our 30/70% split will last forever? While I am a staunch supporter of the 30/70% split and keeping it simple and consistent across our stores, I don’t think 30/70 will last unchanged forever. I think someday we will see a challenge from another platform or a web based solution to want to adjust our model
Internal Apple Emails
(emphasis added)
Luckily for Apple, they had a powerful tool to keep the Web at bay: ironclad control of iOS and the ability to block other browser vendors from bringing their more powerful platforms to Apple users. Meanwhile, Cupertino retained full control over the feature set of the only iOS browser engine, allowing it to suppress potential competition from the web through inaction. By simply failing to add important features, Apple could ensure the web never came within striking distance of being a credible threat.
Regulators around the world have taken note:
Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
UK CMA - Interim Report into Mobile Ecosystems
(emphasis added)
The code of conduct for mobile OS services could require Designated Digital Platforms to allow third-party browser engines to be used on their mobile OS. This could allow third-party providers of browsers and web apps to compete on their merits.
The Australian Competition and Consumer Commission
Mandatory use of WebKit and reluctance to support web apps in browsers (Apple)
Third-party browsers are forced to provide services based on WebKit, which lacks support for web apps, and competition through ingenuity among browsers may be impeded.
Japan’s Headquarters for Digital Market Competition
The Digital Markets Act even stated it as the primary motivation to prohibit banning browser engines:
When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications.
Digital Markets Act
(emphasis added)
We wrote last week about concerning changes in iOS 17.4 Beta 1 (EU). Sites installed to the homescreen failed to launch in their own top-level activities, opening directly in the default browser instead, even when the default browser is the browser that installed it. This demotes Web Apps from first-class citizens to mere shortcuts. Developers have since confirmed this does not occur outside the EU. Two betas later it is becoming more likely that this is a deliberate choice on the part of Apple to remove the ability to install Web Apps.
This cannot be mere oversight. The inability of third-party browsers to compete in the provision of web app functionality was discussed in no less than four regulator's investigations. Potential competition from Web Apps was directly stated in the DMA as the motivation to prohibit banning competing browser engines. it seems highly unlikely that the policy team working for Apple were unaware that they were required to allow third-party browsers to install and power Web Apps using their own browser engines.
Yet when Apple announced their compliance proposal for the DMA, Web Apps were noticeable by their absence. This is the same Apple that again and again claims that Web Apps are the alternative distribution method for Apps in their mobile ecosystem.
QUESTION: Apple is the sole decision maker as to whether an app is made available to app users though the Apple Store, isn't that correct?
REPLY: If it’s a Native App, yes sir, if it’s a Web App no.
Tim Cook - Speaking to US Congress
Web browsers are used not only as a distribution portal, but also as platforms themselves, hosting “progressive web applications” (PWAs) that eliminate the need to download a developer’s app through the App Store (or other means) at all.
Apple Lawyers - Court Filing in Australia
For everything else there is always the open Internet. If the App Store model and guidelines are not best for your app or business idea that’s okay, we provide Safari for a great web experience too.
Apple App Store Guidelines
Apple had four choices here:
The Good
Allow third-party browsers to install Web Apps, powered by the browser that the user chooses to install the Web App with. This is the only near-term viable solution. This enables browsers to compete in the provision of functionality for web apps.
The Broken
Allow browsers to install web apps but power them all by the default browser. While at first glance this may seem like a reasonable solution, it is an unworkable model. Each Web App’s data is stored within its installing browser. Each browser stores the data in different locations and raw formats. Due to complexity, no import/export functionality exists to allow a user to “port” a Web App from one browser to another along with its data. This means users would be logged out of and lose all their data for every Web App every time they switched default browser.
Having every Web App break each time a user switches default browser would be a disaster for the ecosystem. If anyone were to suggest this was a reasonable model, simply ask, would they be happy if all native apps lost their data every time you switched the default App Store.
The Devious
Provide the share menu with third party browsers, burying the ability to install Web Apps powered by Safari’s engine in a high-friction UI. This obviously doesn’t allow third party browsers to compete in the provision of Web App features but may have been sneaky enough for Apple to attempt to slip past.
The Outrageous
Outright remove support for Web Apps by converting them all to bookmarks. This removes the ability to act like an App from the an operating system and user interface perspective. This fundamentally undermines the already tenuous competitiveness of Web Apps due to Apple policies. Recall that Safari deletes data for any site that the you fail to visit for more than 7 days , but not for installed Web Apps. The outrageous strategy now subjects Web Apps in the EU to the same disadvantage. Apple policy also restricts the availability of Push Notifications to installed Web Apps. This change looks set to wreck the most requested Web App feature of the last decade. Lastly, this change hobbles homescreen-installed Web Apps that request to run in full-screen mode, such as games. Demoting Web Apps to shortcuts is a triple disability that Apple cannot be ignorant of. Finally Apple can then attempt to refuse to share the ability to install apps with third party browsers, because now Safari can’t, despite the fact it has been able to for 15 years.
We considered that Apple might try something like this, but dismissed it as too blatantly anti-competitive, even for them. Now, even as it looks increasingly less likely that Cupertino is acting in good faith, Apple could declare this unfinished or a bug. That would go some way towards alleviating concerns, but if the Beta breakage of Web Apps ever makes it onto users’ devices, it will show that Apple is actively seeking to block the Web from ever competing fairly with their App Store.
Some defend Apple's decision to remove Web Apps as a necessary response to the DMA, but this is misguided.
Apple has had 15 years to facilitate true browser competition worldwide, and nearly two years since the DMA’s final text. It could have used that time to share functionality it historically self-preferenced to Safari with other browsers. Inaction and silence speaks volumes.
The complete absence of Web Apps in Apple's DMA compliance proposal, combined with the omission of this major change from Safari beta release notes, indicates to us a strategy of deliberate obfuscation. Even if Apple were just starting to internalize its responsibilities under the DMA, this behaviour is unacceptable. A concrete proposal with clear timelines, outlining how third party browsers could install and power Web Apps using their own engines, could prevent formal proceedings, but this looks increasingly unlikely. Nothing in the DMA compels Apple to break developers' Web Apps, and doing so through ineptitude is no excuse.
Apple still has the opportunity to fix this ‘misunderstanding’. An Apple that is confident in its own products could take the following steps:
Announce that this is indeed a bug.
Publish a blog post explaining how they intend to let third party browsers (with their own engines) compete in the provision of functionality for Web Apps.
Create an API whereby browsers with the entitlement, subject to narrow scope, proportional and heavily justified security rules could install Web Apps powered by the browser that the user chooses to install them with.
Roll out these changes globally.
If Apple truly believed that the Web and Web Apps were no threat to their App Store, why not appease the regulators by letting them compete fairly on their mobile ecosystem.
Apple’s defenders might have been able to argue that a history of inadequate Web App functionality and crippling bugs were simply benign neglect. Web Apps make no money for Apple, so why expend effort on them? But the suppression of competing engines, attempts to geofence their emergence, and radio silence about complete breaking of Web Apps paints a less benevolent picture of Apple not as a bumbling giant, but as a clear enemy of the Web.
Apple looks to be taking active and provocative steps to scuttle Web Apps and to prevent other browsers from providing them. This suggests that Apple is still fearful of a future where users and developers can simply bypass Apple’s App Store using the power of the Web. OWA welcomes that future and will continue to work to ensure it becomes reality, in Europe and beyond -- just as Steve Jobs promised.
If you ship a Web App in the EU and will be impacted by this, please sign our open letter to Tim Cook. It is critical that we gather as much evidence as possible to prevent Apple from breaking Web Apps in the EU.
]]>
Did Apple just break Web Apps in iOS 17.4 Beta (EU)?2024-02-03T00:00:00Zhttps://open-web-advocacy.org/blog/did-apple-just-break-web-apps-in-ios17.4-beta-eu/We have been alerted that Apple has broken Web App (PWA) support in the EU via iOS 17.4 Beta. Sites installed to the homescreen failed to launch in their own top-level activities, opening in Safari instead. This demotes Web Apps from first-class citizens in the OS to mere shortcuts. Developers confirmed the bug did not occur outside the EU.
This bug should have been picked up within seconds of testing any Web App. So how did this issue slip through? One possibility is Web Apps aren’t routinely tested by the Safari or iOS teams and that automated regression testing is not in place. This might explain the parade of show stopping iOS Web App bugs that shipped to stable over the past 15 years.
The author of this article can not even personally test this due to not being physically located in the EU. This is the madness that Apple's malicious and spiteful Digital Markets Act compliance proposal will inflict on web developers and businesses globally.
This is almost certainly a bug, but it gives rise to suspicion among the developer community thanks to Apple’s long history of neglect and denial of features for iOS Safari. The choice to underinvest might only be problematic, save for Apple's effective ban of third party browsers. Because third-party browsers cannot provide their own Web App features, if it doesn't work in iOS Safari, it doesn't work on iOS.
The UK’s Competition and Markets Authority noted Apple’s potential App Store revenue protection motive:
Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
UK CMA - Interim Report into Mobile Ecosystems
(emphasis added)
Despite this, Apple has always claimed that Web Apps are the alternative to their app store:
For everything else there is always the open Internet. If the App Store model and guidelines are not best for your app or business idea that’s okay, we provide Safari for a great web experience too.
Apple App Store Guidelines
Recently, an argument between David Heinemeier Hansson (“DHH”) and Apple erupted over what DHH took to be a threat to eject the HEY email/calendar from their App Store if they didn’t share revenue:
Apple just called to let us know they're rejecting the HEY Calendar app from the App Store (in current form). Same bullying tactics as last time: Push delicate rejections to a call with a first-name-only person who'll softly inform you it's your wallet or your kneecaps.
David Heinemeier Hansson - Creator of Ruby on Rails and CEO of Hey
We're going to make Rails 8 the damn best framework for creating full-stack PWAs. Web Push, badges, install prompts, service workers, the works. I was motivated before, but now it's really on. Let's get back to making apps where we don't have to beg for permission or mercy!
David Heinemeier Hansson - Creator of Ruby on Rails and CEO of Hey
Netflix also made waves when it declined to port their app to Apple's new AR/VR headset, the Apple Vision Pro:
Our members will be able to enjoy Netflix on the web browser on the Vision Pro, similar to how our members can enjoy Netflix on Macs
Netflix
All of this leads to intense suspicion in the developer community.
The simple fact is it doesn't matter if this is incompetence or malice, the end result is the same. Unusably poor support for Web Apps on iOS. Apple does not face effective browser competition, leading to show stopping iOS web bugs with shocking regularity.
Imagine now that genuine and effective browser competition was allowed on iOS.
Under these conditions, showstopping Safari bugs would allow developers to recommend more capable browsers. This, in turn, would force Apple to invest in Safari, reducing the incidence of terrible web experiences for iOS users. This would lead to a vibrant, capable web that would unlock investment by developers and businesses, allowing them to deliver services via the web to iOS users.
Browser competition is critical for security, functionality, stability and privacy. It is this competition that Apple has denied iOS since its inception and that must be restored globally, not just in the EU.
]]>
Web Developers React to Apple’s DMA Compliance Proposal2024-01-31T00:00:00Zhttps://open-web-advocacy.org/blog/developers-react-apple-eu-dma-compliance/
Since Apple released their plans for compliance with the EU’s DMA regulations on 25th January, we’ve been asking web developers how these changes may affect how they work, their businesses and the web as a whole.
Jake Archibald, senior developer for Shopify, reflected "It seemed unbelievable to me that users on iOS were restricted to one browser engine, and one that in the past has been slow to fix serious bugs, and lagged behind on features. Apple has been forced to lift this restriction, but how they react to this will show us their attitude to the web"
Begin co-founder Brian LeRoux said “Lots of us are trying to make sense of the recent EU regulatory rulings and Apples' bad faith letter to the law implementation. To me, it's an excellent demonstration of why browser choice is crucially important as standards participation and legal compliance are clearly not incentive enough.”, continuing his thoughts in a public thread.
Many spoke to us about concerns that Apple is ring-fencing access to new browsers, especially with regards to testing.
Jason Grigsby, Co-founder of Cloud Four, asked “What happens if someone in the EU runs into a bug that isn’t happening in other browsers? How do we troubleshoot it? I’m trying to think of a comparable time when we had no way to test in a browser. The closest I can come to is the earliest days of mobile when the Android browser was different on each carrier. But even then, I could go to a carrier store to test and/or buy a phone if I needed more time with it. What do I do now?”
He continued with some thoughts on how he may solve this, “For us, maybe BrowserStack or a similar service will give us a way to see what our European users are seeing? Absent that, I think we're stuck.”
Peter-Paul Koch, a long time web standards and browser compatibility expert, echoed these worries, asking, “Will there be a way around this problem? For instance a VPN, or non-EU web devs becoming 'members' of an EU entity that gives them an EU Apple account and thus access to the new browsers?” and although an EU citizen himself, he showed concern for developers in other locales and wondered if this opened opportunities for legal challenges in other countries, “This puts non-EU web devs at a clear competitive disadvantage. Would that be an argument that regulatory authorities are willing to listen to? US web devs are put at a disadvantage by Apple, so Apple has to solve the situation - by also giving them access to the other browsers?”
Scott Jenson, UX strategist, opened on a positive note but quickly turned to scepticism, “Excellent start however but rather shocking that the needs of the EU are totally different from the rest of the world.” and continued with a now familiar concern, “As a developer this is very frustrating as how are we even to test our web pages now between regions?”
Moving on from topics of testing, developers reflected on a future with more browser choice for consumers on iOS.
Beginning “I think that only time will tell..” Léonie Watson, Director at TetraLogical and W3C board member, was hesitant “iOS only has one screen reader. VoiceOver works well with Safari and reasonably well with Firefox and Chrome, but whether that will continue when those browsers use their own engines is unknown at this stage.” Watson also has fears for diversity, “I also think there is a chance that Chrome could become the dominant browser across the board, and if it should, that we'll have a near unshakable monoculture.”
Andy Davies, consultant for SpeedCurve, noted that the changes in the EU do open up some opportunities to really get to know Safari better in relation to its competitors, “Probably the most interesting thing for me is we’ll finally be able to do like for like comparisons of web performance in the wild and we’ll be able to compare the speed of sites in Chrome on Android vs Chrome on iOS and so begin to get a real world understanding of the gap between the performance of Android and iOS devices”
Others see more hope in an increase in the competitive landscape. David Darnes, a lead at NordHealth, told us “I guess as a web developer I should see this as a win for the browser landscape. With these changes other browser engines will be able to run on iOS, which in turn creates healthier competition.”
Zach Leatherman, creator of 11ty and CloudCannon developer, had a similar opinion, “I’m nervous to applaud the changes outright as it seems to introduce additional variability but I am quite happy to celebrate a future of more choices for developers and consumers.”
Both had concerns, however, "That being said from what I’ve seen the amount of red tape to cut and hoops to jump through, one of which being just living in the EU, makes me worried that that silver lining will be lost in it all.”, said Darnes. Leatherman noted, “There has always been some unnerving variability in how iOS has handled in-app web browsers, so much so that I have recommended folks never use an in-app browser spawned from a native app lest they compromise the well established privacy norms usually afforded to them by the web browser.“
Dave Rupert, of ShopTalk fame and co-founder of Luro, gave us a position of hopeful curiosity, “It will be interesting to see what happens from here. Will we break out of the Chromium/Webkit duopoly? Or will we fall headlong into a Chromium monopoly? Regardless, the EU ruling is a win for the Open Web because now more users have choice beyond the OS-provided default browser.”
He expanded these thoughts on his blog.
Ultimately Zach Leatherman sums up the concerns for most, “It would be quite disappointing if—when the rubber meets the road—browser variability were dependent on the country in which you reside! I thought web browsers were supposed to be for the world wide web?”
How will these changes affect how you work? Let us know at our social media locations:
]]>
OWA’s Review of Apple’s DMA Compliance Proposal for the Web2024-01-29T00:00:00Zhttps://open-web-advocacy.org/blog/owa-review-apple-dma-compliance-for-web/# Will Apple ever let browsers and Web Apps compete fairly?
We believe that third party browsers should be allowed to compete fairly on iOS using the same engines they safely deliver to every other platform. Further, that Web Apps enabled by the functionality, stability and security delivered via intense competition between browsers should allow developers to bypass and contest the gatekeepers App Store via the world's only truly interoperable platform, the Web.
With this in mind OWA has been looking over Apple’s proposals for compliance with the EU’s Digital Markets Act to determine whether Apple intends to genuinely comply with its legal obligations regarding browsers and web apps. As OWA has argued at length, true choice in browsers is the most important counterbalance to gatekeeper monopoly power, so the answer to this question matters enormously.
Unfortunately so far it appears that the answer is "no".
Let’s dig into our three bigger point of interests:
Will browser vendors be effectively able to bring their own engine to iOS?
Will browser vendors be able to implement proper web app support on iOS?
Will browser vendors be able to compete fairly with Safari?
# Will browser vendors be effectively able to bring their own engine to iOS?
As OWA anticipated, Apple is proposing a new Web Browser Engine Entitlement that allows browser apps some of the extended privileges any modern, safe browser requires. Apple also proposes requirements browser vendors must meet to be eligible. Some deal with functional aspects of web content rendering, ensuring that browser engines are minimally standards compliant. Others deal with security aspects of web browsing, and yet others impose specific constraints related (in Apple’s view) to privacy.
The security requirements are the least objectionable, and major browsers are already compliant with the NIST guidelines for critical software supply chains. and thus, presumably, with Apple’s looser restatements of those processes. OWA's stance is that it is reasonable (and allowed by the act) for Apple to set a minimum bar on the proviso that the rules are reasonable, proportional, and do not preclude smaller browser vendors that take security seriously from competing on iOS with their own engine.
The DMA only grants Apple the right to “strictly necessary and proportionate, measures to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system”, with the burden of proof as to their necessity and proportionality resting on Apple. We concur with the intent of the act, but believe aspects such as performance and functionality should be left to competition.
Apple requires that browsers secure a “90% from Web Platform Tests”, but this is nonsensical, requiring immediate clarification. The Web Platform Tests project is a comprehensive corpus of tests for browser engines, but there is no generally accepted set out of which 90% can be measured, as each engine project enables or disables test groups based on features that are minimally implemented. An engine that implements very few features could easily maintain a 90% pass rate of the features it provides, while falling well short of the goal of broad standards conformance. The test corpus also changes between the desktop and mobile versions of browsers. Without clarification about which group of tests the 90% will be calculated from, developers live under a cloud of doubt. It’s also problematic that Apple’s language potentially demands pass-rate statistics that cannot be produced, as no set of WPT tests are run on iOS for any browser, using any engine (although Android browsers are tested) — including Safari.
The privacy requirements in Apple's policy give rise to deep concerns. Instead of enabling market competition to improve privacy, Apple is demanding specific technical mechanisms that its own products do not abide (e.g., “boostrap” cookies for Web App installation to the homescreen). It also creates vague, unenforceable terms about “informed user activation” that read like a blank check for Apple’s reviewers to reject browsers based on vibes, rather than analysis. Even with a very brief investigation, we found Apple does not yet follow these guidelines. Apple’s own track record regarding many of the issues it is performatively demanding conformance with is poor, and OWA believes that much of this language needs to be trimmed and made more objective. The primary concern here is that Apple may use this rule as a tool to deny third party browsers the ability to implement important Web App functionality with the aim of keeping that functionality exclusive to Native Apps sold via their App Store.
Requirements demanding alternative browsers implement specific APIs related to input are even more worrying. Apple requires specific iOS APIs to be used for features such as text input, scrolling, dragging, and contextual menus. This may seem appropriate to provide iOS users with a uniform experience, but consistency can be achieved in many ways. Indeed, most browser engines work extremely hard to integrate well into their host OSes and provide the best possible experience. Hard requirements in this area seem hard to justify given macOS Safari’s long history of private API abuse for competitive advantage.
One of the aims of the act is to allow third parties such as browser vendors to provide users with more choice and higher quality software than that of the gatekeeper. Third party browsers already have their own code for performing much of this functionality (such as scrolling) built into their own browsers. Web developers havelong complained that iOS Safari is riddled with scrolling bugs for all but the simplest of use cases. Mandating that third party browsers must replace this code with Apple’s libraries when they have their own, arguably superior, libraries blunts competition and may impose significant additional work with no legal justification or user benefit.
Mandating that browser vendors adopt these APIs may, perversely, hurt quality and delay release of competing browsers for months without materially improving consistency. This is particularly egregious in light of the last-minute(pdf) announcement of these APIs, Apple’s attempt at limiting their use to the EU, and Cupertino’s years-long campaign of delay. The wrongs the DMA seeks to right are multiplied by time, and terms that prevent competitors from entering the market in a timely way run counter to the spirit of the law.
Indeed, some of these APIs have deep implications for competing engine codebases. It is therefore likely to increase the complexity of competing engines and make further development and its maintenance harder for browser teams. When Apple shipped Safari on non-Apple platforms, it was not subject to similar restrictions and would be highly unlikely to accept them for iOS Safari itself. Adoption of such APIs should be optional, leaving vendors free to incorporate them as they see fit, and at their own pace.
# Will browser vendors be able to implement proper web app support on iOS?
While some APIs have been made available (and mandatory) for browser engines to implement specific features, others are notable by their absence.
Since the first iPhone in 2007, Safari has had access to private APIs for installing and managing Web Apps, and yet this core, long-standing API is missing from Apple’s compliance proposal. Just like Safari, alternate browsers must be able to add Web Apps to the home screen, to the app library, and have them appear in the system settings so users can see and modify each individual Web App settings. They must also be able to run in the same engine as the browser that installs them — just as Safari-installed Web Apps have for 15 years. Our reading of the documentation made available thus far suggests alternate browsers will not have access to such capabilities.
The DMA explicitly mentions browser competition (including the ability to use your own engine) as being important to prevent gatekeepers from determining the functionality available to Web Apps.
In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications.
Digital Markets Act
(emphasis added)
The UK Competition and Markets Authority noted that Apple had incentive to prevent Web Apps from fairly competing:
Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
UK CMA - Interim Report into Mobile Ecosystems
(emphasis added)
Finally, Apple states in the opening paragraph of their App Store Guidelines that the Web (i.e Web Apps) is the alternative to their App Store.
For everything else there is always the open Internet. If the App Store model and guidelines are not best for your app or business idea that’s okay, we provide Safari for a great web experience too.
Apple App Store Guidelines
Alternate browsers should also be able to handle Push Notifications for Web Apps, as well as badging when they are installed. There is no mention of APIs allowing the implementation of such features in Apple’s documentation.
The DMA states that gatekeepers cannot prevent third-parties from accessing OS or device features, and if these issues are simply oversights, we hope the Commission and Apple will resolve them rapidly. Time is of the essence.
# Will browser vendors be able to compete fairly with Safari?
As mandated by the DMA, Apple plans to introduce a choice screen for default browsers the first time a user opens Safari. We have little information about the design of the choice screen at this point, except that it will present the 12 most popular browsers in the user’s EU country in random order. There are a number of ways Apple can manipulate that choice screen to make it ineffective, so we will watch carefully how it ends up being implemented.
The extent of Apple’s anti-competitive behavior towards third party browsers is hard to overstate. For a dozen years, it wasn’t even possible to set a different browser as default. This thumb on the scales has spotted Safari an extensive market lead. The impact of choice screens against this sort of aggressive, persistent, long-standing self-preferencing is debatable, but OWA welcomes the attempt and urges the commission to scrupulously oversee the process. It should also not rule out re-running a choice ballot for users who have already been subject to one if the previous version is ruled out of compliance.
# Apple system provided In-App Browser ignores the users choice of default browser
Apple also self-preferences towards Safari through the OS-provided “in-app browser” mechanism. OWA expected to see mention of APIs for default competing browsers to handle navigation from apps through this facility, but it is missing. The cumulative effect of Apple’s ongoing self-preferencing in this regard is to make the web forgetful. Even when users make a competitor their default, that browser is not used to handle a sizable portion of browsing. This is a competitive restraint and is incompatible with the spirit of the DMA, and Apple’s proposal ignores the users choice of default browser.
Apple proposes only to allow competitors to ship their own engines inside the EU. This is an attempt to add poison pills, driving up costs for competitors to maintain multiple iOS browsers (one for Europe, another for the rest of the world), and to impose costs that Apple does not bear and would never stand for if imposed by a competitor. OWA expected some amount of awful-but-lawful malicious compliance, but continued restrictions on engine choice outside the EU are egregious.
Another implication of Apple’s gating of this change to the EU is the difficulty for web developers to test their Web Apps and websites across that boundary. EU web developers won’t be able to test their work with the WebKit-based versions of alternate browsers. These iOS browsers are already hard to test “frankenbrowsers” owing to Apple’s WebKit restrictions, and this adds further cost and complication.
Users outside of the EU will be using different versions of “Firefox”, “Chrome”, “Opera”, and given the difficulty in bringing modern experiences up to par on Apple’s browsers, adding to this work increases the pain for businesses attempting to build competitive web experiences in lieu of native apps.
Likewise, developers outside of the EU won’t be able to test their sites on browsers only available in the EU. This will result in major issues and bugs both for EU users and users of EU Web Apps and websites outside of it, further harming EU businesses and users. These issues, however, will only affect users of alternate browsers. Safari will have a significant advantage, its engine being the same everywhere in the world.
Obviously, the Commission does not have jurisdiction outside the EU and cannot mandate that its terms adhere worldwide, but Apple’s proposal to limit true browser choice to the EU shows that far from being embarrassed at having effectively banned third party browsers from iOS for over a decade, Apple will persist in this behavior till legally compelled not to in each and every major jurisdiction on the planet..
# Apple will preclude third party browsers from competing on iPad
Apple has chosen to restrict these browser changes to iPhone, and not to share them with iPad for users. This is currently allowed due to an ongoing dispute with the EU as to whether or not iPadOS is covered by the DMA. In our submission, we argued that iPadOS is a subset of iOS with minor changes and that even were it not it is of sufficient market size and power in the EU to be a designated core platform service in its own right.
There is no legitimate reason as to why browsers should be allowed to compete on iPhone but not iPad. This is simply a case of Apple trying to do the bare minimum possible which comes with the added bonus of scuttling browser or web app competition on iPad.
# Will browser vendors be able to update their existing browsers?
Be a separate binary from any app that uses the system-provided web browser engine
Apple Documentation
Apple is disconcertingly vague on how updating existing browser apps to now use their own engine will work and it is not clear whether:
Browser vendors must ship a separate app using their own browser engine.
Browser vendors can seamlessly swap over their existing users to the updated browser now using its own browser engine.
If it is the first, that is deeply problematic as it essentially resets every third party browser that wants to use its own engine back to zero users. Given that the choice screen will take place prior to browser vendors having the opportunity to ship their real browsers, it is critical that this is not the case.
Browser vendors need to be able to roll out their engines in a stable, predictable manner. This means complete control over swapping webkit with their own engine including the ability to do browser engine phased releases and to be able to rollback.
# Apple’s new contract for browsers that wish to use their own engine
No one on our team is a lawyer, but to our un-lawyerly eyes a number of clauses in Apple’s contract seem not only unfair, but also in direct violation of the DMA.
To our knowledge a specific contract to be “allowed” to bring a browser engine is unique to Apple in the history of successful consumer operating systems.
While in no way limiting Apple’s other rights under this Addendum or the Developer Agreement, or any other remedies at law or equity, if Apple has reason to believe You or Your Alternative Web Browser Engine App (EU) have failed to comply with the requirements of this Addendum or the Developer Agreement, Apple reserves the right to revoke to Your access to any or all of the Alternative Web Browser Engine APIs immediately upon notice to You; require You to remove Your Entitlement Profile from Your Alternative Web Browser Engine Application (EU); terminate this Addendum; block updates of, hide, or remove Your Alternative Web Browser Engine App (EU) and/or other Applications from the App Store; block Your Applications from distribution on Apple platforms; and/or to suspend or remove You from the Apple Developer Program.
Apple’s New Browser Engine Contract
This clause basically says that if you fail to abide by all of Apple’s terms (some of which are pretty vague and possibly in contravention of the DMA), that they can not only reject that update, block your app until it is fixed, ban your app but that they can actually permanently remove and ban every single app your company has from distributions on all Apple platforms (presumably including macOS).
Another clause states that browsers must also abide by the Apple App Store Guidelines ("guidelines" being a delightfully Orwellian phrase for ironclad rules). Apple does not have the best reputation as to being a fair judge of what counts as a violation of its app store rules.
It should not surprise you to know that Apple’s interpretation of its text often seems capricious at best and at worst seems like it’s motivated by self-dealing.
Dieter Bohn - The Verge
Nothing herein shall imply that Apple will accept Your Alternative Web Browser Engine App (EU) for distribution on the App Store, and You acknowledge and agree that Apple may, in its sole discretion, reject, or cease distributing Your Alternative Web Browser Engine App (EU) for any reason. For clarity, once Your Alternative Web Browser Engine App (EU) has been selected for distribution via the App Store it will be considered a “Licensed Application” under the Developer Agreement.
Apple’s New Browser Engine Contract
This clause basically says they can reject your browser for any reason.
Luckily the DMA does not allow this. The rules need to be fair, reasonable, and non-discriminatory. Further browser vendors will be able to appeal app store rulings to an alternative dispute settlement mechanism.
The gatekeeper shall apply fair, reasonable, and non-discriminatory general conditions of access for business users to its software application stores, online search engines and online social networking services listed in the designation decision pursuant to Article 3(9).
For that purpose, the gatekeeper shall publish general conditions of access, including an alternative dispute settlement mechanism.
The Commission shall assess whether the published general conditions of access comply with this paragraph.
Digital Markets Act
Apple may at any time, and from time to time, with or without prior notice to You, modify, remove, or reissue the Apple Materials or the Alternative Web Browser Engine APIs, or any part thereof. You understand that any such modifications may require You to change or update Your Alternative Web Browser Engine App (EU) at Your own cost and that features and functionality of such App may cease to function. Except as required by applicable law, Apple has no express or implied obligation to provide, or continue to provide, the Apple Materials or Alternative Web Browser Engine APIs, and may suspend or discontinue all or any portion of Your access to them at any time.
Apple’s New Browser Engine Contract
This clause says that Apple can break, remove or change any API without any notice. This hardly seems fair or reasonable.
Confidentiality
You agree that any non-public information regarding the Alternative Web Browser Engine APIs or Alternative Web Browser Engine (EU) Entitlement Profile shall be considered and treated as “Apple Confidential Information” in accordance with the terms of Section 9 (Confidentiality) of the Developer Agreement. You agree to use such Apple Confidential Information solely for the purpose of exercising Your rights and performing Your obligations under this Addendum and agree not to use such Apple Confidential Information for any other purpose, for Your own or any third party’s benefit, without Apple's prior written consent. You further agree not to disclose or disseminate Apple Confidential Information to anyone other than those of Your employees or contractors who have a need to know and who are bound by a written agreement that prohibited unauthorized use or disclose of the Apple Confidential Information.
Apple’s New Browser Engine Contract
This bans discussing Apple’s APIs publically or sharing information about them with any party except for employees or contractors who are bound by a similar agreement. Aside from the obvious attempt to stifle public discussion of shortcomings or anti-competitive behavior in Apple’s APIs this also appears to run afoul of the DMA. Given that the code bases of all the major browser engines are open source (including Safari’s) there does not appear to be any legitimate need for such a confidentiality clause.
Any practice that would in any way inhibit or hinder those users in raising their concerns or in seeking available redress, for instance by means of confidentiality clauses in agreements or other written terms, should therefore be prohibited.
Digital Markets Act
# Third-party browsers will be effectively precluded from shipping their browsers on third party app stores on iOS
Apple's proposal includes plans for allowing third-party native app stores to compete with their own on iOS. This is directly compelled by the act.
While allowing third party native app stores is not part of the fight of our organization, it is relevant in so far as browsers, being free products, would like to list on every major app store available on iOS. Apple's proposal seems designed to prevent any free app from ever even considering listing on a third party native app store on iOS.
In order to list their app on a third party app store, the app developer must sign an alternative contract allowing them the rights granted under the DMA but which comes with significantly different pricing. To our non-lawyer minds, having an optional alternate contract that semi-abides by the law and a standard contract which does not is baffling.
The pricing difference between the contracts is worth scrutiny, particularly for free apps like browsers. If vendors choose the second contract, Apple will waive some app store fees but add a new "Core Technology Fee" which boils down to a 50c charge per user, per year.
In Apple's own words the fee is:
The Core Technology Fee (CTF) is an element of the new business terms in the European Union (EU) that reflects the value Apple provides developers through ongoing investments in the tools, technologies, and services that enable them to build and share innovative apps with users around the world. Developers can choose to remain on the App Store’s current business terms or adopt the new business terms for iOS apps in the EU.
Apple Documentation
This sounds awfully like a fee for access to hardware and software APIs. But the DMA specifically precludes such a fee:
Article 6(7) The gatekeeper shall allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system or virtual assistant listed in the designation decision pursuant to Article 3(9) as are available to services or hardware provided by the gatekeeper. Furthermore, the gatekeeper shall allow business users and alternative providers of services provided together with, or in support of, core platform services, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features, regardless of whether those features are part of the operating system, as are available to, or used by, that gatekeeper when providing such services.Digital Markets Act
(emphasis added)
“Free of charge” being the key phrase.
Astonishingly, Apple has added wording that prevents developers from switching back to the standard contract, while granting themselves the right to change either contract at any time:
Developers who adopt the new business terms at any time will not be able to switch back to Apple’s existing business terms for their EU apps. Apple will continue to give developers advance notice of changes to our terms, so they can make informed choices about their businesses moving forward.
Apple Documentation
How much it would cost for a browser to list on one of these third party app stores? iOS has 1.65 billion users. 1% browser market share represents 16.5 million users. If a browser vendor dares to list their app on a third party store, even once, and even if no one downloads it from that third party store, Apple will bill them $8.25 million per a year per 1% share every year with no recourse to change back to the previous contract.
In our view (and the view of many others) is that this is designed to make it as difficult as possible for free apps to list on third party app stores as possible, depriving these app stores of these apps, and sapping their ability to get off the ground.
The DMA also contains additional provisions that likely prohibit this behavior:
Article 6(12) The gatekeeper shall apply fair, reasonable, and non-discriminatory general conditions of access for business users to its software application stores, online search engines and online social networking services listed in the designation decision pursuant to Article 3(9).
Apple’s policy is unfair, unreasonable, and discriminatory — both to free apps such as browsers, and to third party app stores.
If Apple's proposal sounds ludicrous to you, you are not alone. We are confused as to how Apple's lawyers thought this would possibly be compliant with the DMA, and the degree to which this would alienate native app developers. Their willingness to pursue these proposals, despite presumably being aware how unpopular they would be, is itself a striking example of market power.
We hope that the EU rejects this proposal and forces Apple to come up with a single non-alternative contract for all Native App developers who choose to distribute via Apple's App Store in the EU with fair, reasonable and non-discriminatory terms.
# What Apple should have done and why they will ultimately lose
Apple could have behaved differently here. They could have announced global rules allowing browser competition on iOS. These rules could include a minimum bar for security. They could have been working with the teams of each of the major browser vendors for months on what APIs they need and how to share them effectively. They could have upgraded their in-app browser (SFSafariViewController) and their Web App installation functionality to support the users choice of browser and to allow these third party browsers and Web Apps to compete fairly. They could significantly increase Safari's budget and fought to convince consumers of their vision for the Web in anticipation of intense mobile browser competition.
Apple has done none of this. Even a generous observer would conclude their proposal seems designed to circumvent the intent and letter of the digital markets act. Their announcement is dripping with disdain for the EU regulators.
These proposals seem less about complying with the DMA and more about maintaining Apple’s walled garden,
This is a mistake, for all Apple's talk of protecting consumers, the focus on revenue and containing the new competition allowed, shows their hand. The public are not fools and they are not fooled.
Even in traditionally pro-Apple forums the response to Apple's browser competition proposal has been extremely negative. Apple is losing whatever reputation for fair play it may have enjoyed. With each market investigation or act passed, this behavior is forced into the open.
Apple’s compliance proposal is only that: a proposal that the EC can accept or reject, in whole or in part. Apple’s submissions will be reviewed by the EU and are subject to change. The voice of web developers matters now more than ever, as OWA is in contact with regulators and can amplify the concerns of folks working to build competitive experiences on the only open, interoperable, tax-free platform.
The EU thus far has had only this to say:
The DMA will open the gates of the internet to competition so that digital markets are fair and open. Change is already happening. As from March 7 we will assess companies' proposals, with the feedback of third parties. If the proposed solutions are not good enough, we will not hesitate to take strong action.
EU Industry Chief Thierry Breton
Our early reading of Apple’s proposal suggests that its plan does not align with either the letter or spirit of the DMA. We will be providing more updates as we parse the text. Although we have reasons to rejoice because alternate browser engines will now be able to ship to iOS, we remain concerned that this sort of gamesmanship by gatekeepers undermines the intent of the DMA. Fair competition for web browsers and proper support for Web Apps on iOS is not too much to ask. Indeed, we believe it’s now the legal right of EU citizens.
While legal experts expect the EU to challenge Apple's insincere compliance with the DMA, developers should take this opportunity to rethink their native app serfdom. They should push web apps to their limits and then demand further platform improvement.
The web doesn't require commission payments, technology fees based on usage, or permission from platform rentseekers. The web can set the iPhone free, even if Apple won't.
Thomas Claburn - The Register
We will keep on fighting and will alert the EU to shortcomings and risks posed by each of the gatekeeper’s compliance plans.
Stay tuned as we will be posting about its progress as more information becomes available.
We believe it's important that readers be able to make up their own minds.
This is the full text of the DMA. Of most interest is Article 5 and Article 6 which are only a few pages, however the recitals which start on the first page provide context for these articles, such as the reference to web apps.
The following is a list of links to Apple’s documentation on their new browser engine rules and APIs.
]]>
Apple's plan to allow browser competition dubbed unworkable2024-01-27T00:00:00Zhttps://open-web-advocacy.org/blog/apple-dma-changes/
The #AppleBrowserBan Ends in the EU!
After 3 years of campaigning by @OpenWebAdvocacy and in a victory for developers and consumers, Apple has been forced to allow third-party browsers in the EU.
The Digital Markets Act compels them to finally allow browser vendors to port their real browsers to iOS by March 7th, 2024, offering users in the EU (for the first time) a legitimate choice.
This news is tempered by the fact that Apple's proposed solution to comply with the DMA rules to allow browser competition has not been well received.
Apple’s proposals fail to give consumers viable choices by making it as painful as possible for others to provide competitive alternatives to Safari
— Damiano DeMonte - Mozilla spokesperson
Others in the industry we have spoken to described Apple's compliance plan as it relates to browsers as "unworkable", "a massive problem for us" and "doing everything they can to make the DMA fail".
Apple claims repeatedly, if you don’t like their app store, don’t use it. You can use the web and web apps to reach your customers.
They say this, while at the same time preventing this from happening by not providing the tools needed in their own browser and blocking other browsers from providing them.
It is clear that Apple far from being embarrassed at, for over a decade, having effectively banned all third party browsers will only change this policy where legally compelled to do so.
Further, Apple’s language is rife with fear mongering:
“Apple argues (without any particular merit or evidence) that these other engines are a security and performance risk and that only WebKit is truly optimized and safe for iPhone users.” — David Pierce - The Verge
Apple's decision to geo-lock this change underscores their on-going resistance to a truly open web. We will be actively analysing their compliance solution as well as identifying and challenging any loopholes that hinder fair competition.
We need your help to scrutinise every aspect of the compliance proposal for anything that is designed to undermine the DMA’s intent. You can read about Apple’s proposal for compliance here:
This victory wouldn't have been possible without your unwavering support. While we celebrate this important step, let's remember the fight for global browser competition continues. Stay tuned, and let's work together to ensure browser choice for all users, everywhere!
That the EU’s application of the DMA is a disproportionate intervention in response to iOS market distortions.
The AppStore should be considered five separate entities, one for each OS (iPadOS, iOS, watchOS, tvOS and macOS). We’ve previously discussed how Apple’s distinction between iPadOS and iOS is tenuous.
That iMessage should not be designated, because iMessage is neither hardware nor subscription dependant.
At OWA, we don’t have a ton of opinions on the third claim, but we do on the first two, as they’re material to the interests of web developers and relevant browser competition.
If Apple is able to convince the EU not to regulate their AppStore, Apple will be allowed to continue effectively banning third party browsers from being available to their users via the default mechanism those users get apps. As discussed extensively Apple has banned third party browsers on iOS from using their own engine or modifying an existing engine, instead forcing third party browser vendors to build a browser on top of the system supplied WebKit WebView over whose functionality Apple has exclusive control. A possible outcome of avoiding EU regulation of their App Store is that users may only be allowed to later have additional browsers via side-loading, but OWA is sceptical about this as a path to a fairer landscape.
]]>
Open Web Advocacy 2023 in Review2023-12-31T00:00:00Zhttps://open-web-advocacy.org/blog/owa-2023-review/
We’re living through a moment of real potential for change. For over a decade the Web has been prevented from fairly competing. That’s changing, and we’re working without fear or favor to direct change toward a safe, open future for computing and a better Web for all.
Competition is the engine of progress and OWA is working hard to spread the word on anti-competitive practices holding the Web back, how to fix them and the Web’s incredible potential to improve consumers' lives further. By meeting with regulators, giving talks, writing countless technical papers and advocating online, we’re going to take the fight for a better Web to every corner of the globe.
We hope you’ll join us in 2024 as we continue to convert potential into reality. Speak up and demand a web that works for everyone.
It’s been an incredibly busy year, so here’s just the highlights of 2023 by region:
The European Union is a key focus of ours, not only due to its economic size, but also due to its new digital competition regulation the Digital Markets Act.
This act was passed into law on November 1st 2022. To our delight it included explicit wording prohibiting companies such as Apple from banning rival companies porting their real browsers with their own browser engines.
Specifically the following section:
In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users. — Digital Markets Act
In addition it contains a host of clauses that will enable the Web and third parties via the Web to compete fairly on all operating systems. Specifically it has clauses that:
Browsers must be allowed to port their own engines
Third parties services such as browsers must be given access to operating system APIs and hardware subject to narrow scope and strictly necessary security requirements
Operating system and browser gatekeepers will not be able to self preference their own services in a number of ways
In March we had the opportunity to present at the EU’s Digital Markets Act Workshop to express our viewpoints on this new act and how it should be implemented. We also had the opportunity to meet the DMA team in person and talk through our concerns. Since then we have extensively engaged with their team seeking to aid them in effectively applying the DMA to fix anti-competitive issues related to browsers and Web Apps.
On September 6th 2023 the European Commission designated six gatekeepers - Alphabet, Amazon, Apple, ByteDance, Meta, Microsoft under the Digital Markets Act (DMA). Under these 6 gatekeepers 22 core platform services provided by gatekeepers were designated. It is these that must comply with the rules of the DMA. These companies have 6 months to be in compliance with the act from this date.
Apple made this attempt despite the Digital Markets Act containing specific clauses to address this exact behavior:
Article 13(1): An undertaking providing core platform services shall not segment, divide, subdivide, fragment or split those services through contractual, commercial, technical or any other means in order to circumvent the quantitative thresholds laid down in Article 3(2). No such practice of an undertaking shall prevent the Commission from designating it as a gatekeeper pursuant to Article 3(4).
Lucky for us the team at the EC dismissed this ludicrous gambit and painstakingly ripped Apple's argument to shreds. It is baffling to us why Apple's legal team is willing to sacrifice their credibility on something that has such a low chance of success.
Unfortunately they had better luck with iPadOS and were able to convince the EU that it was distinct from iOS. However, the EU has determined that iPadOS has sufficient market share and power to warrant an investigation as to whether iPadOS should be considered a gatekeeper on a standalone basis. OWA had the opportunity to respond as to why we believe that iPadOS must be designated a Gatekeeper and should not be considered separate from iOS in general.
In our own submission we argued that iPadOS is a subset of iOS and that even if it were not it, it has sufficient market power to be designated core platform service.
2024 will be an exciting year in the EU for browser and Web App competition. We are engaging closely with the regulator on a range of topics including:
Allowing third party browsers to be ported to iOS
Allowing browsers fair and effective access to system and hardware APIs
Allowing Web Apps to compete fairly and effectively with their Native App counterparts
Stopping companies from overriding users choice of default browser
Preventing unfair self-preferencing of gatekeepers browsers
March 6th 2024 is the key date by which all gatekeepers must be in compliance, but the changes required by the act are many and there is great technical complexity that various gatekeepers can hide behind. Given that literally billions are at stake, expect fireworks and lawsuits. We will be doing our best to keep the regulator, developers and the general public informed with all the key technical details and outline a path to a future where the Web can compete fairly.
As a result of the WebKit restriction, there is no competition in browser engines on iOS and Apple effectively dictates the features that browsers on iOS can offer (to the extent that they are governed by the browser engine as opposed to by the UI).
Importantly, due to the WebKit restriction, Apple makes decisions on whether to support features not only for its own browser, but for all browsers on iOS. This not only restricts competition (as it materially limits the potential for rival browsers to differentiate themselves from Safari on factors such as speed and functionality) but also limits the capability of all browsers on iOS devices, depriving iOS users of useful innovations they might otherwise benefit from.
Based on the findings of their Market Study in which OWA heavily consulted, the CMA decided to launch a Market Investigation Reference into Browser and Cloud Gaming.
In their reference decision they listed the following potential remedies:
removing Apple’s restrictions on competing browser engines on iOS devices;
mandating access to certain functionality for browsers (including supporting web apps);
requiring Apple and Google to provide equal access to functionality through APIs for rival browsers;
requirements that make it more straightforward for users to change the default browser within their device settings;
choice screens to overcome the distortive effects of pre-installation; and
requiring Apple to remove its App Store restrictions on cloud gaming services.
The decision was both unexpected and disappointing. Apple hadn’t argued that its policies were fair, or that the Competition and Markets Authority (CMA) was wrong in its findings. Rather, Apple argued that the CMA hadn’t regulated fast enough after finding in June 2022 that Apple and Google’s App Store and browser policies harmed UK businesses and consumers.
This judgment put progress on real browser choice in the UK on hold for an indeterminate amount of time. The only remaining hope was an appeal through the courts that could take months or years, or that the long-proposed Digital Markets, Competition and Consumers Bill (DMCC) might make progress through Parliament without being gutted by lobbyists.
The DMCC would give the CMA’s successor statutory authority to regulate more quickly. Even if that came to pass, at least a year of delay would have been won by Apple, as the CMA’s Market Investigation was the (slow) “fast path”. Our hopes were not high.
After months of radio silence, good news arrived from the UK on two fronts.
Then, at the end of the month, we learned that the CMA’s appeal to overturn the April judgment had succeeded, with the caveat that Apple could still appeal the loss to the UK’s Supreme Court. The findings from the Court of Appeal were nothing short of excoriating, with the Court rebuking the Competition Appeal Tribunal for having lost sight of the law’s goals to protect businesses and consumers.
Meanwhile, the DMCC Bill has progressed in the House of Lords without incident, setting the stage for a beefed up UK digital regulator in 2024 with expanded powers to intervene in unfair browser competition.
In April 2022, the Headquarters for Digital Market Competition published a report where they recommend reversing Apple’s ban on rival browser engines and allowing third party browser vendors to port their real browsers to iOS. OWA heavily consulted with the HDMC on the topic of browser and web app competition, see this report for our detailed viewpoints.
Then in February 2023, the Japan Fair Trade Commission (JFTC) published an exhaustive report examining the mobile app and browser ecosystem. The report summary finds that Apple and Google have an effective duopoly over the mobile market, and that (contra Apple’s claims) there’s little pressure on App Stores from Web Apps, in part, due to suppression of key features via browser engine policy and prevention of discovery of Web Apps within App Stores.
Last year the Competition & Consumer Commission (ACCC) published a report outlining competition issues in digital markets. OWA is heavily quoted in the report. The report contains a number of considered remedies including:
The code of conduct for mobile OS services could require Designated Digital Platforms to allow third-party browser engines to be used on their mobile OS. This could allow third-party providers of browsers and web apps to compete on their merits.
We also consider that the additional competition measures should include the ability to provide third-party providers of apps and services with reasonable and equivalent access to hardware, software and functionality through their mobile OS.
In December, promising legislative action has finally emerged from the ACCC’s inquiry. The laws will be based on the ACCC recommendations in their 5th report. It specifically calls for meaningful browser choice, including engine competition, which OWA believes to be critical for the health of the web.
In July, the Indian Parliament recommended the introduction of an ex-ante regime through a new ‘Digital Competition Act’ (DCA), to ensure a fair and transparent digital ecosystem in India.
In September, Brazil announced Bill 2768, a new law related to improving digital competition and interoperability.
In December, the Korea Fair Trade Commission (“KFTC”) announced its proposal to enact the “Platform Competition Promotion Act” (“PCPA”) for ex-ante regulation of platforms by designating “dominant platform operators”.
Even if nothing happens beyond the already locked-in statutory and process deadlines in the EU and the UK, 2024 is shaping up to be the biggest year for digital competition regulation in a generation.
On January 22nd, the UK’s House of Lords is set to bring the amended Digital Markets, Competition & Consumers Bill to Committee stage, one of the final steps before the Bill becomes an Act. OWA understands the quick progress of the DMCC in recent months to indicate high potential for a competent regulator on the job with expanded powers and a mandate to act swiftly. While it will take months beyond Bill passage for the proposed Digital Markets Unit (DMU) to be stood up, OWA is excited to see both the expansion of capacity to regulate questions related to browser choice, as well as the strong support in the legislative process for redressing the market distortions of the status quo.
Next, the UK’s CMA will regain its power to continue a Market Investigation into Browsers and Cloud Gaming beginning January 24th. This restart of the mothballed investigation will once again begin the clock ticking down to intervention by the CMA using statutory powers it already has, with a possible outcome mandating true browser engine choice on iOS. Such a ruling would be a sea change, stands to bring the UK into alignment with emerging EU regulation, and will let the Web truly compete with native apps.
On March 6th, 2024 the 6-month countdown from the EU’s Digital Markets Act (DMA) designation decisions will conclude, requiring that Apple, Alphabet/Google, Amazon, ByteDance, Meta, and Microsoft to be in compliance of the terms of the DMA.
OWA anticipates that the plain language of the DMA will compel true browser choice and an end to Apple’s ban on competing browsers, along with a pile of other improvements to browser competition across Android and Windows. The penalties for non-compliance are severe, and so we remain hopeful that rumors of browser ports from Chromium and Gecko will become real products early next year. Where competitors aren’t able to bring their best products to designated OSes, OWA will continue to facilitate information sharing between all parties to ensure that the lines are clear and that compliance is toothsome.
If nothing else were to happen in 2024, OWA’s docket would be full. Each regulator (empowered by new legislation) that opens investigations into browsers, web apps and digital competition involves hundreds of hours of preparation for briefings to highlight issues that impact consumers, competitors and web developers, and as the EU and UK move into implementation, the workload will only increase.
In addition to OWA’s continued direct advocacy toward browser and OS vendors, we have remained in constant contact with regulators around the world, responding to dozens of requests for information and briefing this year alone. This behind-the-scenes work only occasionally becomes public, but it’s the in-the-weeds problem-description and guidance-giving that changes the agenda and has enabled so many regulators to emphasize the importance to consumers of effective browser and Web App competition.
It’s only through the generous support of donors and volunteers that we’re able to continue this work, and we hope you’ll get involved to help us continue to shape the future of digital competition. We would like to say a special thank you to particularly generous donations from startsmall and store.app.
Together we can fix these anti-competitive issues and allow the Web to fairly compete to its full potential.
Happy New Year from everyone at Open Web Advocacy!
]]>
UK browser investigation to restart Jan 24 after Apple fail to appeal2023-12-18T00:00:00Zhttps://open-web-advocacy.org/blog/cma-reopens-investigation-into-apple/
30 November 2023: In a unanimous judgment (available on the National Archives website), the Court of Appeal has determined that the CMA’s decision to make a market investigation reference in relation to the market for mobile browsers and cloud gaming was lawful, setting aside the CAT’s judgment of 31 March 2023.
Consequently, the Court has ordered that the market investigation will continue to be suspended until permission to appeal (if sought) has been determined and an additional 21 days has lapsed. – Competition and Markets Authority
That 21 days has now passed, and no permissions to appeal were received, and as such the CMA will restart their investigation in the new year.
18 December 2023: the deadline for Apple to seek the Court of Appeal’s permission to appeal the Court’s decision has now lapsed, therefore in accordance with the Court’s order dated 30 November 2023, the market investigation will recommence on 24 January 2023. Further updates will follow in due course. – Competition and Markets Authority
Our previous article covers why this investigation is so important for protecting consumers in the UK.
Once the investigation reopens, you can be sure we'll be covering everything the CMA learns, so stay tuned to our social media.
This is excellent news and will pave the way for fair and effective browser competition on all operating systems & allow Web Apps to compete on an equal footing with Native Apps.
The code of conduct for mobile OS services could require Designated Digital Platforms to allow third-party browser engines to be used on their mobile OS. This could allow third-party providers of browsers and web apps to compete on their merits.
We also consider that the additional competition measures should include the ability to provide third-party providers of apps and services with reasonable and equivalent access to hardware, software and functionality through their mobile OS.
This is important as, Apple has effectively banned third party browsers via their 2.5.6 rule:
2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
We believe that browsers should compete on merit and user choice, not via control of operating systems or other underhanded behaviour. Browser competition is important as it is this competition that pushes browser vendors to secure their products, fix bugs and add new features.
Stay tuned as we will be posting about its progress as more information becomes available.
]]>
iOS Safari zero-day security bugs and how browser choice affects user safety2023-12-05T00:00:00Zhttps://open-web-advocacy.org/blog/security-updates-browser-choice/
In the last couple of weeks we've seen a few browser security bugs pop up, giving us the opportunity to talk about how a competitive landscape for web browsers is vital to protecting users online.
Both bugs were “high” severity, meaning attackers could compromise devices using malicious web pages. This is your friendly reminder to make sure your devices are up to date!
If a security bug shows up on a browser on Android, MacOS, Windows or most other OSs, users can opt to pick a different browser for a time until a patch has landed and their browsing experience is safe again. If their browser has a bad security track record, they can also switch to a better built one. Additionally, Chrome or any other browser on Android etc., can be patched without OS updates. Users don't have to wait for a new version of Android, wait for huge downloads, or reboot their devices.
Users on iOS are less fortunate. Having no other browsers to choose from, they must hope that the security update doesn't catch them out in some way as they wait for an iOS update, as Safari isn't able to independently ship changes. With no choice, they have no option to wait it out on safer shores.
This choice of software architecture - coupling a browser to an OS, or not - has been played out before. It wasn't long ago that Windows users had to wait for OS updates to receive patches for IE because it was so tightly tied to OS components. Microsoft’s strategy handicapped their ability to keep browsers current. Eventually, they changed the design with Chromium-based Edge because decoupled updates are safer. Even without that design change, Windows users still had choices available to them in times of need.
All users deserve to have that choice.
]]>
Apple loses on Appeal, CMA can restart investigation into browsers2023-12-01T00:00:00Zhttps://open-web-advocacy.org/blog/apple-loses-on-appeal/
This is important as, Apple has effectively banned third party browsers via their 2.5.6 rule:
2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
We believe that browsers should compete on merit and user choice, not via control of operating systems or other underhanded behaviour. Browser competition is important as it is this competition that pushes browser vendors to secure their products, fix bugs and add new features. Without the constant threat of users potentially moving to another browser, browsers have limited incentive to compete. This threat is entirely absent on iOS, the other browsers on iOS have extremely limited ability to compete as Apple has banned them from editing their core, the browser engine. Instead iOS provides a uneditable Webview whose security, features set and stability is entirely under Apple's control. Under these conditions there is effectively no browser competition on iOS.
As readers may remember the CMA conducted a Market Study into Mobile Ecosystems.
As a result of the WebKit restriction, there is no competition in browser engines on iOS and Apple effectively dictates the features that browsers on iOS can offer (to the extent that they are governed by the browser engine as opposed to by the UI)."
Importantly, due to the WebKit restriction, Apple makes decisions on whether to support features not only for its own browser, but for all browsers on iOS. This not only restricts competition (as it materially limits the potential for rival browsers to differentiate themselves from Safari on factors such as speed and functionality) but also limits the capability of all browsers on iOS devices, depriving iOS users of useful innovations they might otherwise benefit from.
The report also ruled against Apple’s security arguments. Apple had claimed that Safari’s engine’s security was better than that of third party browsers. This was alluded to in the CMA’s interim report:
... in Apple's opinion, WebKit offers a better level of security protection than Blink and Gecko.
The CMA rejected this claim stating:
... the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines.
Overall, the evidence we have received to date does not suggest that Apple's WebKit restriction allows for quicker and more effective response to security threats for dedicated browser apps on iOS
Amusingly Apple dropped their claim that Safari’s security was superior to other major browsers in their response to the final report.
The report also notes that Apple has incentives to inhibit third party browser from competing due to its search deal with Google:
Apple receives significant revenue from Google by setting Google Search as the default search engine on Safari, and therefore benefits financially from high usage of Safari. Safari has a strong advantage on iOS over other browsers because it is pre-installed and set as the default browser. The WebKit restriction may help to entrench this position by limiting the scope for other browsers on iOS to differentiate themselves from Safari (for example being less able to accelerate the speed of page loading and not being able to display videos in formats not supported by WebKit). As a result, it is less likely that users will choose other browsers over Safari, which in turn secures Apple’s revenues from Google.
Apple reportedly receives $18-20 billion USD a year from their Google Search engine deal, accounting for 14-16 percent of Apple's annual operating profits. Apple has not published the annual budget for Safari/Webkit but based on anecdotal evidence it is likely significantly less than 2% of this sum.
The report goes on to note:
Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.
That is Apple appears to also have incentives to inhibit the capabilities of the Web on iOS Safari. Apple collected $85 billion USD in App Store fees in 2022, of which it keeps approximately 30%. Were Web Apps to have a comparable features set, stability and visibility as Native Apps this revenue would be threatened.
While it has not published the costs of App Store review, payment processing, refund handling etc, it has been estimated that the iOS App Store has a nearly 80% profit margin. Industries with healthy competition feature leading firms with profit margins between 5 and 20 percent. This imbalance strongly implies that Apple’s removal of functional competition in the App Store and beyond have broken the mobile phone market for software and services for more than half of the UK’s consumers.
Based on the findings of their Market Study, the CMA decided to launch a Market Investigation Reference into Browser and Cloud Gaming.
In their reference decision they listed the following potential remedies:
removing Apple’s restrictions on competing browser engines on iOS devices;
mandating access to certain functionality for browsers (including supporting web apps);
requiring Apple and Google to provide equal access to functionality through APIs for rival browsers;
requirements that make it more straightforward for users to change the default browser within their device settings;
choice screens to overcome the distortive effects of pre-installation; and
requiring Apple to remove its App Store restrictions on cloud gaming services.
Unfortunately, they delayed starting the investigation while waiting to see if the UK government was going to pass new laws granting them stronger powers to deal with anti-competitive behaviour by tech giants. These laws are currently working their way through parliament and are currently expected to be passed into law in 2024.
Due to this Apple managed to successfully get the MIR dismissed not by arguing before the tribunal that the CMA was substantially wrong about any of its anti-competitive behaviour but on the legal technicality based around the timing of the opening of the investigation.
The CMA appealed this decision and today the London's Court of Appeal has overruled the Competition Appeal Tribunal's decision and stated that the MIR can be reopened.
It is worth noting that Apple has the right to seek permission to appeal this decision and that the investigation is on hold pending this. Apple is almost certain to appeal to the supreme court. Even if they end up losing, each month browser competition on iOS is delayed is arguably worth billions to them.
Apple reportedly has a legal budget of over $1 billion dollars a year and adopts an exceptionally aggressive stance. If you want to understand Apple’s approach to legal, Bruce Sewell, Apple’s former general counsel discusses it in a talk where discussing Apple's legal strategy he says:
work out how to get closer to a particular risk but be prepared to manage it if it does go nuclear, … steer the ship as close as you can to that line because that's where the competitive advantage occurs. … Apple had to pay a large fine, Tim [Cook]'s reaction was that's the right choice, don't let that scare you, I don't want you to stop pushing the envelope.
Bruce Sewell, Apple’s former General Counsel
This gives some clear insight into Apple’s mindset, and explains a lot of their behaviour.
Despite that, this court victory is a huge step towards restoring browser competition, ending Apple's effective ban of third party browsers and ensuring Web Apps have the ability to compete.
Right now, if competition was restored, 90% of the apps on your phone could be written as a Web App and would be indistinguishable, significantly cheaper and often BETTER than Native Apps. Native Apps will still have a lead in cutting edge graphics and gaming technology but if companies see the web platform as viable this gap will decrease over time.
It is for this reason that allowing browser competition on iOS is critical. Apple’s effective browser ban prevents the emergence of such an open and free universal platform for mobile apps. Unlike desktop, developers cannot build their application once and have it work across all consumer devices. Instead, these policies combine with Apple’s trailing and feature-poor engine to force companies to create separate applications for iOS, significantly raising the cost and complexity of development and maintenance. This severely undermines any interoperability advantages Web Apps have between iOS and Android. A single prominent OS holding back the Web is enough to undermine its entire value proposition as a frictionless, capable and secure distribution mechanism for Web Apps.
The fight to allow browser and Web App competition on iOS is not over. We would like to thank everyone for their support over the last 3 years and ask that consumers, developers and businesses write in and engage with the market investigation reference to arm them with all the data and information they need to successfully restore competition to a broken mobile ecosystem.
Stay tuned as we will be posting about its progress as more information becomes available.
]]>
OWA submits response to EU DMA investigation into Apple iPadOS2023-11-21T00:00:00Zhttps://open-web-advocacy.org/blog/owa-eu-dma-submission-apple-ipados/
As the EU further rolls out the Digital Marketing Act, they have designated a variety of companies and their platforms as “Gatekeepers”. You can see the complete list of Gatekeepers and some really useful explainers on what being a Gatekeeper means on the EU’s very informative website.
Now that Gatekeepers have been designated, the companies that operate those services have had the opportunity to rebut their designations.
A particularly interesting response was from Apple, who have made the case that iPadOS is an entirely separate operating system from iOS, both of which are currently designated as platforms subject to the DMA, along with the Apple App Store. Their arguments boil down to:
iPadOS has some unique features
iPadOS has an optional secondary input (the Apple Pencil)
The most popular apps on iPad are different from the most popular apps on iPhone
We disagree with this claim. iPadOS is a subset of the iOS ecosystem. Indeed it was called iOS up until 2019 and very little has happened since then to significantly distinguish it. Unfortunately the EU has for now accepted the argument that iPadOS is a separate OS from iOS.
Further, according to statistics supplied by Apple, iPadOS has less than the 45 million users required to be automatically designated a Gatekeeper. The EU has determined that iPadOS has sufficient market share and power to warrant an investigation as to whether iPadOS should be considered a gatekeeper on a standalone basis. OWA had the opportunity to respond as to why we believe that iPadOS must be designated a Gatekeeper and should not be considered separate from iOS in general.
In broad strokes, OWA argued that:
Apple’s argument about the size of the EU iPad market is in dispute. IDC, for example, shows the iPad market in Europe (the UK inclusive) to be about 43 million devices. This suggests the bar for arguing that iPadOS should be declared a gatekeeper by bridging the gap between actual and required quantitative threshold should not be high. Further Apple's calculations as to active users need to be scrutinised.
The distinction between iOS and iPadOS is minor, the primary difference being a number of features to take advantage of the larger screen. For most of the history of the iPad, iOS was it’s operating system, and the launch schedules and differences in feature sets have not substantially diverged since the 2019 marketing change.
The cross-device impacts of Apple’s wealthier customer base influence technology choices and investments far in excess of the install base. Discounting the network effects of the iOS/iPadOS App Store-based logic of software development and distribution is to focus on the trees, rather than the forest.
The DMA contains clauses explictly designed to reject the attempts at artificial subdivision that Apple has put forward here. Further iPadOS is a critical part of the iOS ecosystem and it is essential to recognise the anticompetitive architecture of Apple’s influence over app stores, and the interlocking ways they do so across the Apple ecosystem. Allowing Apple to evade its DMA obligations for so significant segment of its ecosystem, will allow Apple great power to not only increaselock-in, reduce interoperability and hobble competition on iPad but also to curtail the effectiveness of the DMA with regards to Apple’s obligations on iPhone.
Apple gates proprietary API access on iOS in exactly the same ways, and through the same terms and conditions, with the same anti-competitive restraints on browser and applications choice, on iOS as it does on the lately-rebranded iPadOS. This is a sizable entrypoint to wealthy consumers across the EU, which amplifies the effects of the restrictions.
]]>
Why is browser choice vital for the future of the Open Web?2023-11-13T00:00:00Zhttps://open-web-advocacy.org/blog/why-browser-choice-matters/
OWA’s key goal is to enable true competition and browser choice across all devices. But, why do we care so deeply about this, and what would success look like?
Currently, businesses that want to grow across many markets must develop not only a good website, but also native apps for any platforms they want to reach that don’t have modern browser features available. Additionally, deriving most of their user base from native applications and app stores mean that they’re forced into giving a cut to those app stores (usually 30% of any payments made through the app store). It’s not uncommon for businesses to pass that fee on to users as an extra cost.
In a fairer world, businesses would be able to rely on modern web browsers being available to all of their users, regardless of the platform they choose, enabling businesses to opt out of app stores and serve their customers from a single application, avoiding the app-store tax.
Although the web in general has a variety of issues in regards to privacy (hello ad-trackers!), browsers offer a sandboxed experience that is superior to native app security - Apple even knows this, and spoke about it in their recent filing to the EU.
With that said, browsers that are stuck inside native applications are at the mercy of that application - information can be freely read and tracked - so with browser choice available to an end user, they can regain control of their privacy and deprive those that would like to farm their data from their behaviours within their applications.
The most obvious reason that a lack of competition is an issue for everyone is it stifles innovation. With no fair way to deploy new browsers to all users, no new ones will be born. The market is already showing this by the practical loss of Opera and the downward trend of Firefox - neither can succeed in today’s market.
Currently, Google and Apple run a duopoly that essentially ensures that they are the only two active participants in deciding what happens to the open web (and mobile computing, in general), because they disallow anyone else to compete against them, preferentially favouring their own, closed, ecosystems of native apps.
If you want a choice in which company you trust with your web experience, the businesses that create those options need to know they have a fair chance to succeed.
If you want to read more about why closed ecosystems are a problem, take a look at our Walled Gardens Report.
]]>
News from the NTIA report on mobile app ecosystems2023-02-03T00:00:00Zhttps://open-web-advocacy.org/blog/NTIA-report-Feb-22/Bruce published an article where he gives us a summary of the NTIA (National Telecommunications and Information Administration) report on Mobile App Competition.
The question now is whether Apple will do the right thing, or seek to hurl lawyers with procedural arguments at it instead, as they're doing in the UK now.
But for every month they delay, they earn a fortune; it's estimated that Google pays Apple $20 Billion to be the default search engine in Safari, and the App Store earned Apple $72.3 Billion in 2020.
Apple's App Store revenue is ~ $72.3 billion, of which they tax app developers between 15% and (likely more often) 30%. If we assume Apple always takes the full 30%, they would receive just shy of $21.7 billion. Apple would still need some of that money to pay for the operating costs of the App Store.
The $20 billion from Google is likely almost all profit.
That's 11% of Apple's yearly profit for doing nothing except banning their competitors from iOS 🤯
Browser ban = higher market share for safari = Google search engine revenue
If you love what we're doing and would like to support our work, please consider
making a donation.
OWA is a registered not-for-profit fighting for the Web against heavily financed gatekeepers
to ensure the future of Browser competition and Web Apps
]]>
Australian Government considering ACCC proposed anti-competitive conduct legislation changes2022-11-30T00:00:00Zhttps://open-web-advocacy.org/blog/Australia-ACCC-Nov-22/
G'day, sport! Bruce here, with an update on progress we've made down under with the Australian Competition and Consumer Commission (ACCC).
Requiring equivalent access to hardware and software
Allowing web apps to compete with single-platform "native" apps
Apple requires all browsers on iOS to be built using its WebKit browser engine. Further, Apple prevents WebKit from accessing certain APIs and iOS functionality, which restricts the functionality of web apps compared to native apps (for example, push notifications can be accessed by native apps but not web apps).
As a result, Apple iOS users do not have the option to use browsers that can offer a wider range of innovative features and functionality. Instead, they are limited to using browsers built using Apple’s WebKit browser engine. Stakeholders submit that, as a result, Safari faces very limited competitive pressure on iOS. We are also concerned that this limits the ability for web apps … to impose a competitive constraint on native apps.”
Apple, and to a lesser extent Google, have also restricted interoperability with hardware, software and functionality through their mobile OS for providers of third-party apps and services.
The ACCC is recommending introducing a new regulatory regime that will be able to compel gatekeepers to stop anti-competitive conduct. They note that reforms are underway globally and it would make sense to align Australia's new regulatory regime with ones such as the EU's Digital Markets Act, the UK's Digital Markets Unit and the Japan's Act on Improving Transparency and Fairness of Digital Platforms.
They clearly recognize the harm that the gatekeepers have on competition, businesses and consumers. The ACCC has a lovely shopping list of proposed legislated obligations, most of which will relate to browsers and web apps. The majority of OWA’s concerns (PDF) fit into these categories:
anti-competitive self-preferencing
anti-competitive tying
exclusive pre-installation and default agreements that hinder competition
impediments to consumer switching
impediments to interoperability
data-related barriers to entry and expansion, where privacy impacts can be managed
a lack of transparency
unfair dealings with business users
exclusivity and price parity clauses in contracts with business users.
The Australian Government is considering the ACCC’s recommendations and will consult publicly to seek the views of stakeholders.
]]>
OWA updates on progress with UK and EU digital competition regulations2022-11-28T00:00:00Zhttps://open-web-advocacy.org/blog/CMA-DMA-Nov-22/
Howdy, Bruce here, with an update on progress we've made in both the EU and with the UK's competition regulator, the Competition and Markets Authority (CMA).
We've had encouraging success at putting browser engines on the regulators' agenda. While rendering engines seem a pretty esoteric subject, it's of paramount importance: Apple has done a great job concealing its anti-competitive behaviour, saying "you can have other browsers on iOS" while glossing over the fact that all other browsers are Apple's mandated version of WebKit under the hood.
Many web developers don't realise this, which is why we made this meme:
So we're thrilled that, after we met with those drafting the EU rules, the final text of the Digital Markets Act (DMA), browser engines are explicitly referenced:
In particular, each browser is built on a web browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. When gatekeepers operate and impose web browser engines, they are in a position to determine the functionality and standards that will apply not only to their own web browsers, but also to competing web browsers and, in turn, to web software applications. Gatekeepers should therefore not use their position to require their dependent business users to use any of the services provided together with, or in support of, core platform services by the gatekeeper itself as part of the provision of services or products by those business users.
The DMA will be applicable as of beginning of May 2023. Non-compliance carries fines of up to 10% of the company’s total worldwide annual turnover, or up to 20% in the event of repeated infringements.
The UK is no longer a member of the EU, so some of us who are citizens of Brexit Island met with the UK's Competition and Markets Authority after it announced an investigation into the Mobile Apps Ecosystem. We explained that it shouldn't be seen as a binary choice between single-platform "native" apps on iOS and Android, but should also be concerned with Progressive Web Apps and, by extension, also look at how Apple hamstrings PWAs by only allowing its WebKit on iOS and iPad.
Web developers have complained that Apple’s restrictions, combined with suggested underinvestment in its browser technology, lead to added costs and frustration as they have to deal with bugs and glitches when building web pages, and have no choice but to create bespoke mobile apps when a website might be sufficient.
Ultimately, these restrictions limit choice and may make it more difficult to bring innovative new apps to the hands of UK consumers. At the same time, Apple and Google have argued that restrictions are needed to protect users. The CMA’s market investigation will consider these concerns and consider whether new rules are needed to drive better outcomes.
We want to say a huge thank you to all web developers who took the time and trouble to reply to CMA's consultations. Big Tech firms have whole departments who leap into action if regulators start sniffing, and the money to set up pseudo-associations to lobby on their behalf. We didn't; you had our backs. Thank you.
We agree overwhelmingly with the findings of fact and, with comments, agree that the
proposed interventions contained within the CMA’s December 14th, 2021 “Mobile ecosystems
market study interim report”
are both warranted and timely.
iOS Safari faces no effective competition as Apple has not provided access to private APIs that
competing browsers need and has banned competing engines. The CMA have highlighted the
second aspect (labelling it "the Webkit Restriction") accurately and extensively in their report
and write:
“As a result of the WebKit restriction, there is no competition in browser engines on iOS
and Apple effectively dictates the features that browsers on iOS can offer (to the extent
that they are governed by the browser engine as opposed to by the UI).”
“Importantly, due to the WebKit restriction, Apple makes decisions on whether to support
features not only for its own browser, but for all browsers on iOS. This not only restricts
competition (as it materially limits the potential for rival browsers to differentiate
themselves from Safari on factors such as speed and functionality) but also limits the
capability of all browsers on iOS devices, depriving iOS users of useful innovations they
might otherwise benefit from.”
They also note that Apple has two perverse incentives to hold back Webkit and to hinder Web
Apps ability to compete with the iOS App Store:
“First, Apple receives significant revenue from Google by setting Google Search as the
default search engine on Safari, and therefore benefits financially from high usage of
Safari. Safari has a strong advantage on iOS over other browsers because it is
pre-installed and set as the default browser. The WebKit restriction may help to entrench
this position by limiting the scope for other browsers on iOS to differentiate themselves
from Safari (for example being less able to accelerate the speed of page loading and not
being able to display videos in formats not supported by WebKit). As a result, it is less
likely that users will choose other browsers over Safari, which in turn secures Apple’s
revenues from Google.”
“Second, and as discussed in Competition in the distribution of native apps, Apple
generates revenue through its App Store, both by charging developers for access to the
App Store and by taking a commission for payments made via Apple IAP. Apple therefore
benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use
the WebKit browser engine, Apple is able to exert control over the maximum functionality
of all browsers on iOS and, as a consequence, hold up the development and use of web
apps. This limits the competitive constraint that web apps pose on native apps, which in
turn protects and benefits Apple’s App Store revenues.”
Apple’s incentives and behaviour bear additional scrutiny.
Apple receives $15 billion USD a year from their Google Search engine deal, representing 9% of
Apple’s 2019 gross profit. Apple has not published the annual budget for Safari/Webkit but
based on anecdotal evidence it is likely significantly less than 2% of this sum.
Apple collected $72.3 billion USD in App Store fees
in 2020. While it has not published the
costs of App Store review, payment processing, refund handling etc, it has been estimated that
the iOS App Store has a nearly 80% profit margin.
Industries with healthy competition feature
leading firms with profit margins between 5 and 20 percent.
This imbalance strongly implies
that Apple’s removal of functional competition in the App Store and beyond have broken the
mobile phone market for software and services for more than half of the UK’s consumers.
If Safari/Webkit had competition on iOS, Apple would have great incentive to retain users on
their browser by making a better, more functional browser. A competitive web ecosystem may
also put pressure on rent extracting behaviour without sacrificing user safety as browser
makers compete aggressively on security, privacy, and user-empowering features such as
extensions. If Web Apps are competitive with Native Apps, without sacrificing safety,
system-default app stores may become less important to both users and software makers.
Require that iOS and the version of Webkit provided by iOS support specific features
required by Web Apps
Require that iOS allows third party browser engines
We believe and argue below that while Remedy 2 (Requiring Webkit Features) may provide
some value in the short term, in the long term it will ultimately be unworkable as a replacement
for Remedy 1 (Equivalent API) and Remedy 3 (Third Party Engines), and only both Remedy 1
(Equivalent API) and Remedy 3 (Third Party Engines) will restore competition between
browsers on iOS and between Web Apps and Native Apps on iOS.
We also propose a 4th Remedy “Require Broad Web App Support” which has specific technical
aspects not covered by Remedy 1 (Equivalent API) and Remedy 2 (Requiring Webkit Features).
In addition we believe that Remedy 1 (Equivalent API) needs to be significantly strengthened to
prevent gaming by Apple.
“Businesses that face effective competition dare not raise prices, or cut down on quality
standards, for fear of losing customers to their competitors (and so losing money)”
“For the foreseeable future, iOS will be the dominant access pathway, passport,
monetizer and platform for not just digital life, but virtual ones. Apple holds this role
because it makes best-in-class hardware, offers the best apps, and operates the most
lucrative app store.”
iOS Safari faces no effective competition as Apple has banned competing engines. These
engines, in turn, differentiate other browsers. Without substantive competition in browsers,
consumers have little recourse short of buying another phone. Businesses and developers,
meanwhile, are forced to consider the Web as an uncompetitive environment in which to launch
services, as Apple’s neglect has ensured that for more than half of UK users, browsers cannot
be a reasonable replacement for Apple’s proprietary App Store and APIs.
The development, maintenance and lost opportunity costs of supporting a buggy browser that
misses key features are mostly hidden from end users. It is hard for consumers to see a missing
feature or an entire Web App that didn’t get built (due to poor support in iOS Safari). When they
do encounter a bug caused by Safari they are more likely to blame the Web App than the
browser. The user may get the impression that the Web is buggy, slow and that Native Apps
are better, which then has negative flow on effects for the entire web ecosystem.
Businesses have little recourse as they can not suggest their customers install another real
browser (there are none) and they are unwilling to lose more than half their mobile customers
(51% in the UK, 66% in Japan, 56% in Australia, 46% in the US). Additionally iOS users tend to
be wealthier and spend more
making them a higher priority for companies. In the end the
majority of large businesses simply throw in the towel and make an iOS Native App and in doing
so agree to pay Apple 15-30% of their revenue.
As such, Apple faces little effective competitive pressure to improve the quality of their iOS
Safari browser and has incentives to inhibit it from competing with native. Thus Apple’s decade
long prohibition on competition for Safari on iOS has a compounding anti-competitive effect as
companies sink money into non-interoperable native iOS applications instead of Web Apps.
Even Apple executives appear to be aware only their stranglehold on iOS installation is allowing
their 30% tax on revenue, something they can not achieve on Mac OS.
“Neither is on the store because they don't have to be. They can be on Mac and
distribute to users without sharing the revenue with us.”
# 4.1. Require equivalent API access for rival browsers
We believe that Third Party Apps access to operating system APIs and features should be, at a
minimum, equivalent to the access provided to Apps and functions provided by the Gatekeeper
or its business partners. Currently on iOS and Android there exist features that are exclusive to
the browsers owned by the gatekeeper of the operating system.
Apple's hobbling of third party browsers doesn't stop at mandating a specific version of
Webkit, Apple provides Safari significant unfair advantages.
The major issues include:
Full Screen
iOS Safari allows video elements to become full screen, but frustratingly, not other
element types. This hobbles many gaming scenarios on the Web. The HTML5 canvas
element is essential for games (where Apple derives the lion’s share of App Store
revenue) which cannot be made full screen.
Competing browsers, based on other engines, have long pro**vided reasonable behaviour
in this regard, including on Android.
No Web Apps
Only Safari is allowed to install Web Apps to the iOS home screen via private APIs that
are not available to competing browsers, even if they are set as the user’s default.
Should competing engines become available for iOS browsers, it’s essential that
expansion of Web App installation also allow those competing engines to “back” the
Apps they install so that developers do not experience Web Apps as being held back by
Apple’s trailing-edge engine technology.
Extensions
Only Safari can use extensions which are used by many users, including to block ads
and improve privacy.
Apple Pay
Apple forces competing browsers to provide only Apple Pay as a payment mechanism
for use within the Web Payments API. This is blatantly anti-competitive.
In-App Browsers
Regardless of the user’s default browser setting, iOS developers that invoke the
SFSafariViewController tool for creating Remote Tab-based In-App Browsers are always
forced to invoke Safari, rather than a user’s default browser (
Please see our other submission regarding In-App Browsers and how they negatively affect
browser competition).
While Android browsers other than Chrome can install PWAs, Google has not yet provided
access to the latest mechanism.
This can lead to bugs, and far poorer operating system
integration and user experience. This remedy would compel Google to fix this and we support
the CMA’s proposal in this regard.
Consider a fictional scenario where Apple removed the ability to install Web Apps via Safari.
Under the proposed language identifying this remedy, Apple would no longer need to provide
this functionality to other rival browsers. This is an extreme example as it would immediately
draw the ire of regulators, but it highlights how Apple can (more subtly) hinder the
development of all browsers on iOS by removing or not adding certain iOS integrations via
Safari and then use regulatory conformance as a shield, contra the spirit of the law. Protecting
App Store profits from Web Apps requires nothing more than keeping the Web at bay. A safe,
user-respecting platform that mobile Operating System platform vendors cannot collect rents
from is a transparent threat to their oligopoly interests.
The CMA should prepare for subtle, underhanded behaviour from Apple.
With this in mind, we believe this remedy needs to be strengthened to overcome this sort of
gaming. One alternative might be to require Gatekeepers provide browser vendors access to
all functionality available to any App or function provided by the Gatekeeper or their business
partners (subject to very narrow, and heavily justified privacy/security concerns with
consideration given to the level of unmitigatable risk vs the loss of useful functionality for end
users).
An example of this is iOS Safari does not technically require access to Bluetooth, as they do not
intend to provide Web Bluetooth (but many other Apps on iOS do). Under the existing remedy
Apple would not be required to grant rival browsers access to the iOS Bluetooth APIs if Apple
chose to not provide it to iOS Safari. Thus Apple could limit the functionality of rival browsers
by not providing access to particular iOS system features to iOS Safari.
Finally there exist Web App specific features that no App currently has on iOS, that would not
be effectively covered by this remedy. As such we have proposed a 4th remedy to cover these
narrow cases.
This is a useful remedy and will improve browser competition. That said, we do not believe it is
sufficient individually to enable effective competition, as without the other remedies such as
allowing third party engines the same perverse incentives to either underinvest or withhold key
features from Webkit (the version provided with iOS) persist.
# 4.2. Require Safari/Webkit to support key Web App Features
Web Standards evolve quickly, spurred on by competing browser makers working with
developers. This involves collaboration in standards bodies to improve compatibility, however if
each Browser vendor had to wait until there was complete agreement between every vendor
for each of the various standards (and each standards body operates differently), it would be
possible for a single vendor (e.g. Apple) to game these processes to halt progress, especially in
areas where they have an interest in preserving the proprietary nature of their own solutions.
Typically, cutting edge features are deployed by browser makers' own engines first. Real world
feedback from developers (typically over several years) informs eventual standardisation. No
feature starts out as a web standard.
“Web Standards are voluntary. The force that most powerfully compels their adoption is
competition, rather than regulation. This is an inherent property of modern browsers.
Vendors participate in standards processes not because they need anyone else to tell
them what to do, and not because they are somehow subject to the dictates of
standards bodies, but rather to learn from developers and find agreement with
competitors in a problem space where compatibility returns outsized gains.”
No one can predict what web technologies will be important in the future, and disagreements
between browser makers on the exact path forward are reasonable and expected. It is very
difficult, if not impossible for regulators to predict which standards will be the most important
and what their exact definition will end up being. It's a subtle and complex topic.
The perverse incentives for Apple
are not removed by this remedy and consumers have no
recourse should Apple choose not to include a feature in Webkit (the version provided with
iOS). If the case for adding the feature is not overwhelming then the regulator may not feel
enabled to force them to add it.
The primary issue is competition. When there is a severe bug,
there are no panicked meetings
at Apple within the iOS Safari team about how to quickly fix the issue, because Web App
developers are urging their users to switch to Edge, Firefox and Chrome on iOS. Developers
know that all browsers on iOS are essentially identical, so the competitive pressure that forces
Apple to stem users on iOS fleeing to other browsers is removed. There is no real fear of
losing browser market share because there is almost zero risk of users changing phone brand
over broken/missing browser features.
The next issue with this measure is that it requires Apple to attempt to comply in good faith.
Recently, Dutch regulators mandated that Apple must allow dating app providers in the
Netherlands to use alternative payment methods.
Apple's response shows utter contempt
for the regulator and at every step appears designed
to undermine the regulator's ruling with the aim of making it all but impossible (and pointless)
for developers to use alternative payment methods. Apple's documentation
is really quite
incredible in the degree and brazen way they seek to avoid complying with the regulator. It is
clear that regulators must operate under the assumption that Apple will act in bad faith and
plan their regulatory regimes accordingly.
Mandating Web App features is complex and subtle. Apple will have plenty of ambiguity to hide
behind in undermining, slow rolling and crippling key Web App features. Additionally, it's very
hard to regulate that software must be stable and not have bugs. All Browser Engines have
bugs, it is competition that is the force that compels fixing them.
Thus while there may be significant benefit from compelling Apple to add the clearest and most
needed Web App features in the short term, we believe that this remedy will be unworkable in
the long term given these adversarial dynamics.
Rather than mandating Gatekeepers support particular standards, a better approach is to
regulate such that effective competition is possible without direct intervention of regulators
regarding every single proposed API. Policies that create a space for browser vendors to
compete and deliver features enhances competition both between rival browsers and
between Web Apps and Native Apps. Such a regime is possible – it is the status quo in every
other popular operating system, including Apple’s macOS – and most effectively harnesses the
spirit of competition to respond to both user and developer needs.
# 4.3. Require iOS to Allow Third Party Browser Engines
We strongly support the CMA’s findings of fact and proposed remedies in this area. This is the
most vital proposed remedy to enable unlocking truly competitive browsers.
Apple enjoys iron control over what features make it into Webkit, the specific version of Webkit
provided by iOS, and the feature set of iOS Safari. Without allowing third party browsers
engines it is not possible (or excessively difficult) for third parties to provide these features to
consumers.
Currently if Apple wishes to block a feature from appearing on iOS Safari they do not need to
fear that their users will switch to another browser, as the other browsers on iOS will also be
missing this feature (as they are required to use a specific version of Webkit).
If both remedy 1 and 3 were applied, that is browser vendors can supply browsers with their
own engines on iOS and be provided all the same system APIs that Safari and iOS are provided,
then competition would be restored.
Were Apple to choose not to add a particular feature to their browser, then other companies
would have the option of adding that feature (or their version of that feature) to their browser.
Users could be alerted by websites and Web Apps that a particular required feature was
missing in iOS Safari and that they could switch to one of the other browsers.
This is important in four ways:
Browsers would be free to experiment on what the correct new Web Standard should
be
Users would have recourse to switch to another browser (if iOS Safari was missing key
features)
If these features were truly useful/popular, Apple would now have an incentive to
implement them on its own browser (even if these features enabled Web Apps to
compete more effectively with the App Store) or risk losing browser share on iOS
Additionally, Apple would now have a powerful incentive to properly fund their browser
Thus, the perverse incentives highlighted earlier completely evaporate and the regulator is not
put in the difficult position of having to write and enforce Web Standard Specifications.
We are grateful to the CMA’s attention to the state of Web Apps on iOS vs. competing OSes.
We believe gatekeepers must provide sufficient functionality, integration and APIs to enable
browser vendors (where possible) to provide Web Apps feature parity with Native Apps. For the
most part the changes required to allow this are not significant relative to the competitive
benefits this will unlock (outlined in detail within “Bringing Competition to Walled Gardens”).
We propose this be a fourth remedy that the CMA considers in combination with the other
remedies.
To ensure long-term parity between Apple’s proprietary APIs and competition potentially
provided by Web Apps and competing browsers, it’s important that controlling regulations
create an expectation that Web Apps will not be restricted from integrating deeply into OSes,
even if that means exposing currently private APIs to Browsers.
For example:
In general, Web Apps should act like Native Apps from the users perspective once installed
iOS Permissions for Web Apps should not be harder to manage than those of Native Apps
Integration into OS-level management surfaces should be required
Web Apps should not face hurdles to accessing sufficient system resources to enable
important applications (e.g., storage space and durability)
Integration with system-provided services (application backup/sync, AI assistant
services, etc.) should be possible for both third-party browsers and Web Apps
Additionally we believe that there are significant competitive benefits from compelling Apple to
allow Web Apps to be directly listed on the iOS App Store.
Currently iOS Apps on the iOS App Store must be written in programming languages specific to
Apple. This acts as a form of lock-in by requiring that developers write their Apps multiple
times. Proper Web App support would allow developers to bypass the iOS App Store, but some
(particularly larger developers) may see value in the listing there.
This will increase competition and benefit users:
These Apps will be interoperable across operating systems (with a single code base)
Developers could advertise to users via the App Store or avoid the App Store entirely,
gather their own users via the Web or both at the same time.
Browser environments and its APIs are significantly more locked down and sandboxed
than Native equivalents. Users could benefit from this improved security.
It’s important to note here that we are not lawyers and anything in this section is merely to
provide ideas to solve potential technical problems with enforcement.
All of the measures could be balanced by a security and privacy provision, perhaps similar to
the one found in the proposed Open App Markets Act:
**In General** —Subject to section (b), a Covered Company shall not be in violation of a
subsection of section 3 for an action that is—
necessary to achieve user privacy, security, or digital safety;
taken to prevent spam or fraud; or
taken to prevent a violation of, or comply with, Federal or State law.
**Requirements** —Section (a) shall only apply if the Covered Company establishes by
clear and convincing evidence that the action described is—
applied on a demonstrably consistent basis to Apps of the Covered Company or its
business partners and to other Apps;
not used as a pretext to exclude, or impose unnecessary or discriminatory terms
on, third-party Apps, In-App Payment Systems, or App Stores; and
narrowly tailored and could not be achieved through a less discriminatory and
technically possible means.
One important feature of this is, that it allows gatekeepers to take necessary steps to protect
the security/privacy of their users while requiring them to prove with convincing evidence that
the measures are consistent, narrow and non-malicious in intent.
It may be useful to add Web Apps to the list in 2 b).
Additionally we believe it is important that the Gatekeeper must prove with clear and
convincing evidence that the benefits to users of any privacy or security measure outweigh
the costs to users of the measure. This is to preclude very fringe but non-zero security
issues being used to block users from useful functionality.
Finally we would like to see provisions that ban any secret measures and allow companies to
compel the gatekeeper to provide detailed technical answers to reasonable questions related
to these measures.
The issues that affect competition in the UK within mobile ecosystems are the same issues
globally. If a UK company wishes to sell their product internationally, which most do, then
these remedies have to be global remedies.
We believe it is essential that the CMA work together with other regulatory and legislative
bodies so that these remedies become global and not only applied to the UK. As part of the
market study and the work of the Digital Markets Unit, close collaboration with other regulators
should be considered a high priority.
That said, there are still some benefits from the UK leading the way in this regulation as it will
provide data and leverage to regulators in other countries, who can point to the UKs successes
and use them as a blueprint for their own regulations. Additionally even in the complete
absence of global support for such regulations UK customers will still benefit significantly.
We are heartened by the depth of research and thoughtfulness embodied in the CMA’s interim
report. We concur with the findings of fact and strongly support many of the proposed
remedies.
To recap, we believe that the following remedies are necessary:
Gatekeepers must provide browser vendors access to all functionality available to any
App or function provided by the Gatekeeper or their business partners.
iOS must allow third party browser engines
Mobile OSes must provide broad and deep Web App support
While we feel there may be some significant short term benefit by requiring Webkit and iOS
Safari support particular Web App features, we believe that in the long term this will be
unworkable. True, meaningful competition is the only long-term and durable fix.
Open Web Advocacy is a loose group of software engineers from all over the world, who work
for many different companies who have come together to fight for the future of the open web
by providing regulators, legislators and policy makers the intricate technical details that they
need to understand the major anti-competitive issues in our industry and potential ways to
solve them.
It should be noted that all the authors and reviewers of this document are software engineers
and not economists, lawyers or regulatory experts. The aim is to explain the current situation,
outline the specific problems, how this affects consumers and suggest potential regulatory
remedies.
This is a grassroots effort by software engineers as individuals and not on behalf of their
employers or any of the browser vendors.
We are available to regulators, legislators and policy makers for presentations / Q&A and we
can provide expert technical analysis on topics in this area.
For those who would like to help or join us in fighting for a free and open future for the web,
please contact us at:
]]>
OWA has a new website!2022-03-02T00:00:00Zhttps://open-web-advocacy.org/blog/website-under-development/
A team of enthusiastic volunteers has got to work on OWA's new site.
![Image showing three pull quotes, stating: To me, it's an excellent demonstration of why browser choice is crucially important [...] legal compliance are clearly not incentive enough. Brian LeRoux, Begin. Apple has been forced to lift this restriction, but how they react to this will show us their attitude to the web. Jake Archibald, Shopify. It would be quite disappointing if—when the rubber meets the road—browser variability were dependent on the country in which you reside! Zach Leatherman, 11ty, CloudCannon](/images/blog/developers-react-265KHgC1yq-800.jpeg "Image showing three pull quotes, stating: To me, it's an excellent demonstration of why browser choice is crucially important [...] legal compliance are clearly not incentive enough. Brian LeRoux, Begin. Apple has been forced to lift this restriction, but how they react to this will show us their attitude to the web. Jake Archibald, Shopify. It would be quite disappointing if—when the rubber meets the road—browser variability were dependent on the country in which you reside! Zach Leatherman, 11ty, CloudCannon")
