Archive for December, 2024

Apple’s malicious compliance – the EU strikes back!

When the Digital Markets Act came into force, there was a grace period for Gatekeepers (such as Apple) to prepare their Core Platform Services (such as iOS) to be interoperable and to stop self-preferencing the Gatekeepers’ own products. Spoiler alert: many Gatekeepers haven’t yet done so.

In the browser world, the most egregious offenders are Microsoft and Apple. Microsoft is a Gatekeeper because of its Windows operating system, so it moved a lot of its sneaky tricks into Microsoft Edge which (bizarrely) is not designated as a Core Service. The Browser Choice Alliance was recently formed to persuade regulators to look at desktop browser competition.

Apple, meanwhile, have adopted a strategy of malicious compliance so brazen that they might as well be sticking a finger up at the EU, while shouting “Fine us then, you communists!”, then turning around and pulling a moonie.

So in September, the EU started two specification proceedings to “assist” Apple in complying with its interoperability obligations, and the preliminary findings were published yesterday for public consultation. I read the PDFs so you don’t have to, in case you’re imminently off to an Xmas party where glamorous and sophisticated people will ask you questions about this and you don’t want to appear an ill-informed chump.

The first focused on “on several iOS connectivity features and functionalities, predominantly used for and by connected devices”. While this isn’t in the world of browsers, “companies offering these products depend on effective interoperability with smartphones and their operating systems, such as iOS”, as do browsers, so it’s instructive to see the EU’s thinking on iOS interoperability.

The preliminary findings in case DMA.100203 – Article 6(7) – Apple – iOS – SP – Features for connected physical devices [PDF] is mostly technical, but concludes with some interesting measures for all features.

Paragraph 131 would ban the ludicrous contractual obligations that Apple would impose on third-party browser engines in its anti-competitive Web Browser Engine Entitlement Addendum for Apps in the EU [PDF]:

(c) Apple shall not undermine effective interoperability with the 11 features set out in this Document by behaviour of a technical nature. In particular, Apple shall actively take all the necessary actions to allow effective interoperability with these features.

(d) Apple shall not impose any contractual or commercial restrictions that would be opaque, unfair, unreasonable, or discriminatory towards third parties or otherwise defeat the purpose of enabling effective interoperability. In particular, Apple shall not restrict business users, directly or indirectly, to make use of any interoperability solution in their existing apps via an automatic update. In any event, any restrictions imposed by Apple shall not be more restrictive than those applied to Apple’s own services and hardware, i.e., Apple’s own services and hardware may not be subject to more favourable requirements and criteria.

It explicitly recognises that adding friction points can influence consumer behaviour, and thus forbids it:

(f) As regards the end user journey and the ease of use for end users, Apple shall not add friction that end users of Apple services and Apple connected physical devices are not subject to. In particular, Apple shall refrain from adding friction by:
(1) offering choices to the end user in a non-neutral manner, including in permission prompts for third-party connected physical devices,
(2) setting a system default to not grant a permission with respect to third party connected physical devices,
(3) requiring end users to process multiple successive permission prompts that could be presented in a single prompt,
(4) requiring switching between apps or apps and the iOS settings to configure a connected physical device,
(5) misrepresenting any risks of using the connected physical device towards the end user,
(6) using deceptive design pattern or dark patterns that steers users to not grant a permission.

(g) Apple shall ensure that for the features listed in this Document and the respective interoperability solutions end users can grant any required user permissions in a frictionless way:
(1) From inside the application itself or with a simple system prompt; or
(2) Following a link to the relevant item in the system settings (so-called “deep-linking”). In this case, Apple shall ensure that the user does not need to continue onto additional screens to change the specific setting, that the relevant item can be clearly highlighted, and that the user can be visually guided to return to the application.

I hope that, if the EU starts specification proceedings on allowing third-party web browser engines because Apple still digs its heels in, a similar set of over-arching requirements will be specified.

The second preliminary findings published yesterday sets out proposed measures that Apple should implement to improve the request-based process for requesting interoperability with iOS [PDF] set up by Apple.

This was always a ridiculous process. The point of DMA is that Gatekeepers design and document APIs that allow interoperability, rather than grudgingly demand supplicants submit a form into a black hole. I’ve sent a couple of interoperability requests on behalf of Vivaldi (my employer), but only received an automated response with no idea of what the next step will be, when the initial assessment will take place, the criteria used for such as assessment, or how one appeals a rejection:

Hello,

Thank you for your submission. We’ll review your request soon. Your reference number is INTEROP-248.

