The European Commission Hits the Nail on the Head in its DMA Specification Decision Forcing Google to Allow Access to its Search Data

Access to search data has been floating around as a remedy for some time now on both sides of the Atlantic. The DMA compels gatekeepers to render such access under Article 6(11) DMA, whereas the US courts are working on imposing similar remedies on the undertaking. With respect to the former, the European Commission (EC) has issued its Specification Decision relating to how Google must comply with Article 6(11) DMA by setting out the implementation measures that it must adopt in the short term.

When comparing the Specification Decision with the Draft Implementation Measures that the EC published in April for public consultation (see comment here), one clearly understands that the regulator went to great lengths to strengthen the data protection and privacy safeguards surrounding the implementation of Article 6(11) DMA. By doing so, the EC seeks to quieten the concerns that commentators and stakeholders voiced following the Draft Implementation Measures. However, a completely unrelated question to the improvements still looms in the background, which seeks to elucidate the interplay between the GDPR and the ex ante regulation.

Data Protection Reinforced: Data Scope, Anonymisation and a Segregated Processing Environment

Article 6(11) DMA mandates the gatekeeper to provide to any third-party undertaking providing online search engines (OSE) access on FRAND terms to ranking, query, click and view data in relation to its search results. Abiding by the provision, “any such query, click and view data that constitutes personal data shall be anonymised”. Recital 61 complements the provision’s content by stating that anonymisation must be performed to ensure the protection of the personal data of end users, including against possible re-identification risks, “without substantially degrading the quality or usefulness of the data”.

The nuance of those words has given leeway to differing interpretations of the provision. On one side, some argue that Article 6(11) DMA must provide equivalent protection in terms of anonymisation as that granted by the GDPR. On the other side, EC officials (and the EC itself) present the idea that Article 6(11) DMA requires anonymisation of the personal data of users who issued the queries (and not the personal data relating to individuals other than the end users). Following the EC’s narrower interpretation, then anonymisation must not be interpreted in the same strict sense as the GDPR, but rather it must be informed by the need to preserve the usefulness of the data, i.e., some personal data that is accessed by third-party OSEs will not be anonymised. This tension between both positions has informed some of the changes introduced by the regulator to the Specification Decision.

In terms of the legal standard that Article 6(11) DMA applies in relation to anonymisation, we will still have to wait for the fully-fledged decision where the EC fleshes out the rationale underlying its interpretation. It is, however, quite notable that the Specification Decision abandons the formerly and closely held belief that the technical measures of the implementation measures “alter the Search Data to mitigate the risk of re-identification of end users to a residual level” (para 19 of the Draft Implementation Measures). This was an implicit recognition from the EC that the technical measures applied for anonymisation could only get so far. Therefore, the contractual measures were absolutely necessary to lower the re-identification risk to an insignificant level.

The reference to residuality is dropped from the Specification Decision, which explicitly recognises that the measures alter the Search Data and “play a prominent role to mitigate the risk of re-identification of end users without substantially degrading the data quality and usefulness” (para 26 of the Specification Decision). In other words, the Commission eliminates the actual quantification of risk delivered by the technical measures (although those have been reinforced, as we will see later on) to demonstrate that the contractual measures are more of a backstop for a smaller residual than before.

The enforcer actually portrays both technical and contractual measures as “mitigating the risks of end users’ re-identification to an insignificant level” (para 26). Whether that is the case depends on the changes operated by the EC on its Specification Decision. And those amendments have focused on three main tenets surrounding the data protection safeguards relating to the access to search data, notably: i) the scope of data included in the Search Data; ii) the anonymisation techniques and fine-tuning that the EC tailors through its technical measures; and iii) the inclusion of a segregated processing environment requirement.

Even though the obligations imposed on Alphabet remain roughly the same under the Specification Decision, the regulator has fine-tuned the scope of the data included in the Search Data. For example, when it comes to query data, the EC narrows down the scope of query metadata that Alphabet must disclose to third-party OSEs. In the Draft Implementation Measures, the gatekeeper had to disclose the query’s timestamp, the user device identifier and the indication of the method of query input, including text, voice and photo requests (para 5 of the Draft Implementation Measures). The Specification Decision drops all those data points (para 11(b) of the Specification Decision). In the same vein, the scope of click data is substantially reduced from the Draft Implementation Measures to the Specification Decision. In the Draft Implementation Measures, Alphabet had to share click data on “the duration a user viewed the given URL/block or the data allowing to infer it, i.e., at least the height and size of the URL/block, its distance from the top of the SERP, the share it occupies of the user’s viewport (i.e., the area of the webpage which is visible on the user’s device) and the duration the user stayed on a given screen view” (para 9(b) of the Draft Implementation Measures). The Specification Decision eliminates all references to raw viewport, size and distance-from-top metrics (para 15 of the Specification Decision).

