The Digital Markets Act is one of the least understood EU technology laws, yet it has tangible impacts—both positive and negative—on the technology landscape. We’ll use the opportunity to study an interesting and real-world case. It concerns the practice of Chrome preloading its web browser extension so that Google’s services may effortlessly and by default, without user choice or knowledge, interact with Google servers and services. The issue is that this bypassing of the core pillar of web security and privacy, the Single-origin policy, is not available to other web browser or extension vendors.

Executive (and final) assessment.

Google Chrome's practice of preloading extensions that bypass the single-origin policy and grant them privileges not available to third-party extensions could breach Article 6(7) of the Digital Markets Act (DMA). This article mandates that gatekeepers must allow free and effective interoperability with, and access to, the same software features available to services provided by the gatekeeper, regardless of whether those features are part of the operating system. By allowing its extensions access to exclusive APIs or functionalities that are not equally accessible to third-party developers, Google may be undermining fair competition. This exclusivity could be viewed as unfairly limiting the interoperability required under DMA, favoring Google's services over competitors.

The DMA regime stipulates fines up to 10% of turnover, but let’s not waste time on estimations of such mundane things and get to the meat/tofu.

Technical background

Web browsers are able to install extensions to enhance what can be done with a web browser. The most popular is perhaps the Adblock which, well, blocks the display of ads. Such browsers must respect security boundaries to defend from, for example, sending all user data to a remote server to steal them. This is also why by default web browser extensions are vetted by vendors like Mozilla or Google. Only verified, approved extensions may be installed by users really effortlessly.


The issue here is that Google’s preinstalled extension is included directly in web browser Chromium code. This means that it works on every installed Chrome browser, including its derivatives like Microsoft Edge or Brave. The extension functionality allows sending diagnostic data to Google as defined in the Manifest file:


"externally_connectable": {
"matches": ["https://*.google.com/*"]
},

And that’s what’s sent:

port.postMessage({
'browserCpuUsage': browserProcessCpu || 0,
'gpuCpuUsage': gpuProcessCpu || 0,
'tabCpuUsage': tabProcess.cpu,
'tabJsMemoryAllocated': tabProcess.jsMemoryAllocated,
'tabJsMemoryUsed': tabProcess.jsMemoryUsed,
});

This can be demonstrated using this simple line of code.

You may visit chrome://system/ to verify that the extension 1) is installed, 2) has an ID of 'nkeimhogjdpnpccoofpliimaahmaaome'.


You can run the code in DevTools to demonstrate the potential to send data to Google servers (first, visit google.com):

chrome.runtime.sendMessage('nkeimhogjdpnpccoofpliimaahmaaome', {method: 'cpu.getInfo'}, response => {
const url = `https://www.google.com/path?X=${encodeURIComponent(JSON.stringify(response))}`;
fetch(url)
.then(response => response.json())
.then(data => console.log('Data sent to Google:', data))
.catch(error => console.error('Error:', error));
});


To show that it is not possible to do so with another extension, let’s try to execute the same with uBlock Origin ID ('cjpalhdlnbpafiamejdnhcphjbkeiagm'):

chrome.runtime.sendMessage('cjpalhdlnbpafiamejdnhcphjbkeiagm', {method: 'cpu.getInfo'}, response => {console.log(JSON.stringify(response, null, 2));});

This does not work:


The DMA article 6(7) stipulates that:

“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 (…) 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.”


This DMA article is popularly understood to apply solely to operating systems; however, it indeed may apply in this case to the entire software platform, including web browsers. This interpretation is justified as, despite web browsers not being part of operating systems, the article imposes requirements regardless of whether those features are part of the operating system. Therefore, in the current circumstances, it would apply.

In light of the above, I recall Recital 55: “competing service or hardware providers, … 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”.

Additionally, Recital 57 highlights that “The gatekeepers should, therefore, be required to ensure, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same operating system, hardware or software features that are available or used in the provision of its own complementary and supporting services and hardware. Such access can equally be required by software applications related to the relevant services provided together with, or in support of, the core platform service.”

These recitals articulate the legislative intent that gatekeepers must not only facilitate but actively ensure non-discriminatory access to essential software features, extending such obligations to cover web browsers.

This interpretation enforces that web browsers, as integral components of the software ecosystem, must comply with the DMA’s interoperability and access requirements to maintain a competitive digital market.

This ends the reasoning.

Summary

I recently had a talk about the DMA, and helped in Open Web Advocacy cause. This post is likely among the very few DMA assessments as applied to actual technology products. DMA is a tricky regulation, big businesses struggle with compliance. European Commission refuses to provide more detailed requirements, and some provisions are very general and ambiguous at best. Now, who has the lantern in this maze?


Comments, queries, or maybe offers? Contact me at me@lukaszolejnik.com, I’m seeking engagements.