If additional information is needed to complete the initial assessment, we’ll reach out. When responding to communications, please use the email address from which you submitted your interoperability request. The use of a different email address may result in a delay in handling your request.

For more information, please visit the FAQ.

Apple Developer Relations

Paragraph 23 of the preliminary findings addresses this lack of transparency:

To ensure sufficient transparency regarding the process, the gatekeeper should put in place a clearly structured, adequately documented process setting out how requests will be received, acknowledged, assessed and responded to.
(24) … . The webpage should include clear and detailed information on how to submit a request, what information the developer should insert in the request form, a description of the phases and their deadlines as well as a clear description of the criteria and considerations that Apple would apply or take into account in its assessment of the request at the various stages should also be included.

There should be a named contact, transparency of rejection reasons, and a conciliation process. There should be a tracker system so developers can see the progress of others’ interop requests (with the consent of the initial requester):

(69) Apple should organise the requests it received in an easily accessible tracker system giving developers relevant information on the status of each interoperability request, including for each request information on its current stage and expected timeline. The tracker must be up to date and be easily accessible to all interested developers via a dedicated section on the developer portal.

Perhaps most intriguingly, Apple should document its private APIs:

(11) To ensure sufficient transparency with respect to features and functionalities that are currently only available to or used by Apple, or not available in an effective manner to third-party developers (hereinafter “reserved feature and functionality”), the following measures should be implemented.
(12) Apple should provide developers with information on reserved features and functionalities, comprising
(i) descriptions of all features and functionalities accessed or controlled by iOS or iPadOS, so that developers adequately understand their purpose;
(ii) indications of whether the features and functionalities are reserved to Apple or also available to third parties, such that developers can easily distinguish features and functionalities that are not (yet) available to third-party developers;
(iii) any terms, conditions, restrictions, or entitlements that apply, such that developers understand why features and functionalities may or may not be available publicly as well as understand privileged access for Apple;
(iv) Apple’s services and hardware that use the feature or functionality, such that developers understand which services or hardware provided by Apple take advantage of the features and functionalities.

Of course, Apple is very sad about these suggestions. It swiftly published a lachrymose paper called It’s getting personal. How abuse of the DMA’s interoperability mandate could expose your private information [PDF] to lament that Meta had made 15 interoperability requests that “alter functionality in a way that raises concerns about the privacy and security of users”.

Apple further weeps,

These processes will hurt innovation— companies should be able to compete with one another to make their own products work together in new ways that benefit users without giving their ideas away to competitors. Apple is the only company being forced to share its innovations in this way with everyone else, including those who do not share its commitment to user privacy.

I’m no fan of Meta, but I agree with their unnamed spokesperson’s statement to Bloomberg:

What Apple is actually saying is they don’t believe in interoperability. Every time Apple is called out for its anticompetitive behavior, they defend themselves on privacy grounds that have no basis in reality.

Do you have an opinion? Tell the EU before 9 January!

Reading List 331

This reading list is brought to you courtesy of Vivaldi browser who pay me a respectable salary and don’t moan when I read stuff I’m interested in. Studies show that using Vivaldi makes you even more gorgeous, by up to 879%.

CMA Provisional Report on mobile browsers

Two years after opening its Market Investigation into mobile browsers, the UK’s Competition and Markets Authority has released its provisional report. From the summary of provisional decision (the full report is a 600 page document!):

The independent inquiry group appointed for this market investigation has provisionally
found that a number of markets relating to browsers on mobile devices are not working
well.

We have provisionally identified a number of features in the markets for mobile browsers,
browser engines and in-app browsing technology which restrict competition. Most of these
features relate to the policies implemented by Apple in the relevant markets. In particular,
we have provisionally found that various types of policies implemented by Apple are
holding back innovation from other browsers.

First, Apple currently specifies that mobile browsers in the UK must use Apple’s own
underlying browser engine (WebKit), which determines what competing mobile browsers
can do on iOS. We have provisionally found that this limits the extent to which competitors
can differentiate their browsers and offer enhanced features to iOS users.

Second, we have provisionally found that Apple has withheld access or has delayed giving
competing mobile browsers using its WebKit system the same level of access and
functionality as its own browser Safari enjoys, which has a negative impact on competition
and innovation.

Progressive Web Apps are mentioned as being hampered by Apple, which harms UK developers’s business:

In particular, Apple’s rules appear to be holding back a category of apps known as
‘progressive web apps’ (PWAs) that are lower cost and easier for developers to build since
they can run on any operating system. PWAs do not need to be listed on an app store and
are not subject to app store charges.…