The choice of eliminating these types of data from the data scope entirely is not trivial. Some of them account for classic device and behavioural fingerprinting vectors, which can be characterised as high-entropy quasi-identifiers. That is to say, they are pieces of personal information that do not identify the person on their own but contain high levels of randomness. Therefore, when they are combined with other data, this high variability makes it incredibly easy to single out and re-identify an individual within an anonymised dataset.

For example, the precise query timestamp that the Draft Implementation Measures included is close to a unique identifier once the Search Data includes more than a handful of queries from someone. Human query submission patterns over time are essentially a behavioural signature. An adversary holding any other timestamped log of the same person can join on timestamp with very high precision. This is precisely what researchers did to re-identify individuals in the supposedly anonymised Netflix Prize dataset by cross-referencing those timestamps against public IMDb rating dates. Another example that can be a bit less evident is that of the click data relating to raw viewport, module size and distance from top. In its most basic expression, this data relates to screen height, module pixel dimensions and exact scroll distance. Unlike an attribute such as device type, the combination of these parameters creates a highly distinctive signature for browser fingerprinting, which can quickly reveal an individual’s device and their browsing habits.

This is not to say that the Draft Implementation Measures were wrong in including them in the first place. As a matter of fact, the technical measures provided that those parameters were to be generalised before applying the k-anonymity threshold. Their elimination from the data scope considered by the Specification Decision entails that anonymisation is externally verifiable, to the extent that a recipient or auditor will be able to confirm whether the data remain within the Search Data. Fundamentally, the change means that some of the attack surfaces present in the EC’s former approach have now been promptly closed.

In addition to the changes in the scope of data, the Specification Decision strengthens the EC’s approach towards anonymisation. The Draft Implementation Measures relied on k-anonymity, which is a data privacy model ensuring an individual’s specific data cannot be distinguished from at least k-1 other people in the same dataset. For instance, if a dataset has a k-value of 5, any combination of identifying attributes must be shared by at least 5 different records. If data cannot be grouped effectively, then it is removed or redacted. The difference between both versions lies with the threshold that the EC introduced in k-anonymity. The Draft Implementation Measures placed k-anonymity at 50, given that Alphabet had “to check whether at least 50 (r) signed-in end users (had) issued a query with the same metadata attribute values for inferred language, location information and device type” (para 31 of the Draft Implementation Measures). The Specification Decision increases the threshold times twenty, making k-anonymity = 1,000 (para 36 of the Specification Decision), which is much closer to what’s typically considered defensible and robust.

The Specification Decision introduces other changes, such as the explicit inclusion of phone numbers, coordinates, IBANs and card numbers to its detector taxonomy (para 29) or the use of a technical standard to perform geo-generalisation (para 35). Notwithstanding, one of the major improvements lies with mini-sessionisation. Mini-sessionisation aims to limit the ability to track a single user across their entire online history by breaking long and continuous streams of user activity into smaller and separate time blocks. The Draft Implementation Measures enabled Alphabet to “group records by ordering all records from the same end user chronologically and adding each search record to the previous group” if the user clicked on a query refiner, selected an autocomplete suggestion or entered a new query into the search box on the previous record’s SERP and there was a clear link between both (para 32 of the Draft Implementation Measures). The Specification Decision maintains those conditions and adds that the “maximum length of a mini-session shall be three queries, and a query can only be part of one mini-session (i.e., mini sessions shall not overlap)” (para 38 of the Specification Decision). The small tweak makes all the difference because now the EC’s approach makes it more difficult to re-identify a single user through the searches that an individual makes in sequence. Such a ‘reconstruction’ can only take place via chains that can be, at most, 3 searches long and they cannot cross into a new day. When longer sequences are available, re-identification is much easier. For example, in 2006 AOL released anonymised search logs. Journalists were able to identify individual users by reading their sequences of searches.

The amendments that the Specification Decision introduces also touch upon the contractual measures that complement the anonymisation techniques, as required by the Draft Joint Guidelines issued by the EDPB/EC on the interplay between the GDPR and the DMA, so as to mitigate residual likelihood of identification (para 181 of the Joint Guidelines, see comment here). In particular, the Specification Decision requires Alphabet to impose contractual conditions upon third-party OSEs “to process the Search Dataset exclusively within a logically and technically segregated processing environment so as to prevent linking between the Search Dataset and any other auxiliary dataset accessible to the third-party OSE or its subcontractors” (para 49 of the Specification Decision). The Draft Implementation Measures did not include such an obligation, although it did require the third-party OSE to generally “prohibit the copying, downloading or local storage of any data from the Search Dataset on authorised personnel-managed devices or workstations” (para 47 of the Draft Implementation Measures).

