{"id":23918,"date":"2026-09-09T22:00:00","date_gmt":"2026-09-09T22:00:00","guid":{"rendered":"https:\/\/scannn.com\/how-and-why-google-will-share-anonymized-search-data-with-their-competitors\/"},"modified":"2026-09-09T22:00:00","modified_gmt":"2026-09-09T22:00:00","slug":"how-and-why-google-will-share-anonymized-search-data-with-their-competitors","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/how-and-why-google-will-share-anonymized-search-data-with-their-competitors\/","title":{"rendered":"How and why Google will share anonymized search data with their competitors"},"content":{"rendered":"\n<div>\n<p><strong>In<\/strong> Europe, the online search engine market is very concentrated: Google<br \/>\nSearch has had around <a href=\"https:\/\/gs.statcounter.com\/search-engine-market-share\/all\/europe\">90% of the market share<\/a> for over a decade. This<br \/>\ngives Google access to a massive amount of data about what people search for,<br \/>\nwhat they click on, what modules they interact with on the page, and so on.<\/p>\n<p>This data is immensely useful to optimize a search engine. To understand why,<br \/>\nlet&#8217;s look at one of my recent online sessions on Google Search. I type \u201cgrand<br \/>\nprix\u201d, stay on the search page for less than 2 seconds without clicking on<br \/>\nanything, then go back to the search bar and type \u201cgrand prix attack\u201d. I click<br \/>\non the first link from<br \/>\n<a href=\"https:\/\/www.chess.com\/openings\/Closed-Sicilian-Defense-Grand-Prix-Attack\">chess.com<\/a>,<br \/>\nthen go back to the search page after 1.5 seconds, then click on the second link<br \/>\nfrom<br \/>\n<a href=\"https:\/\/www.reddit.com\/r\/chess\/comments\/1isdh4h\/thoughts_on_grand_prix_attack_against_sicilian\/\">Reddit<\/a>,<br \/>\nthen go back to the search page after 37.8 seconds, then click on the<br \/>\n<a href=\"https:\/\/www.youtube.com\/watch?v=lj930-Mz7tc\">first video result by Eric<br \/>\nRosen<\/a> and don&#8217;t ever come back to<br \/>\nthe search page.<\/p>\n<p>What has Google learned in the process?<\/p>\n<ul>\n<li>Some people who look up \u201cgrand prix\u201d are actually looking for chess content<br \/>\n  and not Formula 1. It might be worth suggesting \u201cchess\u201d as an autocompletion<br \/>\n  for this term.<\/li>\n<li>The chess.com link, despite its nice favicon and great branding, may not<br \/>\n  actually be that useful for people who look up a chess opening, since I only<br \/>\n  stayed on this page for such a short time.<\/li>\n<li>By contrast, the reddit.com page seems much more useful. I stayed there long<br \/>\n  enough to read and engage with the content, so I must have thought this was<br \/>\n  worth it.<\/li>\n<li>Returning videos is a great idea for chess-related searches; more<br \/>\n  specifically, Eric Rosen is a trusted source of educational chess content.<\/li>\n<\/ul>\n<p>Multiply this by hundreds of millions of users who regularly look up things on<br \/>\nGoogle Search, and this data is <em>absolute gold<\/em> to improve a search engine. It<br \/>\nhelps you suggest good autocompletions, understand what users mean when they<br \/>\ntype ambiguous queries, learn which websites users find most useful so you can<br \/>\nshow them first in the results and crawl them more regularly, among a ton of<br \/>\nother use cases.<\/p>\n<p>Every search engine provider uses their own data to optimize their product. But<br \/>\nthe magnitude and the diversity of the data matters a lot: regardless of how<br \/>\nmuch you optimize your machine learning pipelines, if you have orders of<br \/>\nmagnitude less data than Google, you won&#8217;t be able to match Google Search&#8217;s<br \/>\nperformance. This phenomenon occurs for all kinds of learning tasks\u00a0\u2014\u00a0Google<br \/>\nscientists called it the \u201cunreasonable effectiveness of data\u201d in a <a href=\"https:\/\/research.google.com\/pubs\/archive\/35179.pdf\">2009<br \/>\narticle<\/a>.<\/p>\n<p>The European legislator considered that the lack of healthy competition in the<br \/>\nsearch engine market was a problem. In 2022, it passed<sup id=\"fnref:passed\"\/> the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_Markets_Act\">Digital<br \/>\nMarkets Act<\/a> (DMA) to address it. The DMA attempts to encourage healthier<br \/>\ncompetition in a large variety of digital markets, and <a href=\"https:\/\/eur-lex.europa.eu\/eli\/reg\/2022\/1925\/oj\/eng#006.011\">Article\u00a06(11)<\/a><br \/>\nis specifically about the online search engine business. It states the<br \/>\nfollowing:<\/p>\n<blockquote>\n<p>The gatekeeper shall provide to any third-party undertaking providing online<br \/>\nsearch engines, at its request, with access on fair, reasonable and<br \/>\nnon-discriminatory terms to ranking, query, click and view data in relation to<br \/>\nfree and paid search generated by end users on its online search engines. Any<br \/>\nsuch query, click and view data that constitutes personal data shall be<br \/>\nanonymised.<\/p>\n<\/blockquote>\n<p>Here, the \u201cgatekeeper\u201d is Google<sup id=\"fnref:gatekeeper\"\/>: they must share their search data<br \/>\nwith competitors, in anonymized form. In March 2024, to comply with DMA\u00a06(11),<br \/>\nGoogle started to offer access to an anonymized dataset to its competitors.<br \/>\nThere was no significant uptake: even though search data is incredibly valuable<br \/>\nto optimize a search engine, and competing search engine providers are starved<br \/>\nfor data, they didn&#8217;t think Google&#8217;s offer was worth taking.<\/p>\n<p>In reaction to the lack of uptake of Google&#8217;s proposed dataset, the European<br \/>\nCommission decided to intervene. In January\u00a02026, it opened <a href=\"https:\/\/ec.europa.eu\/commission\/presscorner\/detail\/en\/ip_26_202\">specification<br \/>\nproceedings<\/a> to attempt to resolve the issue. The proceedings ended<br \/>\n<a href=\"https:\/\/ec.europa.eu\/commission\/presscorner\/detail\/en\/ip_26_1634\">last month<\/a>, and the <a href=\"https:\/\/ec.europa.eu\/competition\/digital_markets_act\/cases\/202637\/DMA_100209_2799.pdf\">full decision<\/a> was published<br \/>\nthis week. It describes in great detail how Google needs to comply with<br \/>\nArticle\u00a06(11).<\/p>\n<p>In October\u00a02025, the European Commission asked me to help them with these<br \/>\nproceedings. I quickly understood why: the anonymization strategy chosen by<br \/>\nGoogle was the single greatest issue with their compliance approach. Their<br \/>\ndesign choices rendered the data all but useless for optimizing a search engine.<br \/>\nThis makes sense considering the incentives at play: obviously, the last thing<br \/>\nthey want is for their competitors to build good alternatives to Google Search.<\/p>\n<p>I&#8217;ve been working with them throughout the proceedings, and it&#8217;s been an<br \/>\ninteresting ride! I helped with a variety of tasks:<\/p>\n<ul>\n<li>analyzing Google&#8217;s proposed anonymization approach in detail<sup id=\"fnref:initial\"\/>,<\/li>\n<li>collecting information by meeting and asking written questions to Google and<br \/>\n  its competitors,<\/li>\n<li>designing an alternative solution to anonymize the data,<\/li>\n<li>performing data analysis to evaluate its effectiveness (with the help of my<br \/>\n  excellent colleague <a href=\"https:\/\/brandworthy.ai\/about\">Rebecca<\/a>),<\/li>\n<li>understand the many (many) pieces of evidence used in this case,<\/li>\n<li>address all the feedback from public consultations and Google&#8217;s technical<br \/>\n  arguments and experimental evidence,<\/li>\n<\/ul>\n<p>\u2026 and more. In the rest of this blog post, I&#8217;ll explain the anonymization<br \/>\napproach selected by the Commission to enable this data sharing in a way that<br \/>\nachieves both the privacy and utility goals set forth by the relevant<br \/>\nlegislation.<\/p>\n<p><em>Disclaimer: I have been working with the European Commission as part of a<br \/>\nseries of paid engagements. This blog post is not part of our contract; it is<br \/>\nstrictly based on publicly available information, and I am not being paid for<br \/>\nit. The Commission reviewed it for factual accuracy, and to make sure that I&#8217;m<br \/>\nnot revealing anything confidential. All opinions remain my own.<\/em><\/p>\n<p>The DMA specifies that the search data must be anonymized. What is the exact<br \/>\ncriterion used to determine whether the shared data passes the anonymization<br \/>\nbar? The standard set forth by the DMA (in <a href=\"https:\/\/eur-lex.europa.eu\/legal-content\/EN\/TXT\/?uri=uriserv%3AOJ.L_.2022.265.01.0001.01.ENG&amp;toc=OJ%3AL%3A2022%3A265%3ATOC#rct_61\">Recital\u00a061<\/a>) is as follows. It<br \/>\nwill sound familiar to readers who know <a href=\"https:\/\/en.wikipedia.org\/wiki\/General_Data_Protection_Regulation\">GDPR<\/a>&#8216;s <a href=\"https:\/\/eur-lex.europa.eu\/legal-content\/EN\/TXT\/?uri=CELEX%3A32016R0679&amp;qid=1783338815431#rct_26\">Recital\u00a026<\/a>.<\/p>\n<blockquote>\n<p>The relevant data is anonymised if personal data is irreversibly altered in<br \/>\nsuch a way that information does not relate to an identified or identifiable<br \/>\nnatural person or where personal data is rendered anonymous in such a manner<br \/>\nthat the data subject is not or is no longer identifiable.<\/p>\n<\/blockquote>\n<p>This requirement is further clarified in a separate document, the <a href=\"https:\/\/www.edpb.europa.eu\/public-consultations\/joint-guidelines-on-the-interplay-between-the-digital-markets-act-and-the_en\">Draft Joint<br \/>\nGuidelines<\/a> on the interplay between DMA and GDPR, co-written by the<br \/>\n<a href=\"https:\/\/en.wikipedia.org\/wiki\/European_Data_Protection_Board\">European Data Protection Board<\/a> and the European Commission. These<br \/>\nguidelines establish two important (and fairly unique) specificities of<br \/>\nArticle\u00a06(11) data sharing.<\/p>\n<ol>\n<li>First, only end users are covered by the privacy goal. Say that Alice<br \/>\n   searches for Bob&#8217;s full name, and one of the results contains Camille&#8217;s<br \/>\n   personal website. Then, <em>only Alice&#8217;s identity must be protected<\/em>: someone<br \/>\n   looking at the anonymized data must not be able to tell that Alice submitted<br \/>\n   this query. But it&#8217;s OK to share the query or its results even if they<br \/>\n   contain Bob&#8217;s or Camille&#8217;s personal information.<\/li>\n<li>Second, anonymization may be met with a combination of <em>technical measures<\/em><br \/>\n   (modifying the data itself) and <em>non-technical measures<\/em> (everything<br \/>\n   else<sup id=\"fnref:ntm\"\/>). Technical measures need to be prominent, but it&#8217;s OK if they<br \/>\n   leave some non-zero level of re-identification risk, as long as this residual<br \/>\n   risk is then adequately mitigated by the non-technical measures.<\/li>\n<\/ol>\n<p>The first point means that even if the anonymization goal is met, the shared<br \/>\ndataset <em>still contains personal data<\/em>. So the GDPR still applies to this data!<br \/>\nThis is unusual: usually, organizations anonymize data because they want to take<br \/>\nit out of scope of GDPR obligations entirely.<\/p>\n<p>The second point means that the technical measures don&#8217;t need to be entirely<br \/>\nbulletproof. They only need to bring down the re-identification risk to an<br \/>\nacceptable \u201cresidual\u201d level. The law doesn&#8217;t specify exactly what this residual<br \/>\nlevel of risk means in practice; we made this notion more concrete in the<br \/>\nfollowing way. <\/p>\n<blockquote>\n<p>[\u2026] risks are considered beyond residual level after application of technical<br \/>\nmeasures if they meet any of the following criteria:<\/p>\n<ul>\n<li>An adversarial entity can choose a specific individual and, with<br \/>\n  significant probability, retrieve some of their search records with high<br \/>\n  certainty.<\/li>\n<li>An adversarial entity can choose a random search record and, with<br \/>\n  significant probability, re-identify the end user with high certainty.<\/li>\n<li>An adversarial entity can perform attacks that re-identify a large number<br \/>\n  of end users with high certainty and with reasonably simple methods.<\/li>\n<\/ul>\n<\/blockquote>\n<p>This corresponds to the main two risk factors of this data sharing scheme.<\/p>\n<ol>\n<li>Indiscreet employees could try to find the search records of people they know<br \/>\n   about or be overly curious and attempt to re-identify the data they see in<br \/>\n   the course of their jobs. This is often called \u201cinsider risk\u201d and must be<br \/>\n   mitigated.<\/li>\n<li>Product or data analysis teams within recipient organizations could, in<br \/>\n   violation of their contractual obligations, attempt to re-identify the data<br \/>\n   and use it for other purposes (like augmenting other datasets).<\/li>\n<\/ol>\n<p>In particular, this definition means that finding a few specific edge-case<br \/>\nexamples of records that may be reidentifiable is not an indication that the<br \/>\nrisk is above this residual level. If it can only happen for a very low fraction<br \/>\nof records and\/or with a lot of inherent uncertainty, this is acceptable: it can<br \/>\nthen be complemented by non-technical measures to address residual risk. We&#8217;re<br \/>\nnot trying to provide formal guarantees that hold for any attacker, like in<br \/>\n<a href=\"https:\/\/desfontain.es\/blog\/friendly-intro-to-differential-privacy.html\">differential privacy<\/a>; this would be largely incompatible with achieving<br \/>\nreasonable utility for this use case. Rather, we&#8217;re trying to mitigate the bulk<br \/>\nof the real-world risk, considering realistic adversaries and extensive<br \/>\nnon-technical protections.<\/p>\n<p>Article\u00a06(11) also specifies that if multiple possible methods meet the<br \/>\nanonymization bar, one must choose the one that retains most utility. To<br \/>\ndetermine what this means in practice, we spent a long time discussing with<br \/>\nsearch engine providers to understand how they would use the data<sup id=\"fnref:understand\"\/>.<br \/>\nOf course, I expected search engines to be complex systems, but the sheer number<br \/>\nand diversity of potential use cases still took me aback. Different providers<br \/>\nhave very different interests and business strategies, and each one has many<br \/>\ndistinct uses for this data.<\/p>\n<p>There are three categories of use cases for which the asymmetry in access to<br \/>\nuser data is particularly painful for Google&#8217;s competitors.<\/p>\n<ol>\n<li><em>Crawling and indexing.<\/em> Search engines need to maintain an up-to-date list<br \/>\n   of all the Web pages that can be returned as a result (the \u201cindex\u201d), which<br \/>\n   they obtain by having bots access the Web (\u201ccrawling\u201d). Access to more data<br \/>\n   helps search engines understand where the gaps are in their index, determine<br \/>\n   what to crawl, and decide how often to crawl different websites.<\/li>\n<li><em>Query understanding.<\/em> Queries submitted by users are often vague and<br \/>\n   ambiguous, but users still expect the search engine to understand what they<br \/>\n   mean and give them good results. Machine learning models are trained on user<br \/>\n   queries and interactions to figure out what queries actually mean. More data<br \/>\n   makes these models perform much better.<\/li>\n<li><em>Ranking and quality.<\/em> This is about deciding which modules and results to<br \/>\n   show in search results, and in which order. Users want (and expect) to see<br \/>\n   useful, trustworthy results near the top of the page. Interaction data is<br \/>\n   critical to improve the underlying algorithms.<\/li>\n<\/ol>\n<p>For all the three use cases above, the asymmetry in data access is about the<br \/>\nlong tail. Online search engines don&#8217;t need Google data to provide good results<br \/>\nto queries like \u201cweather z\u00fcrich tomorrow\u201d, or \u201ccapital of switzerland\u201d. But it&#8217;s<br \/>\na lot harder to do a good job answering novel and ambiguous queries, for which<br \/>\nrelevant results are on rarely-visited websites. And these are very important<br \/>\nfor user satisfaction! If a search engine does a good job answering 90% of<br \/>\nqueries, but fails on the remaining 10%, this is often enough to be an<br \/>\nunacceptable level of quality for end users.<\/p>\n<p>The \u201clong tail\u201d means something different for all three use cases.<\/p>\n<ol>\n<li>For crawling and indexing, what matters are impressions and clicks on URLs<br \/>\n   that are rarely viewed or rarely clicked: those are the ones that are most<br \/>\n   likely to be missing from competitors&#8217; indexes.<\/li>\n<li>For query understanding, the rare queries are super important: 15% of search<br \/>\n   queries seen by Google Search every day are <a href=\"https:\/\/www.google.com\/intl\/en_in\/search\/howsearchworks\/our-approach\/\">brand new<\/a>, and the<br \/>\n   diversity and scale of this long tail is critical to build performant models.<\/li>\n<li>For ranking and quality, interaction data is critical. It&#8217;s very useful to<br \/>\n   know that someone went back to the search page quickly after clicking on the<br \/>\n   first result, but stayed on the second result longer. And this interaction<br \/>\n   data is only useful when provided with the relevant context: which results did<br \/>\n   the user <em>not<\/em> click on?<\/li>\n<\/ol>\n<p>All these data attributes, and many others, were considered to be in scope of<br \/>\nArticle\u00a06(11) by the Commission&#8217;s legal analysis.<\/p>\n<p>The privacy guarantees of the data sharing scheme specified by the European<br \/>\nCommission come from the combination of three sources: eligibility, technical<br \/>\nmeasures, and non-technical measures.<\/p>\n<p><center><br \/>\n<br \/>\n<\/center><\/p>\n<h4 id=\"eligibility\">Eligibility<\/h4>\n<p>Strict criteria limit who can be a recipient of Google Search data: only<br \/>\nestablished online search engines or credible new entrants are eligible, and<br \/>\nadditional guardrails prevent foreign state actors from gaining access to it.<\/p>\n<ul>\n<li>Qualifying as an established online search engine requires 50,000 monthly<br \/>\n  active users, and either more than 2 years of existence, or more than<br \/>\n  50,000,000\u20ac in capital investments.<\/li>\n<li>Alphabet must then assess the eligibility of potential recipients, and may<br \/>\n  reject them if they&#8217;re subject to restrictive measures by the EU (e.g.<br \/>\n  sanctions), or if they&#8217;re controlled by a non-<a href=\"https:\/\/en.wikipedia.org\/wiki\/European_Economic_Area\">EEA<\/a> state actor that poses<br \/>\n  \u201cserious and structural [\u2026] data protection risk\u201d<sup id=\"fnref:state\"\/>.<\/li>\n<\/ul>\n<p>Most online search engines that you&#8217;ve heard of should be eligible, which is<br \/>\ngood for competition. The Commission also determined that if an AI chatbot has a<br \/>\nsearch feature to find and summarize information from the Web, they should also<br \/>\ncount as online search engines. This is aligned with Google&#8217;s own <a href=\"https:\/\/blog.google\/products-and-platforms\/products\/search\/search-io-2026\/\">pivot<\/a> to<br \/>\ndeeply integrating AI features into Google Search.<\/p>\n<p>On the other hand, the barrier of access for new entrants is pretty high: people<br \/>\ncan&#8217;t just pop up a fake search engine for the sole purpose of accessing the<br \/>\ndata, and there are several filters in place to catch ill-intended actors.<\/p>\n<h4 id=\"technical-measures\">Technical measures<\/h4>\n<p>The bulk of the risk mitigation happens through the technical measures. They<br \/>\nwere a primary focus of our work, and must reduce the re-identification risk to<br \/>\na sufficiently low residual level as defined above. The procedure specified by<br \/>\nthe European Commission has five main stages<sup id=\"fnref:stages\"\/>.<\/p>\n<p><center><br \/>\n<img decoding=\"async\" alt=\"A simple diagram with five boxes displayed vertically. They read, in order:&#10;&quot;De-identification: Turns linkable queries into a \u201chaystack\u201d&quot;,&#10;&quot;Entity-based thresholding: Removes queries with potential secrets&quot;,&#10;&quot;Length-based thresholding: Removes longer, more risky queries&quot;,&#10;&quot;Metadata generalization: Makes each \u201chaystack\u201d very large&quot;, and finally&#10;&quot;Mini-sessionisation: Re-groups queries when it doesn\u2019t increase risk&quot;&#10;\" src=\"https:\/\/desfontain.es\/blog\/images\/technical-measures-6-11.svg\" width=\"100%\"\/><br \/>\n<\/center><\/p>\n<ol>\n<li>\n<p><strong>De-identification and attribute removal.<\/strong> For each search record, the<br \/>\n   procedure removes user identifiers, precise timestamps, and a number of other<br \/>\n   attributes that could potentially be used as a user fingerprint.<\/p>\n<\/li>\n<li>\n<p><strong>Query suppression based on rare entities.<\/strong> Each search query is passed<br \/>\n   through a personal data detector to extract full names, addresses, phone<br \/>\n   numbers, location coordinates, and so on; then, each separate word is also<br \/>\n   extracted from the query. If either of these \u201centities\u201d has been searched by<br \/>\n   fewer than 50 distinct users in the past year, the search record is removed.<\/p>\n<\/li>\n<li>\n<p><strong>Query suppression based on length.<\/strong> All search queries that are longer (in<br \/>\n   characters) than the 95th percentile of search queries for the same<br \/>\n   language are removed<sup id=\"fnref:length\"\/>.<\/p>\n<\/li>\n<li>\n<p><strong>Metadata generalization.<\/strong> The end user location associated with each<br \/>\n   search query is replaced by a large region<sup id=\"fnref:nuts\"\/>, and the precise device<br \/>\n   type is replaced by a broad category (either desktop, mobile, or<br \/>\n   tablet).<br \/>Then, the procedure checks if at least 1,000 signed-in users share the same<br \/>\n   location, device type, and inferred language in the data. If not, the<br \/>\n   location is further coarsened to country-level. If the 1,000-user threshold<br \/>\n   is still not met at that level, the search record is removed<br \/>\n   entirely<sup id=\"fnref:kanon\"\/>.<\/p>\n<\/li>\n<li>\n<p><strong>Mini-sessionisation.<\/strong> The procedures looks for instances in the original<br \/>\n   data where a user submitted a search query, then either (1) clicked on a link<br \/>\n   on the results page, which submitted a second search query (e.g. \u201cDid you<br \/>\n   mean\u2026\u201d suggestions, entity chips, etc.); or (2) entered a new query into the<br \/>\n   search box on the results page, and the first query is a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Substring\">substring<\/a> of the<br \/>\n   second one. <br \/>The procedure then associates the corresponding records<br \/>\n   together to form <em>mini-sessions<\/em>, with a limit of 3 successive queries.<\/p>\n<\/li>\n<\/ol>\n<p>Let&#8217;s go through these steps one by one to understand the intuition behind each<br \/>\none.<\/p>\n<ol>\n<li>\n<p>De-identification is the most important step: it turns a dataset with full<br \/>\n   search histories for each user into a \u201chaystack\u201d of individual queries. The<br \/>\n   goal is to make it so that if someone looks at the anonymised data, they<br \/>\n   cannot combine multiple queries from the same user to build a rich profile<br \/>\n   about them and use this for re-identification. This comes at a steep utility<br \/>\n   cost: recipients (unlike Google) don&#8217;t have full search sessions, which can<br \/>\n   be very useful for in-depth query understanding.<\/p>\n<\/li>\n<li>\n<p>Word- and entity-based query suppression is designed to remove <em>secrets<\/em> from<br \/>\n   the data. Think package tracking numbers, links to nonpublic URLs, passport<br \/>\n   numbers, and so on: such queries are more likely to contain personal data<br \/>\n   that can be associated with the end user. Many such removals are false<br \/>\n   positives (like typos), but this is unavoidable.<\/p>\n<\/li>\n<li>\n<p>Length-based query suppression mitigates the risk from particularly long<br \/>\n   queries, which are more likely to be accidental copy and pastes of private<br \/>\n   documents, and can contain more identifiable data. Similarly, this incurs<br \/>\n   some utility cost (longer queries are often innocuous but useful to<br \/>\n   understand long-tail behavior), but mitigates an important factor of<br \/>\n   potential risk.<\/p>\n<\/li>\n<li>\n<p>Metadata generalization makes each \u201chaystack\u201d of queries large enough to<br \/>\n   prevent attackers from figuring out which search records come from the same<br \/>\n   user. It leaves some valuable metadata attributes in the data, while<br \/>\n   mitigating the fingerprinting risk. The hard threshold is at 1,000 users, but<br \/>\n   the majority of users are in much larger buckets (95% are in groups of 25,000<br \/>\n   users or more).<\/p>\n<\/li>\n<li>\n<p>Finally, mini-sessionisation recovers some of the data value that was lost<br \/>\n   due to de-identification, without meaningfully increasing the privacy risk.<br \/>\n   It augments the dataset with information about <em>refinement queries<\/em>:<br \/>\n   situations where the user didn&#8217;t find what they were looking for because<br \/>\n   their initial query was too vague, and directly modified their search. The<br \/>\n   conservative criteria on when queries can be associated in this way ensures<br \/>\n   that a mini-session typically doesn&#8217;t reveal any additional information<br \/>\n   compared to just the final query.<\/p>\n<\/li>\n<\/ol>\n<p>The strategy was designed to mitigate the vast majority of the issues that could<br \/>\ncause end user re-identifiability risk, and ensure that in the unlikely event<br \/>\nthat re-identification happens, the attacker doesn&#8217;t learn anything useful about<br \/>\ntheir target.<\/p>\n<p>But nobody is arguing that these technical measures bring the risk to zero!<br \/>\nTheir role is to mitigate it to a residual level that meets the above criterion.<br \/>\nIt&#8217;s the combination of technical and non-technical measures, taken together,<br \/>\nthat meets the anonymisation bar.<\/p>\n<h4 id=\"non-technical-measures\">Non-technical measures<\/h4>\n<p>The eligibility criteria are just the first step for an organization to access<br \/>\nto the data. They must then demonstrate that they will be able to comply with a<br \/>\nseries of <em>non-technical measures<\/em>, governing the processing and usage of the<br \/>\nanonymized search data. Here are some of its key requirements<sup id=\"fnref:nont\"\/>.<\/p>\n<ul>\n<li><em>Segregated processing environment.<\/em> Recipients must separate the computing<br \/>\n  environment in which the search data is stored and processed from the rest of<br \/>\n  their infrastructure. Copying it elsewhere, or sharing it with third-parties,<br \/>\n  is strictly forbidden.<\/li>\n<li><em>Purpose limitation.<\/em> Recipients can only use the search data to optimize<br \/>\n  their online search engines. For AI chatbots, search data can be used to<br \/>\n  optimize the \u201csearch and retrieval\u201d part of their operation, not to train or<br \/>\n  fine-tune general-purpose LLMs. Using the data for any other purpose is<br \/>\n  strictly forbidden.<\/li>\n<li><em>Prohibition against linking, re-identification and augmentation.<\/em> Recipients<br \/>\n  must not attempt to link the search data with auxiliary datasets, try to<br \/>\n  figure out an end user&#8217;s identity, nor augment the dataset in a way that<br \/>\n  reverses some of the technical measures. Note that this doesn&#8217;t matter whether<br \/>\n  such attempts would be successful: the very act of trying would be a breach of<br \/>\n  their contractual obligations.<\/li>\n<li><em>Retention.<\/em> Recipients must delete the data 13 months after they receive it.<\/li>\n<li><em>Governance and traceability.<\/em> Recipients must record and track all operations<br \/>\n  that access the search data, and models trained or fine-tuned with it must be<br \/>\n  evaluated to ensure that they don&#8217;t reproduce re-identifiable data.<\/li>\n<\/ul>\n<p>Those aren&#8217;t just pinky promises: recipients must pass a first independent audit<br \/>\nto confirm that they have set up the necessary infrastructure and processes<br \/>\nbefore getting access to the data. Then, yearly audits are conducted to monitor<br \/>\ncompliance with the above restrictions.<\/p>\n<p>This is an extremely restrictive data sharing setup! It massively reduces the<br \/>\nincentives for recipients to do anything inappropriate. A breach of contractual<br \/>\nrestrictions would mean losing access to this very valuable data, which would<br \/>\nhave painful consequences for their competitiveness in the online search engine<br \/>\nmarket, and make them lose sunk investments.<\/p>\n<p>A lot of thought went into designing the anonymisation strategy. I supported the<br \/>\nCommission in performing threat modeling, listing potential attackers (along with<br \/>\ntheir goals, incentives, and capabilities), coming up with a criterion to define<br \/>\nthe target level of residual risk, and designing technical measures to meet this<br \/>\nbar and non-technical measures to further mitigate this residual risk. This<br \/>\nstrategy was then evaluated in multiple ways.<\/p>\n<ul>\n<li>The Commission published a <a href=\"https:\/\/ec.europa.eu\/commission\/presscorner\/detail\/en\/ip_26_825\">preliminary version<\/a> of the measures and<br \/>\n  encouraged the community to provide feedback and suggest changes. We carefully<br \/>\n  read and took into account the feedback we received<sup id=\"fnref:paid\"\/>.<\/li>\n<li>We performed data analysis and adversarial experiments on a sample of search<br \/>\n  data shared by Google<sup id=\"fnref:sample\"\/>.<\/li>\n<li>Google also performed adversarial analysis and submitted the results of their<br \/>\n  investigations. We then assessed these results and took them into account to<br \/>\n  improve the measures where needed.<\/li>\n<\/ul>\n<p>There were major differences in the approaches taken by us and by Google.<\/p>\n<ul>\n<li>We evaluated the technical measures against a risk framework which recognizes<br \/>\n  that a residual level of risk can remain after the technical measures. More<br \/>\n  precisely, our goal was to quantify the success of an attacker focusing on<br \/>\n  specific individuals or random records, or trying to perform re-identification<br \/>\n  with a high level of certainty at scale.<\/li>\n<li>Google focused on the worst-case records in the data, trying to identify rare<br \/>\n  edge cases that suggest end-user reidentifiability.<\/li>\n<\/ul>\n<p>Google made a number of scary-sounding claims in the press, in particular<br \/>\nclaiming to have re-identified users in \u201cless than 2 hours\u201d. There are many of<br \/>\ncaveats to this claim: they ignored non-technical measures, they threw more<br \/>\nresources at the problem than would ever be realistic for a data recipient,<br \/>\ntheir claims are based on the preliminary measures, they largely didn&#8217;t validate<br \/>\ntheir claims nor quantified their certainty level, and so on.<\/p>\n<p>Most of what they found was compatible with our risk framework. The technical<br \/>\nmeasures are not supposed to bring the risk to zero, so it is not surprising<br \/>\nthat one might find a small number of re-identifiable records. <\/p>\n<p>Still, whenever their experiments identified issues that suggested that the risk<br \/>\nwas beyond the residual level set in our framework, we adapted the measures: for<br \/>\nexample, we excluded all sponsored results from the dataset, used much larger<br \/>\ngeographic regions for location metadata, and increased the metadata threshold.<\/p>\n<p>Google has 6 months to implement the technical measures and finalize the<br \/>\nprocesses for data access; competing search engine providers could start<br \/>\nreceiving data in early 2027. That being said, I expect that Google will<br \/>\ncontinue resisting sharing valuable data with competitors in any way they<br \/>\ncan\u00a0\u2014\u00a0be it in court or through lobbying efforts to the media, regulatory<br \/>\nspaces, and professional communities.<\/p>\n<p>Meanwhile, the Commission will keep a close eye on the process, and help oversee<br \/>\nthe finalization of implementation details. It has also planned regular reviews<br \/>\nto check if the measures are effective (both from a competition and privacy<br \/>\nstandpoint) and take into account any new developments. This is probably not the<br \/>\nlast you hear of this!<\/p>\n<\/p><\/div>\n<p><a href=\"https:\/\/desfontain.es\/blog\/google-search-dma-data-sharing.html?utm_source=tldrnewsletter\">Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>In Europe, the online search engine market is very concentrated: Google Search has had around 90% of the market share for over a decade. This gives Google access to a massive amount of data about what people search for, what they click on, what modules they interact with on the page, and so on. This [&hellip;]<\/p>\n","protected":false},"author":16,"featured_media":23919,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[143],"tags":[],"class_list":["post-23918","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai"],"_links":{"self":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23918","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/comments?post=23918"}],"version-history":[{"count":0,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23918\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media\/23919"}],"wp:attachment":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media?parent=23918"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/categories?post=23918"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/tags?post=23918"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}