Many smaller UK app developers told us that limits on web apps are holding back their
business because they could be developing PWAs as a comparable and lower cost
alternative to developing a native app.

The CMA notes that concerns about security are entirely valid, but Apple’s belief that it alone is capable of delivering a secure browser to its users in a timely manner is utter crap (I paraphrase):

We also note that alternative browser engines have strong records on security outcomes, and more widely, that Apple’s current restriction actually prevents mobile browsers competing and innovating on security and privacy features, for example by implementing security updates more frequently than Apple’s architecture currently allows.

The full report says

4.191 Several stakeholders also submitted that when a security flaw is found in WebKit, consumers are unable to protect themselves by switching to a mobile browser based on a different browser engine and are therefore vulnerable until a fix is deployed to WebKit (which can take several weeks).

In-App Browsers (which Open Web Advocacy calls “the worst erosion of user choice you haven’t heard of“) are also discussed:

Third, we have provisionally found that on iOS, Apple limits the technology available to link
to web content from within an app, known as in-app browsing, which appears to be an
increasingly significant proportion of all browsing which takes place on mobile devices. We
have provisionally found that Apple’s restrictions limit the traffic available to challenger
browsers in this type of browsing and also limit the extent to which apps can customise
their users’ browsing experience as companies with millions of users like Meta would like
to do.

The vast payments by Google to Apple for default search on Safari/iOS harm competitiveness:

Fourth, we are concerned about revenue sharing arrangements between Google and
Apple. We have provisionally found that Apple and Google earn significant revenue when
their key rival’s mobile browser is used on iOS, reducing their financial incentives to
compete.

Both Google and Apple misuse their Android and iOS platforms to steer users away from competitors’ browsers:

Fifth, we provisionally find both Apple’s and Google’s product design choices about when,
whether and how users make certain decisions about mobile browsers, also known as
choice architecture, are making it significantly harder for users to drive competition by
actively choosing which mobile browser they use.

The full report notes that Apple’s malicious compliance tactic in EU of preposterous terms and conditions for third-party browser engines is a “further area of effectiveness risk”:

11.104 We note that multiple stakeholders submitted that the terms Apple has
attached to its proposed Web Browser Engine Entitlement (WBEE), which it has
introduced in response to the DMA obligations, have precluded them from
considering using alternative browser engines on iOS in the EU.

11.105 Particular concerns could arise if Apple were to introduce:

(a) Conditions such as:

(i) requiring users of mobile browsers which use alternative browser
engines to uninstall their existing mobile browser and install a new
version of the app, creating potential friction or confusion (the ‘separate
binary’ requirement); and

(ii) Apple imposing terms on browser vendors on the location of where
testing and development of mobile browser apps using alternative
browser engines should take place (for example, that testing and
development of a UK browser app using an alternative browser engine
should be done in the UK only).

(b) Disproportionate security and privacy considerations.

Naturally, the CMA also had a hearing with Apple (PDF, 6 pages), in which we learned that API design is very hard:

Apple stated that making functionality within the iOS architecture available to browser vendors can be complex

and (surprise!)

Apple raised a concern that the proposed remedies would not protect or enhance competition in the market

Bang to rights! What happens now?

First, interested parties have until mid-December to respond to the provisional report. The final report is due in the first quarter of next year. But it looks as if the CMA wants to refer the matter back to itself, because while the investigation was ongoing, the Digital Markets, Competition and Consumers Act gave the CMA new powers to establish a Digital Markets Unit to investigate, enforce and, if necessary, fine anti-competitive organisations up to 10% of their annual global turnover. (Previously the CMA had to take offenders to court, and there was no guarantee of effective sanction.)

So, it’s back to investigating whether Apple and Google should be designated with Strategic Market Status (SMS), presumably with consultations and provisional reports:

We have provisionally concluded that an effective and comprehensive means of
addressing the competition concerns we have provisionally identified is to recommend to
the CMA Board that, using these new powers:

(a) it prioritises commencing SMS investigations to assess whether it would be
appropriate to designate Apple and/or Google for their respective digital activities in mobile
ecosystems; and it is recommended that the scope of such SMS investigations includes
the supply of mobile browsers, browser engines and in-app browsing technology; and

(b) if such designation(s) are made, it considers imposing appropriate
interventions, such as those we have considered in this report.

Such is the slow progress of law. But we’re inching forwards to freeing up the web on mobile and weakening the duopoly in the UK as well as the EU and Japan.