A segregated processing environment is an isolated computing framework designated to separate specific tasks or data from the rest of a system. Thus, the Specification Decision requires that the Search Dataset that is accessed must be technically isolated so that it cannot be queried jointly with auxiliary data and cannot be copied, merged or synchronised with auxiliary systems (para 49 of the Specification Decision). By doing so, the EC tackles one of the most common ways in which an anonymised dataset gets re-identified in practice, which is through a linkage attack, i.e., matching the anonymised dataset against a different dataset that has the missing identifying details. In practice, this means that the third-party OSEs are barred from copying or merging the Search Dataset alongside other datasets. The segregated processing environment makes such activities technically impossible for the third-party OSE.

Against this framework, the final result that the EC has delivered on its Specification Decision is certainly better in terms of the data protection safeguards that it introduces once Article 6(11) DMA is rolled out. However, will it be enough to satisfy the legal standard required by the GDPR? Some (including EC officials, with whom I respectfully disagree) would argue that this is not the correct question to make, since the DMA does not transpose the GDPR into the letter of law. But, in my own view, there is no other legal standard for us to go to. In the parallel reality where anonymisation under the GDPR is not required by the DMA, then Article 6(11) DMA would enshrine a lower legal standard than that contained under the data protection regime. And where would that lead us? To derive that parallel and specialised regimes may be enshrined in EU law if there is a relevant enough interest (not a fundamental right) to protect via secondary law.

So let’s focus on the initial question: does the Specification Decision meet the legal standard for anonymisation (if one can readily single it out!) under the GDPR? At the very least, the Specification Decision improves the EC’s chances of meeting the legal standard. The improvements on k-anonymity and the introduction of technical standards reduce the likelihood of singling out an individual’s personal data for any individual attribute combination. However, the technical measures that build on query-suppression logic by checking entity membership and overall string length have been left unchanged by the Specification Decision. This means that rare queries will be eliminated from the Search Data. A query built entirely of common allowlisted words will still fall through the cracks, even though it can still be a globally unique combination of words.  In addition, the tweaks introduced in the Specification Decision in terms of mini-sessionisation and mandating a segregated processing environment meaningfully reduce the third-party OSE’s ability to link records into longer behavioural trails. The contractual measures do not eliminate all risks associated with combinations with auxiliary data, to the extent that motivated-intruder risks persist, i.e., the chance that a third party combines the Search Dataset with external auxiliary data.

Bearing that in mind, one can clearly argue that the Specification Decision demonstrates genuine progress on the EC’s side when approaching the implementation of Article 6(11) when put in relation with data protection standards. It’s still uncertain whether those safeguards will be enough to satisfy the legal standard that the legislator itself introduced via the regulation.

More Work Done in Eligibility

In my previous comment, I challenged the EC’s brief description of the eligible undertakings that could access the remedy under Article 6(11) DMA. In my own view, a general reference to anyone who meets the definition of an OSE under Article 2(5) of the P2B Regulation does not quite meet the threshold of necessary justification that should go into a public institution’s reasoning in making a particular decision.

Following this reasoning, the Specification Decision gets into much more detail in terms of who might be eligible to access the Search Data. The EC adds four additional assessments that any third-party OSE must meet to be able to exercise its rights under Article 6(11) DMA (which Alphabet is in charge of analysing). First, the third-party OSE must not be subject, directly or indirectly, to restrictive measures or other sanctions under Union law (para 3(a) of the Specification Decision). Second, the undertaking applying for eligibility must not be subject to the control of a third country that poses a serious and structural non-technical cyber security and/or data protection risk (para 3(b)). Third, the undertaking must be an established company or a credible new entrant providing an OSE as a genuine economic activity in the EU. For this purpose, the third-party OSE must prove that it either: a) has provided OSE services in the EU for at least two consecutive years or b) was founded less than two years ago but has received more than 50 million EUR in capital investments. Additionally, the undertaking must have had at least 50,000 monthly average users of its OSE services in the EU in the past year (para 3(c)). Fourth, Alphabet should also inquire on whether the undertaking plans to process and maintain the Search Data within the EEA or whether it plans to request access via international transfers. If the gatekeeper cannot guarantee EEA-equivalent protections to non-EU countries via an adequacy decision, then this also is a ground to refuse an undertaking’s eligibility (paras 6 and 7).

These eligibility conditions ensure that EU sanctions are not evaded and that undertakings do not hide behind shell companies to simply access the Search Data made available through Article 6(11) DMA. Both those objectives are legitimate concerns to bear in mind. However, one cannot really understand why the gatekeeper must be in charge of conducting a third-country control and cybersecurity risk assessment that is similar to the FDI and investment screening regime that the EC conducts in the context of mergers. These instruments exist because public authorities, and not private parties, are supposed to make these judgments, whilst complementarily making use of intelligence and diplomatic channels. Asking Alphabet to make these calls seems wholly inappropriate, precisely because it does not have enough information to layer this type of assessment onto its role as an access provider. In addition, the economic requirements placed as eligibility conditions may also contribute to undermining contestability, insofar as technically excellent but under-capitalised new entrants will be gated from accessing the rights created by Article 6(11) DMA.

Aside from that, the EC does not really clarify why AI chatbots provide comparable services to those that a traditional third-party OSE caters to in more detail. It is true, however, that the contractual measures do account for some of the peculiarities that AI chatbots bring to the table. For instance, the contractual measures now require Alphabet to submit a pre-deployment evaluation of the model to ensure that it does not reproduce data from the Search Dataset and exposes end users to risks of re-identification (para 54). By doing so, the Specification Decision acknowledges that memorisation must be addressed head on by the implementation measures to avoid that anonymised inputs get leaked as quasi-identifying patterns at the consumer level.

Who Foots the Bill?

As you may recall from the start of this post, Article 6(11) DMA provides that access to search data must be provided under FRAND conditions. The EC has interpreted that those FRAND conditions lead the pricing structure to necessarily correspond with a FRAND price, which might remind the avid reader of SEP licensing or EU telecom interconnection pricing.

Back in the Draft Implementation Measures, the EC set out that the FRAND methodology that would be used to ensure that Alphabet would be appropriately remunerated for its efforts to share the search data was a cost-based methodology, and not a value-based one. In the EC’s own words, such compensation should reflect “the incremental costs incurred by Alphabet for the purpose of making such Search Data available plus a reasonable return, corresponding to a return on the capital employed for that purpose that shall not exceed Alphabet’s weighted average cost of capital” (para 71 of the Draft Implementation Measures.

From the EC’s reading of the FRAND clause, one can quickly guess that the incentive structure inverts itself relative to SEP licensing. In SEP licensing, the patent holder’s incentive is to maximise licensing revenue. Given that the patent holder wants more licensees paying, their main temptation is to overcharge. The FRAND doctrine is built entirely to constrain this particular incentive.

In turn, the EC’s approach towards FRAND in Article 6(11) DMA makes licensing revenues economically trivial for Alphabet, so that the temptation is no longer to overcharge. Rather, the sharing of data with rival third-party OSEs poses a competitive threat, so that the gatekeeper will have every incentive to try to delay or degrade the usefulness of the data. Cost-based pricing accentuates the problem. And the changes introduced by the Specification Decision only deepen the incentive structure. The EC compels the gatekeeper to “grant access to the Search Dataset to each eligible third-party OSE within 10 days after it has entered into a licence agreement and accepted the price offer, which is to be finalised within six months (of the adoption of the implementation measures)” (para 131 of the Specification Decision). The 6-month deadline can be flexibilised further where the gatekeeper does not propose an appropriate methodology (para 136). Therefore, the gatekeeper has every incentive to slow the process down and no comparable interim access mechanism is provided by the Specification Decision. For instance, in SEP licensing an interim access mechanism is provided whilst the FRAND rate is being worked out, precisely so that the rate disputes do not become a de facto blocking mechanism.

Furthermore, the FRAND regime established by the EC’s Specification Decision fails to provide enough assurances to ensure that the gatekeeper does not overprice. As opposed to the Draft Implementation Measures, the Specification Decision requires Alphabet to identify one-off and recurrent incremental costs so that they can be easily tracked when factored into the methodology for compensation by submitting an exhaustive list of cost items and estimates (paras 92 and 133).

Let’s assume that SEP licensing is not the blueprint against which the EC designs the FRAND rate for Article 6(11) DMA, and let’s take the example of EU telecom interconnection pricing under the Access Directive framework instead. The regime introduced a pure long-run incremental cost (LRIC) methodology by which maximum termination rates were calculated on the basis of the additional costs required to produce the service over a multi-year period. Sunk costs are ignored and maximum efficiency is assumed. The LRIC ensures that companies can cover long-term investments without overcharging. What’s lacking from the Article 6(11) DMA regime, if we draw this comparison, is that no independent cost auditor is mandated to verify Alphabet’s actual cost accounts. In the telecom regime, national regulatory authorities built standardised bottom-up cost models and required regulatory accounting separation for this purpose. The Specification Decision is lacking in providing the appropriate safeguards to counter this information asymmetry, which the Commission can only disagree with and order a resubmission so that a new calculation is made (para 138). By this token, one turns again to the idea of self-reporting that I pointed out in my previous comment relating to the EC’s specification proceedings against Alphabet under Article 6(7) DMA: the gatekeepers rely on enforced self-regulation in the midst of a regulation that does not provide for it.