CMA Q1 2024 update report on implementation of the Privacy
Sandbox commitment
April 2024

CONTENTS
Summary .................................................................................................................... 2
Dashboard.................................................................................................................. 4Context and framework of our assessment ................................................................ 5
Overall competition concerns .................................................................................. 6
Potential concerns and current views on the individual Privacy Sandbox tools.......... 7
Showing relevant content and ads .......................................................................... 8
Measuring digital ads ............................................................................................ 30
Strengthening cross-site boundaries ..................................................................... 46
Fighting spam and fraud on the web ..................................................................... 65
Limiting covert tracking ......................................................................................... 70
Other updates covering the reporting period ............................................................ 79
Update on testing and trialling ............................................................................... 79
Actions and conclusions of the Monitoring Trustee ............................................... 80
Technical Expert ................................................................................................... 81
Engagement with market participants ................................................................... 81
IAB Tech Lab – Privacy Sandbox Fit Gap Analysis for Digital Advertising ............ 88
Stakeholder engagement ...................................................................................... 89
Engagement with the ICO and international authorities ........................................ 89
Next steps ................................................................................................................ 90
Contact details ......................................................................................................... 90
Annex 1 – current proposals in the Privacy Sandbox ............................................... 91
Annex 2 – context and framework of our assessment .............................................. 941

Summary
1.

This report sets out the CMA’s updated views on the issues we identified in
our January 2024 report concerning Google’s proposed Privacy Sandbox
changes (see Annex 1). Our analysis is based on the framework forassessment set out in the legally binding Commitments that Google made in
February 2022 to address competition concerns relating to its proposals to
remove third-party cookies from Chrome. The January 2024 report set out ourprovisional views on the impact of the Privacy Sandbox on competition,
publishers and advertisers and user experience.

2.

We outline Google’s response to the concerns we identified in that report andthe steps it is taking to resolve pending issues. We have also considered thefeedback received from market participants on these points. We haveincluded a summary of this feedback in the sections below.

3.

This report also incorporates the preliminary assessment of the Information
Commissioner’s Office (ICO) on the privacy and data protection impacts of thePrivacy Sandbox. Having consulted with the ICO, we set out our current viewson these concerns for each of the APIs.

4.

Although there are a number of concerns to work through, based on theavailable evidence, we consider that from 1 January 2024 to 31 March 2024
(the relevant reporting period), Google has complied with the Commitments.
This means that in our view Google has followed the required process set out
in the Commitments and is engaging with us (and the ICO) to resolve ourremaining concerns ahead of third-party cookie deprecation. However, further
progress is needed by Google to resolve our competition concerns ahead ofdeprecation.

5.

We will continue to work with Google to resolve our concerns1 between now
and the point at which Google triggers the Standstill Period. 2 We will provide
an update on progress in our next update report.

6.

Testing of the Privacy Sandbox tools is also currently underway. The test
results will form part of a wider evidence base that we will use to assess the1

Paragraph 17.a.ii of the Commitments enables us to raise issues with Google, and for Google to work with the
CMA without delay to seek to resolve concerns raised.
2
Under paragraph 19 of the Commitments, Google must allow for a Standstill Period of at least 60 days before
third-party cookies can be removed. This period can be extended to 120 days.

2effectiveness of the Privacy Sandbox. The test period runs until the end ofJune this year.
7.

Given the time needed to resolve outstanding issues and take account of
testing results, we have agreed with Google that there should be a limiteddelay to third-party cookie deprecation. Subject to resolving our remaining
competition concerns, Google is now aiming to proceed with third-party cookie
deprecation starting in early 2025. Under the Commitments, it is for Google todecide when the Standstill Period is triggered.

8.

We encourage market participants taking part in testing to submit their results
directly to us by the end of June deadline. We also welcome any additional
feedback from stakeholders on the concerns identified in this report. Ourcontact details are included at the end of this report.

3

Dashboard
Dashboard: summary of CMA view on current position, January-March 2024
Relevant sectionof Commitments

Compliance

Level of focus
by CMA 3•

D - Transparency
and consultation
with third parties

CompliantHigher focus••
E - Involvementof the CMA in the
Privacy Sandbox
proposals

F - Standstill
before theRemoval of ThirdParty Cookies

G - Google’s useof dataCompliantCompliantCompliantHigher focus•

CompliantMedium focus•

Focus on Google’s
internal data control
systems (particularly antiabuse activities andparagraph 26 data use)
Work to ensure thatnecessary data use
protections are fully
implemented well inadvance of third-party
cookie deprecation
Continued engagementwith Google aroundattestation andenrolment, design
decisions (including
Related Website Sets,
Protected Audience API,
Attribution Reporting
API), and governancefollowing third-party
cookie deprecation
Further testing Google’s
internal decision-making
process, particularly at
key decision points.
Incorporation of market
commentary and testing
feedback
Applying technicalknowledge to monitoring
artifacts and logs

•

•

•

I - Reporting andcompliance

Compliant

Lower focus

Encouraging testing andtrialling by Google andother market participants
Engaging on design
issues including
approach to Related
Website Sets, Protected
Audience API and
Attribution Reporting API
Preparing for the
standstill, including byidentifying remaining
competition concerns
and through testing andtrialling•

H - Nondiscrimination

Engagement with Google
and market participantson the development of
individual proposals (e.g.
Protected Audience API)
Following up on the
recently publishedupdate to our guidanceon testing•
Medium focus

Medium focus

Summary of planned
next steps

Key actions during period•

Completion of regularmonitoring report(s)

•

•
•

•

•

•

•

•

•

Engaging with Google
and other market
participants to resolve
concerns relating to thedevelopment of thePrivacy Sandbox tools
Following up on the
recently published update
to our guidance on testing
Engaging with Google
and other market
participants to resolve
concerns relating to thedevelopment of thePrivacy Sandbox tools
Encouraging testing andtrialling by Google andother market participantsand engaging with market
participants that intend to
test
Continuing to prepare forthe standstill, including
through resolving
remaining competition
concerns and throughtesting and trialling (seeabove)
Resolving additionalquestions regarding
Google’s internal data
control systems (with aparticular focus onparagraph 27)
Continuing to develop aframework for ongoing
monitoring following thirdparty cookie deprecation

Continuing engagementwith Google regarding
attestation and enrolment,
design decisions, andgovernance following
third-party cookie
deprecation
Continuing to monitor
artifacts and logs••

Note: this is a summary, so it cannot provide comprehensive details on all topics

4

Google to continue
demonstrating ongoingcompliancePreparing for next
monitoring report(s)Context and framework of our assessment
9.

We have set out below our current views on the proposed Privacy Sandbox
changes. The framework for our assessment, which is based on theDevelopment and Implementation (D&I) Criteria set out in Google’s
Commitments, is summarised in Annex 2.

10.

We have been consulting the ICO on the aspects of the Privacy Sandbox that
relate to matters of privacy and data protection. 4 The ICO has shared with us
its provisional views on the impact of the Privacy Sandbox on privacy
outcomes and compliance with data protection principles and the Applicable
Data Protection Legislation. For each of the APIs, it has summarised key
outstanding privacy and data protection concerns.

11.

We have considered the ICO’s views on privacy and data protection concerns
and incorporated these into our report for each of the APIs in the section
below. An overview of the ICO’s approach to reviewing the Privacy Sandbox
tools is included in Annex 2.

12.

The CMA-ICO joint statement on competition and data protection explores theintersection between our regimes. 5 Both this joint statement as well as the
ICO’s Opinion on data protection and privacy expectations for online
advertising proposals dated 25 November 2021 (2021 Opinion), 6 note that
the CMA and ICO will work closely to assess the Privacy Sandbox, with aview to supporting positive competition and privacy outcomes in online
advertising markets. In the Privacy Sandbox context, it may be the case thatspecific examples of Google interventions to improve alignment with dataprotection principles and the Applicable Data Protection Legislation havenegative impacts on some ad tech firms, and advertiser and publisher
outcomes. We are mindful of this risk and the need for careful consideration ofthese issues so that competition and data protection objectives are promoted
overall to the benefit of consumers.

3 While all aspects of the Commitments are important, this column refers to the relative priorities of the CMA, andwhich have required a greater focus, during the course of the reporting period.
4
See paragraph 18 of the Commitments.
5
CMA-ICO joint statement on competition and data protection law dated 19 May 2021.
6 See the 2021 Opinion.

5Overall competition concerns
13.

The January 2024 report identified a series of areas that could raisecompetition concerns, which relate to the design of the individual the APIs.
Since the last report was published, we have received further submissions
from Google on some of the concerns and additional views from stakeholders,
including on new concerns identified. Our updated views on each tool basedon this feedback are set out in the next section.

14.

In addition, we set out in our January 2024 report several key concerns that
Google will need to resolve ahead of third-party cookie deprecation:(a) Ensuring that Google does not design, develop or use the Privacy
Sandbox tools in ways that reinforce the existing market position of
its advertising products and services, including Google Ad Manager(GAM). GAM is Google's integrated ad server and supply side platform(SSP), accounting for more than 90% of the display ads served in theUK. 7 For example, we set out our concerns on GAM’s proposed approachto Protected Audience auctions in the section below. We are continuing todiscuss with Google how these concerns could be resolved.
(b) Clarifying the longer-term governance arrangements for Privacy
Sandbox. Google currently retains significant discretion over how Privacy
Sandbox works, develops over time, and the conditions for using Privacy
Sandbox (e.g. requiring attestations). This creates a risk of selfpreferencing or of the perception of self-preferencing. We are continuing
to engage with Google as it works to develop and refine a governancemodel for Privacy Sandbox. Our current view is that the model should
ensure that decisions are consistent with the Development and
Implementation Criteria set out in the Commitments, include elements of
independent decision-making, support transparency and provide
opportunities for stakeholder engagement.

15.

7
8

In addition, we are discussing with Google what further restrictions may be
applied on Google's use of first-party data to target and measure ads on
Google's owned and operated (O&O) inventory. 8 We are conscious of therisk that ad spend could move away from open display and into O&O

See page 270 of the CMA’s Online platforms and digital advertising market study dated 1 July 2020.
The Commitments already impose some restrictions (see sections G and H).

6inventory (or ‘walled gardens’) – depending on the overall impact of thePrivacy Sandbox changes.
16.

Finally, market participants have raised concerns that Google's aim to restrict
all cross-site tracking will harm third-party businesses seeking to provide
interest-based targeting and measurement in competition with Privacy
Sandbox. For example, concerns have been raised in the context of Google’s
Bounce Tracking Mitigations proposal in the section below. Although the
obligations under the Commitments relate specifically to the impact ofGoogle’s introduction of the Privacy Sandbox proposals and not Google’s
approach towards other market participants’ alternative technologies,
Google’s market position allows it to have a significant impact on the viabilityof alternative technologies that may compete with the Privacy Sandbox tools
following the removal of third-party cookies. 9 Both the Privacy Sandbox tools
and possible third-party alternatives will need to comply with applicable dataprotection legislation. 10 We are continuing to discuss this issue with Google.

17.

We have raised our competition concerns with Google following the processenvisaged under paragraph 17.a.ii of the Commitments. We have held aseries of meetings with Google to discuss these issues. Where we haveidentified concerns, this does not mean that we currently think the Privacy
Sandbox changes cannot go ahead, but it is important that the concerns areresolved, either through design changes, assurances from Google about
action it will take or refrain from, or other evidence which resolves ourconcerns.

18.

We will provide an update on how Google intends to resolve our concerns in
the report we will publish at the end of July 2024.

Potential concerns and current views on the individual Privacy
Sandbox tools
19.

This section is organised by the function or use case that Privacy Sandbox
APIs are intended to serve, and within each use case, by API. A summary of
the relevant use cases is included in Annex 1.

20.

We outline the concerns we have identified for each of the APIs based on theCommitments framework (D&I A – Privacy outcomes, D&I B – Digital9

See paragraph 4.324 of the Decision to accept commitments offered by Google in relation to its Privacy
Sandbox proposals dated 11 February 2022 (Commitments Decision).
10
See paragraph 4.325 of the Commitments Decision.

7

advertising, D&I C – Impact on publishers and advertisers and D&I D –User experience; see Annex 2).
Showing relevant content and ads
Topics API
Overview
21.

The Topics API is intended to enable interest-based targeting. 11 It uses an ondevice classifier model to generate a list of topics reflecting the user’s
interests based on their browsing history. The topics are selected from ahuman-curated, publicly available taxonomy, currently containing 469 topics. 12
Human curation is intended to ensure that topics are interpretable, forexample ‘Arts & Entertainment’, and that sensitive topics are excluded.

22.

The on-device classifier uses the site’s hostname, including subdomains. For
example, the site news.bbc.co.uk is assigned ‘news’ and the site
sport.bbc.co.uk is assigned three topics: ‘news’, ‘sport’ and ‘soccer’. 13 Theclassifier only considers the hostname.

23.

Every week, Chrome will calculate (locally on the user’s device) the top five
topics from the user’s browsing history of sites that use the Topics API thatweek (epoch). When callers (including third-party ad tech or advertisingproviders) call the Topics API, the API will return at random for the user up to
three topics in total from the top five topics for each of the last three weeks;
once a topic is selected for a week, user, and top-level site, it will remain
constant. Google selects ‘top’ topics, first based on their utility (‘high’ or‘standard’), and then by their frequency count. 14
Potential concerns

24.

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

11

An overview of the Topics proposal can be found here (accessed on 22 April 2024).
The taxonomy is listed on the Topics GitHub page here (accessed on 22 April 2024).
13
Accessed via chrome://topics-internals/ (accessed on 22 April 2024).
14
See Google Developer Blog on ‘Enhancements to the Topics API’ here (accessed on 22 April 2024).
12

8

25.

For the purposes of assessing the compliance of the Privacy Sandbox tools
with data protection principles and the Applicable Data Protection Legislation,
as defined in the Commitments, the ICO has drawn upon its 2021 Opinion
and its Update report into ad tech and real time bidding dated 20 June 2019(2019 Report). 15

Potential concerns
Google does not provide
sufficient clarity to individuals
regarding how their data isused by the Topics API.

Provisional CMA views based on ICO’s preliminary
assessment
We are concerned that the Topics consent user interface may notadequately inform users about how their personal data is used or
how the topics generated may be used for purposes wider thaninterest-based advertising (e.g. as determined by organisations
that decide to use the API).
To address this concern, Google has agreed to update the Topics
API consent interface and to strengthen developer guidance tohighlight the requirement to obtain purpose-specific consent prior
to calling the API.
We are awaiting the results of these updates.

Topics API makes cross-site
insights available to API
callers with no Googleimposed restrictions limiting
the purpose of topics data tointerest-based advertising
only.

The ICO’s 2021 Opinion 16 sets expectations that future proposals
must ‘clearly articulate specific purposes for processing […] anddemonstrate how [they] uphold the integrity of the purpose
limitation principle’.
Based on the ICO’s preliminary assessment, we are concernedthat topics data may be used for purposes outside that specified by
the API, and in so doing may harm the user and breach Applicable
Data Protection Legislation.
Google believes that the Topics API will primarily be used forinterest-based advertising. However, Google does acknowledge
that entities calling the API might use the data for other purposes.
Google views the risk to users in relation to potential harmful use
cases as low. However, in addition to agreeing to review the API’s
user transparency and developer guidance (see issue above),
Google is now exploring ways to monitor potential abuse of theAPI.
Once we receive further updates from Google on theseassurances, we will consider, after consulting with the ICO,
whether our concerns have been resolved.

Topics will be stored andaccumulated beyond thethree-epoch period (currently
three weeks).

Google has stated that the Topics API has a storage limit of threeepochs, with one epoch equivalent to one week (therefore equating
to a three-week period overall).
Google views three epochs as an appropriate amount of entropy toshare with API callers. It has reached this view after assessing the

15 See the 2019 Report and the 2021 Opinion.
16 See page 44 of the 2021 Opinion.

9Potential concerns

Provisional CMA views based on ICO’s preliminary
assessment
risk of re-identification on the part of a single API caller, finding thatthree epochs establishes a suitable level of difficulty for doing so.
The ICO’s 2021 Opinion states that new solutions should ensure
data is processed ‘for the minimum amount of time necessary’ inline with the data minimisation principle. 17 The ICO has also notedthat solutions should avoid ‘augmenting, matching or combining
personal data without strong justification, transparency andcontrol’. 18
Although the chosen epoch period may provide a proportionate
storage limitation limit for topics data where it is used for the
purposes of interest-based advertising, based on the ICO’s
preliminary assessment, we have concerns that API callers may
process data beyond this limit without providing the user with thetypes of strong justification, transparency and control that the ICO’s
2021 Opinion refers to thereby potentially breaching Applicable
Data Protection Legislation. This raises a corresponding risk ofharm.
To address these concerns, Google proposes to issue improved
developer guidance to communicate the responsibilities API callers
have regarding consent requirements. As regards identifiability,
Google is also exploring how governance and monitoring may
inform future API design.
We are awaiting Google providing further details of these plannedchanges to guidance and proposed governance measures.

The future changes to the
Topics API taxonomy could
introduce new privacy risks
without appropriate
mitigations.

We understand that Google’s privacy controls regarding
identifiability are constructed and informed by the granularity of thetaxonomy. We also understand it is Google’s view that increases tothe number of categories in the taxonomy may directly improveutility and revenue for API callers, pending additional evidence.
The ICO’s 2021 Opinion stated that with new initiatives,
organisations must consider ‘any new risks they introduce, andhow they will mitigate them before processing takes place’. 19 The
Topics API taxonomy is a key variable when assessing privacy risk
with this tool. We agree with the ICO that future utility-basedchanges to the taxonomy could introduce new privacy risks.
Currently, we are concerned that compensating privacy controls
will not be sufficiently considered, documented or implemented if
utility-focussed changes to the taxonomy are undertaken. Google
will need to ensure that users are put at the heart of the decisionmaking process as set out in the ICO’s 2021 Opinion expectations,which could potentially lead to breaches of the Applicable Data
Protection Legislation.
Google acknowledges the sensitivity of changes to the taxonomy.
An appropriate oversight and governance approach is underconsideration.

17 See page 45 of the 2021 Opinion.
18 See page 45 of the 2021 Opinion.
19 See page 44 of the 2021 Opinion.

10

26.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the following potential concerns under D&I B – Digitaladvertising and D&I C – Impact on publishers and advertisers. In thetable below, we also include our updated views on each of the concerns
identified based on further submissions from Google and other market
participants since our last report was published in January 2024. New
concerns raised by stakeholders during the reporting period are included at
the end of the table.

Potential
concerns
The Topics API is
likely todisadvantage
small ad techs
who have a more
limited ‘reach’and access totargetinginformationcompared tolarge ad techs.

CMA views in January 2024 report

Updated CMA views

Google’s view is that the three-topic
constraint applies equally to all adtechs and that ad techs are likely tosupplement topics with other (e.g.
contextual) signals.

Since the publication of our lastreport, we have received further
stakeholder feedback that thelimitations imposed by the Topics API
are not equal. Specifically,
stakeholders are concerned thataccess to the Topics API requires
certification (the process for which isgoverned by Google), and that GAM
will have broader information aboutuser topics compared to competitors
because it is embedded on mostsites.

We consider that the impact will vary
based on the degree to which an adtech relies on the Topics API as atargeting signal. Some ad techs may
have access to other sources of
information about a user (e.g. throughdata sharing arrangements, data on
logged in users or from Protected
Audience interest groupmembership). However, unequal
access to data is not a new problem,
it exists today for ad techs using thirdparty cookies.
The ‘reach’ problem is also not
specific to Privacy Sandbox; ad techs
with a larger reach have more
opportunities to use third-party
cookies. Privacy Sandbox means thatad techs have fewer options to extend
their reach by sharing information with
one another within the browser (e.g.
cookie syncing, fingerprinting andbounce tracking are all limited). That
does not stop them from sharing dataon the server side, although thisopportunity also exists today (e.g. via
controller-to-controller data sharing
agreements, data clean rooms orother means).

Our current view is that Google’s
certification process does not impose
unequal limitations on stakeholders.
We also consider that any information
advantage received by GAM as aresult of being embedded on mostsites is not exacerbated by the
introduction of the Topics API.
We therefore maintain our view that
unequal access to data is not a new
problem and that, compared to thestatus quo, small players are unlikely
to be disadvantaged as a result of theintroduction of the Topics API.

Therefore, compared to the statusquo, we do not consider that smaller
players are likely to be disadvantaged
with the introduction of the Topics
API.
Google will beless reliant on the

Sections G and H of theCommitments already impose some11

Our discussions with Google are
ongoing on this point.

Potential
concerns
Topics API thanother market
participants,
given its accessto first-party data.

Google mightadvantage itself
by manipulating
the Topics API
taxonomy which
it currently
controls.

CMA views in January 2024 report

Updated CMA views

restrictions on Google’s use of its
first-party data. The Monitoring
Trustee has a continuing role to playin verifying Google’s compliance withthe relevant sections of theCommitments.
We will consider whether additional
restrictions may be needed to resolve
this concern.
Google has told us it is developing
robust governance arrangements for
decision-making on issues relevant to
the development of the APIs. Google
has said that it remains interested instakeholder feedback on the future
governance of the taxonomy anddiscussion of how other industry
bodies can play a more active role indeveloping and maintaining it.
We consider that transitioning
ownership to an external, industry-run
group could resolve concerns that
Google might advantage itself by
manipulating the Topics API
taxonomy. The timing of such transfer
will need to be discussed further with
Google.

Google has informed us that it does
not exclude the possibility of involving
external bodies in the governance of
the Topics taxonomy in the long-term.
However, Google does not yet havenear-term plans to transfer
governance of the Topics taxonomy
to an external body.
We wait for Google to provide further
details on the governance framework
for the Topics API. Our evaluation of
the governance model will consider
whether the proposed approach will
adequately mitigate the risks to user
privacy that may occur as a result of
increasing the granularity of the
Topics taxonomy. As stated in our
D&I A assessment of the Topics API
above, any utility-focussed changes
to the taxonomy will need to beaccompanied by compensating
privacy controls.

The level of
granularity of thetaxonomy may
have an impact
on the utility of
the API for
publishers andadvertisers andon publishers’
first-party data
strategies.

Given the diversity of actors in the adtech ecosystem, we anticipate that
discussions on the most appropriate
size and level of granularity for Topics
taxonomy will continue. Striking theappropriate balance will be a key
question for the future governancemodel.

Our views remain unchanged, and we
await Google providing further details
on its proposals for the future
governance model.

Classification
based only on
hostname meansthat sites
covering many
topics contribute

Google’s Q3 2023 update reportstates that it ‘previously considered
offering functionality to classify sites
into topics based on page content andmade the decision not to move

We maintain our view thatclassification based on hostname is areasonable trade off.

12

Our evaluation of the governancemodel will consider whether the
proposed approach will adequately
mitigate the risks to user privacy that
may occur as a result of increasing
the granularity of the Topics
taxonomy. As stated in our D&I A
assessment of the Topics API above,
any utility-focussed changes to thetaxonomy will need to beaccompanied by compensating
privacy controls.

If we become aware of new proposals
to develop the classifier model inPotential
concerns
less useful
information thanniche sites. For
example,YouTube is
assigned ‘Online
Communities’,‘TV & Video’ and‘Arts &
Entertainment’.

Publishers areconcerned that
their sites could
be misclassified
or not assigned a
topic and want tocontrol the topics
that areassociated with
their sites.

Allowing sites toselectively
contribute to auser’s topics
could create afree-riding
problem, i.e. thatsome ad techs
can choose toobserve topics
without
contributing to

CMA views in January 2024 report

Updated CMA views

forward based on privacy and security
concerns’.

future, we will evaluate these toensure that any potential risks to user
privacy are addressed.

We are aware of proposals frommarket participants that aim tobalance privacy and security
concerns against improving utility, forexample by using permissions
policies. 20 Our current view is thatclassification based on hostname is areasonable trade off, but we are open
to proposals to develop the classifiermodel in the future.
Google has expressed concern about
the risk of misclassification, e.g.
where the Topics API classifierassigns a topic that the site ownerconsiders to be incorrect. 21 Our
current view is that Google’s
response resolves the
misclassification concern and agreewith Google’s view that allowing site
owners to control classification risks
incentivising site owners to game thesystem.

Google’s original response to thisconcern stated that ‘the specific sitesthat are misclassified are no moreand no less harmed by this than any
other sites. This is because a site’scontextual information will always be
available for auctions on their site,which would provide comparable
information to the correct topic, evenin the case of misclassification’.

We are aware of specific stakeholder
concerns relating to SSP ‘free riding’and feedback on the way Google’s
Q3 2023 report addressed theissue. 22 We have raised the concern
with Google and will update in our
next quarterly report.

Google has said that if an API caller
never invokes the functionality for thebrowser to observe topics, the caller
will never receive any topics. Thismeans that there is no incentive forcallers not to contribute to a user’s setof topics.

Since the publication of our lastreport, we have received further
stakeholder feedback on how themisclassification issue can be
reduced. Stakeholders haverequested a mechanism throughwhich a classification can bereviewed, or at least some additionaltransparency on how the classification
model works and determines its
categories. We have relayed thesesuggestions to Google.

Our current view is that allowing
selective observation of a user’s
topics is a reasonable way ofmaximising the utility of the API, as it

20

See for example, issue #224 on the Topics repository on GitHub here (accessed on 22 April 2024).
See page 9 of Google’s Q2 2023 progress report (accessed on 22 April 2024).
22
See issue #92 on the Topics repository on GitHub here (accessed on 22 April 2024).
21

13

Potential
concerns
the set of topics
stored on theuser’s device.

CMA views in January 2024 report

Updated CMA views
allows callers to avoid filling the user’s
top five topics with items that are
generic or commercially irrelevant.
However, we are aware that this may
have a negative impact onadvertisers, as the SSPs they workwith could selectively use topics tomisrepresent user cohorts that arelower value (e.g. those that use Made
For Advertising (MFA) and pirate
sites).
Our understanding is that API callers
can mitigate this concern by taking
commercially reasonable measures toprovide advertisers with the URLs of
pages where their ads were placed.
We are keen to hear further feedback
from stakeholders who believe they
may be affected by this issue.

A site’s decision
to support (or not
to support) the
Topics API
should not
influence its
Google Searchranking.

Google has confirmed to us that
Google Search will not use a site’s
decision to opt-out of the Topics API
as a ranking signal. 23

We are awaiting Google’s responseon this point.

We consider that Google’s assurance
that a site’s decision to support (or not
to support) the Topics API will not
influence its Google Search ranking
should also extend to the other
Privacy Sandbox tools.

The Topics API
relies on user
consent. If
consent rates are
low such that
Topics areunavailable, there
may be knock-on
effects forinterest-basedtargeting andpublisherrevenue.

We recognise that Google needs torequest user consent for the Topics
API to operate. We anticipate that the
Chrome-facilitated testing period inearly 2024 will provide further
information about Topics availability.

Stakeholders continue to express
concern about the availability of the
Topics API if consent rates are low.
We expect that the Chrome-facilitatedtesting period will provide further
information about Topics availability
and its potential impact on revenue.
As noted in the D&I D section below,
we are continuing to engage with
Google about the user choice andcontrols for the Topics API to ensurethat users can make effective
choices.

The one-weekepoch meansthat topics arelikely to be out of

Although reducing the epoch length
could increase utility for advertisers,
given the likely impact on privacy, on

As noted in the D&I A section above,
Google defined the Topics epoch
after assessing re-identification risk.

23 See page 34 of Google’s Q4 2022 progress report (accessed on 22 January 2024).

14

Potential
concerns
date, with
implications forshowing ads
where the user
may already haveacted on theirinterest (e.g. bymaking apurchase).

CMA views in January 2024 report

Updated CMA viewsbalance, we currently consider that anepoch of 7 days may be appropriate.

Therefore, we currently consider the
one-week epoch to be reasonable.

Topics API will bedifficult to test
until it is stableand fully
implemented in
Chrome.

N/A

We have received new concerns fromad techs stating that they cannot test
the Topics API until it is stable andfully implemented in Chrome. While
we are aware that the Topics API wasshipped in Chrome M115 (on 1
August 2023), stakeholders have said
that the updated Topics taxonomy
only became available on the majorityof traffic in mid-November 2023. They
therefore seek greater assurance thatthe taxonomy will not change in order
to meaningfully test it.
We consider it reasonable forstakeholders to expect that the Topics
taxonomy will change over time. We
anticipate that Google’s forthcoming
proposals for the future governance of
the Topics API will give stakeholders
sufficient time to plan and provide
input on the design of the API before
testing and deploying it.

27.

As regards the application of D&I D – User experience, although there havebeen some positive developments in the design of user controls for the Topics
API, e.g. users can review the topics assigned to them and proactively add orblock topics, concerns remain about the transparency of the information
presented to users via the consent dialogue box and the extent to which users
adequately comprehend and engage with the Topics choice.

28.

We are continuing to engage with Google on resolving these concerns andasking it to take measures such as further user research and testing toenhance information transparency and user engagement with the dialogue
box. Additionally, while repeated consent pop-ups, e.g. surfaced uponinteracting with every publisher site, could lead to prompt fatigue and degradeuser experience, we consider that providing users with adequate opportunity
to revisit their Topics API preferences is important for effective decisionmaking. Therefore, we are exploring potential platforms for prompting users toreview their preferences with Google.
15

Summary
29.

Google needs to resolve our concerns for the Topics API, and it has agreed totake the following steps:(a) Update the Topics API consent user interface to provide sufficient clarity
to individuals on how their data is used by the Topics API.
(b) Strengthen developer guidance to highlight the requirement to obtainpurpose-specific consent prior to calling the API.
(c) Implement ways to monitor potential abuse of the Topics API, particularly
where it is used for purposes other than interest-based advertising.
(d) Explore how governance and monitoring may inform the future design of
the Topics API.
(e) Ensure there is adequate governance of the taxonomy. We remain
concerned that Google retaining governance of the taxonomy creates arisk of distorting competition between Google and other market
participants. We want Google to set out a plan, with a timeline, toreassure market participants that decision-making on issues relevant to
the taxonomy will be transparent and accountable to stakeholders. This
could include transferring governance to an independent third party, withclear Terms of Reference to ensure that the taxonomy evolves in a waythat balances utility for interest-based targeting with minimising reidentification risks.

30.

In addition to these steps, our current view is that Google should:(a) Surface the Topics dialogue box periodically and consider approaches,
based on user research, to remind or prompt users to revisit other Privacy
Sandbox settings.

Protected Audience API
Overview
31.

The Protected Audience (PA) API (formerly known as FLEDGE) is primarily
intended to support remarketing and other custom audience use cases. 24

24

For more information on PA API and how it works see Google Developer Blog on ‘Protected Audience API’
here (accessed on 22 April 2024).

16

Remarketing is the practice of serving targeted ads to individuals based on
their activity on an advertiser’s website. PA allows sites to assign users tointerest groups. The browser stores information about interest groups
including the name of the interest group, the group’s owner, and information
about the interest group’s configuration.
32.

PA has several components, intended to work together to facilitate privacy
preserving remarketing. Google has published a timeline showing the statusof each component. 25 The timeline is high level, indicating the quarter in which
Google expects the feature to be available.
Potential concerns

33.

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

Potential concerns
At third-party cookie
deprecation, PA will be
deployed without a numberof key technical privacy
controls.

Provisional CMA views based on ICO’s preliminary
assessment
We understand that a range of planned Privacy Enhancing
Technologies (PETs) will be required no sooner than 2026. These
include: Trusted Execution Environments (TEEs) 26 for Key/Value
servers; Fenced Frames; a replacement for event level reporting;and a solution to Navigation URL leaks. Based on the ICO’s
preliminary assessment, we are concerned that the absence of
these features will allow API callers to join user activity across thesites they visit.
We understand it is Google’s current position that industry adoptionof the API is a priority: PA is already a significant change to thirdparty cookie-based remarketing and, if planned PETs are too
rapidly introduced, it could have a significant impact on theecosystem and adoption of the API. While all key dates anddelivery are hard to forecast, Google has said that it is working ondelivering privacy mitigations for known cross-site tracking risks.
Google has said that it plans to outline how the implementation ofprivacy-related controls will be accounted for in a wider, to-beproposed governance process.
Without sufficient controls, in the short term, the ICO has
expressed concern that PA will not mitigate key privacy risks
identified. Longer term, we await sight of Google’s proposed
governance process to determine if it provides sufficient assurance

25

See Google Developer Blog on ‘Status of pending Protected Audience API capabilities’ here (accessed on 22
April 2024).
26
Google describes Trusted Execution Environments (TEEs) as ‘a special configuration of computer hardware
and software that allows external parties to verify the exact versions of software running on the computer. TEEs
allow external parties to verify that the software does exactly what the software manufacturer claims it does—nothing more or less.’ See Google Developer Blog on Aggregation Service here (accessed on 22 April 2024).

17

Potential concerns

Provisional CMA views based on ICO’s preliminary
assessmentthat planned controls will be delivered as currently outlined in the
product roadmap.

The delegation of Interest
Group (IG) creation to third
parties will not be transparent
to the user.

After consulting with the ICO, we are concerned that site owners
may not clearly disclose who is processing the user data and the
purpose for which it is used, including obtaining valid consent fromvisitors. Moreover, we believe that the current UX does notadequately inform users that a range of parties beyond the firstparty site may be processing their data, potentially in combination
with third-party data collected outside the site they are currently
visiting. Google is considering updates to the UX to address theseconcerns, including undertaking further user research.

Permissionless delegation ofIGs will impact transparency,
fairness and lawfulness.

We understand that site owner permissions for creating IGs(joinAdInterestGroup) are currently set to ‘allow all’ by default.
Based on the ICO’s preliminary assessment, we are concernedthat with these permissions site owners will not have full control orvisibility of the parties processing users’ personal data. As a result,the ICO is concerned that third parties creating IGs will undertake
data processing without sufficient transparency being provided tothe user and without an appropriate lawful basis.
We understand that Google has defaulted site permissions to‘allow all’ to facilitate successful testing and adoption of the PA
API. In Google’s view, the requirement for site owners to makechanges to their sites would create an unwanted barrier toadoption while transitioning from third-party cookie-based
remarketing.
Google has said it has undertaken market research that shows site
owners are concerned about leaking their audiences via third
parties operating without explicit permissions, and that site owners
would require 12 months’ notice to prepare for a change in default
permissions. We understand that Google will enact this change
based on advertising industry feedback no earlier than 2025;
however, no set timeline is given.
We view this as a risk that will persist until at least the second halfof 2025.

Third-party/cross-site data
will be combined with firstparty data in the PA IG.

We understand that k-anonymity controls (previously in place toprevent microtargeting in early iterations of the proposal formerly
known as FLEDGE) no longer apply to IGs. As a result, it ispossible to create IGs bespoke to individuals rather than someminimum number or people. Further, it is also possible to store
deterministic identifiers as part of the IG and use them in the ad
selection process. This may lead to a situation where cross-sitedata and profiles from third-party sources can be leveraged in PA.
The ICO is concerned that combining first- and third-party data in
the PA API will not address a range of data privacy concerns
potentially leading to non-compliance with Applicable Data
Protection Legislation. The ICO, for example, is concerned that:•sufficient information will not be presented to users toensure transparent and fair processing; and18

Potential concerns

Provisional CMA views based on ICO’s preliminary
assessment• excessive profiling will occur that exceeds the API’s
remarketing use case. We share this concern.
Google has acknowledged that it is possible to leverage third-party
data in PA’s ad selection process. In the context of Google’s stated
API goal of preventing cross-site reidentification, Google’s view isthat, when all planned PETs are implemented post-2026, noadditional cross-site information is leaked. Put another way, for athird party with access to audience profiles, a future iteration of PA
will not leak cross-site data to enable additional
enrichment/augmentation of profiles.
Google has also agreed to update its developer guidance to stressthe importance of transparency requirements when using the API.
Further, Google is exploring whether it is possible for API callers toflag when an IG utilises cross-site data and how this information
could be surfaced to users.
We await Google’s updated developer guidance and further
information on possible changes to PA UX to understand if thisconcern is resolved.

That utility-focussed updates
to the API are undertaken
without sufficientconsideration for privacy
impacts.

Across the development and testing of the PA API we haveobserved a range of changes made to the original API design. The
majority of significant updates to the proposal have been focussed
on improving utility (for example, removing k-anonymity controls forIGs). Based on these observations, we are concerned that privacy
is not appropriately considered by Google. As a result, over time,
there is a risk that the PA API will be evolving in a direction
potentially leading to non-compliance with Applicable Data
Protection Legislation.
In response, Google has said that the API must offer sufficientutility to ensure adoption. However, Google has acknowledged that
there is a risk that too much compromise in this area would
undermine a core aim of the project.
To address this concern, Google is developing governancearrangements to ensure privacy is correctly balanced against utility
and the immediate priority of adoption.
We await Google’s updated approach to governance.

34.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the following potential concerns under D&I B – Digitaladvertising and D&I C – Impact on publishers and advertisers. In thetable below, we also include our updated views on each of the concerns
identified based on further submissions from Google and other market
participants since our last report was published in January 2024. New
concerns raised by stakeholders during the reporting period are included at
the end of the table.

19

•

PA Concerns

Potential concerns
IG design currently
excludes traffic shaping,
the practice of filtering or
curating bid requests toprioritise DSP responses
based on some
information about the bid
opportunity.

CMA views in January 2024
reportGoogle has responded to thetraffic shaping concerns byrecommending that SSPs canuse caching or DSPs canmake increased use ofTrusted Key/Value servers toaddress these use cases. 27
We recognise that traffic
shaping contributes to efficientuse of ad tech resources.
Some ad techs areconstrained by limits on thenumber of queries per second
they can process, and traffic
shaping can help them toprioritise bids.
We are keen to hear further
stakeholder feedback onwhether Google’s
recommendation addresses
this use case.

PA does not currently
support effective IG
delegation, (i.e. where
one party assigns a user
to an IG and allows
another party to bid onthat IG in a PA auction).

PA auctions only allow
buyers to bid on one IG.
Buyers cannot combine
IGs, for example to bid
when a user is a memberof both IG A and B.

Updated CMA views
We remain concerned that a lack ofeffective traffic shaping could distortcompetition between DSPs with alarger capacity to respond to bid
requests, which may therefore beless reliant on traffic shaping, andthose which rely heavily on traffic
shaping.
Given that Google’s DSPs have alarge capacity to respond to bid
requests, we are therefore
concerned that the lack of traffic
shaping could favour Google’s DSPs.
Since the publication of our lastreport, stakeholders have also raised
concerns that caching is complex to
implement, creates a dependency on
SSPs and hides the ‘true’ shape of
traffic from DSPs.
We have shared this feedback with
Google and await its response.

Google believes that its
implementationaccommodates all use casesand states that it should ‘build
additional support to makesome use cases flow moresmoothly in the future’. 28

Google has repeated its view that PA
currently supports contract-based
approaches to IG delegation. We
have not received any updates on
the timeline for the ‘additional
support’ referenced in Google’s Q32023 feedback report.

We have raised the issue with
Google and are seeking
clarification on the timeline.

As stated in the D&I A section above,
IG delegation should be transparent
to the user.

Google has stated that PA
does not support this type ofad targeting, and thatcombining IGs is incompatible
with PA’s current privacy
model. 29

We are aware of stakeholder
comments that it would be possible
for DSPs and ad servers to develop
joint buying/selling logic. We are
exploring whether this could allow adservers and DSPs with a strong
relationship (e.g. those owned by
Google) to work around therestrictions in PA. 30

We currently agree with theapproach to restricting
remarketing and other custom
audience use cases to one IG

27

See ‘Traffic shaping’ in Google’s Q2 2023 feedback report (accessed on 22 April 2024).
See ‘Publisher Interest Group Control’ in Google’s Q3 2023 feedback report (accessed on 22 April 2024).
29
See issue #818 on the FLEDGE repository on GitHub here (accessed on 22 April 2024).
30
See Issue #1028 on the FLEDGE repository on GitHub here (accessed on 22 April 2024).
28

20

Potential concerns

CMA views in January 2024
reportand will discuss ourassessment of privacy issues(D&I A) in relation to the PA
privacy model further in a
future quarterly report.

Updated CMA views

PA auctions allow one ad
auction per placement
slot and each slot istreated independently.
This creates challenges
of competitive ad
separation, i.e. ensuringthat ads for competingbrands do not appear inad slots on the same
page.

Competitor ad separation is an
important industry use case.
Stakeholders have suggested
adding ‘whole page’ 31 or‘multi-tag’ 32 auctions to PA.
Google has identified
increased complexity andprivacy risks associated withthis feature.

Google has argued that competitor
ad separation is not entirely possible
in today’s digital advertising
ecosystem. Google has said that,
presently, direct sold ad serving by
the publisher is the only reliable
method for ensuring competitor ad
separation. 33

PA auctions offer limited
support for negative
targeting, i.e. excluding
some users from seeinga particular ad.

Our understanding is that
Google is considering thefeature request, and we willcontinue to monitor the issue.
We are keen to hear further
stakeholder feedback, andsuggestions for other designchanges that could help toaddress the issue.

Discussions on negative
targeting capabilities in PA are
ongoing. Google has
introduced functionality inresponse to stakeholder
requests. However, somestakeholders continue toexpress concern that this does
not fully address their cases.
The ecosystem continues topropose improvements andGoogle has indicated that it

31

We recognise that competitor ad
separation could have contractualand revenue implications for the adtech ecosystem. We are also awarethat other browser vendors haveproposed implementations that allow
for coordinated ad placement via
multi-tag support in the scoreAds
function. 34
We await more detail on Google’s
response to the feature requests,
and its proposed solutions or
mitigations to the privacy andsecurity challenges that Google has
previously identified.
Google has addressed the majorityof stakeholder concerns on thisissue. We are following the ongoing
discussions related to the potential
facilitation of excluding an entire IG,
as opposed to filtering ads within thatgroup 36 and other alternative
methods. 37

See issue #98 on the FLEDGE repository in GitHub here (accessed on 22 April 2024).
See issue #846 on the FLEDGE repository on GitHub here (accessed on 22 April 2024).
33
See ‘Competitive Separation’ in Google’s response to the IAB Tech Lab’s report here (accessed on 22 April
2024).
34
See ‘API difference highlights’ in the privacy-preserving-ads repository on GitHub here (accessed 22 April
2024).
36
See issue #896 in the FLEDGE repository on GitHub here (accessed on 22 April 2024).
37
See Issue #1096 on the FLEDGE repository on GitHub here (accessed on 22 April 2024).
32

21

Potential concerns

CMA views in January 2024
reportwill take some proposals on
board. 35

Updated CMA views

We will continue to monitor theissue, noting that we do not
expect the Privacy Sandbox
tools to replicate all thefunctionality currently available
to ad techs using third-party
cookies.
GAM will not participate
in PA component
auctions unless it is the
top-level PA seller. Thismeans that publishers
have to use GAM in orderto access AdX demand.

Our understanding of thecurrent approach is that GAM
will only participate in PA
component auctions where
GAM also run the top-level PA
auction. We have identified
this as a priority area for
Google to address. We arealso exploring whether parties
other than the publisher ad
server should be able to run
the top-level PA auction. Ourcurrent understanding is thatsome ad server functionality(e.g. pacing) may not be
available unless the ad server
runs the top-level PA auction.

Google has confirmed ourunderstanding that GAM will only
participate in PA component auctions
where GAM also runs the top-level
PA auction. Google’s position is thatrunning both the component and PA
auctions enables the ad server toprovide functionality (e.g. pacing,
forecasting) for publishers.
Our understanding is that publishers
wanting to access demand from
Google’s SSP in PA auctions would
therefore have to choose GAM as
the top-level PA seller. We areconcerned that this could extend
GAM’s market power in the publisher
ad server market to limit competition
among parties wishing to run PA
auctions as top-level seller.
We are aware that somestakeholders have expressed adesire for GAM to share information
about the winning contextual bid witha third party, allowing that third party
to run the top-level PA auction. 38
We are continuing to discuss theseconcerns with Google. This is a highpriority area for us to resolve.

PA reduces theinformation available topublishers compared withthe status quo.
Publishers will only
receive information on
the top-level winning bid,with no visibility over35
38

PA is currently not designed toprovide publishers full control
over auction dynamics anddata related to theiradvertising inventory. This
design raises concerns that
GAM, or any other top-level
seller will receive more data
and understanding of theGoogle is considering options toprovide view and click information tobuyers, in response to stakeholder
feedback. Our understanding is thatad techs could use this information to
optimise their approach to PA
auctions. We encourage theFor example, see issue #896 in the FLEDGE repository on GitHub here (accessed on 22 April 2024).
See Issue #10690 here and #9481 here on the Prebid repository on GitHub (accessed on 22 April 2024).

22

Potential concerns
component auction
winners.

CMA views in January 2024
reportrelative value of impressions
than either publishers orcomponent sellers.
We are exploring this further
with Google and other market
participants. Several
stakeholders have proposedthat the publisher’s top seller
should be able to share all thedata (beyond price) with any
component sellers the
publisher may select.

Information on PA
component auction
winners will be visible to
GAM, raising concerns
about unequal access to
information.

Our current understanding isthat each PA component
auction returns the outcome ofthe scoreAd function to the
top-level auction.
Google has informed us that
information on individualcomponent auctions neverleaves the auction worklets.
We are currently discussing
with Google whether GAM hasaccess to information that is
not shared with the publisher.

Updated CMA views
ecosystem to provide feedback on
Google’s proposed design. 39
As regards the concerns about
GAM’s access to information which
would benefit Google’s services overother market participants, we areconsidering what further assurances
Google can provide to resolve thisconcern.

Google has told us that, based on its
commitments to the French
Competition Authority on the online
advertising case, 40 GAM in its role as
ad server is prohibited from sharing
bid data with any entity participating
in an auction, including GAM’s ad
exchange.
Furthermore, Google has explainedthat GAM’s ad exchange functionality
is prohibited from using third-party
SSP prices in order to optimise bids
in a way that third-party SSPs cannot
reproduce. However, Google has
said that GAM as an ad server canuse these bids for its ‘ad server
functionality’ (e.g. for computation of
the Minimum Bid to Win).
We are considering what further
assurances Google can provide toresolve this concern.

GAM proposes to use
machine learning todecide whether to triggera PA auction. This raises
concerns about a lack oftransparency for
publishers about how thesystem decides whether
to trigger a PA auction
and a lack of publisher
control.

GAM has told us that its
proposed model will optimise
for total publisher revenue
from all sources including
direct deals, AdX
programmatic auctions andrevenue from other SSPs.
GAM has clarified thatpublishers will have the option
to turn off the machinelearning feature when there
are other sellers who want toparticipate in the PA auction.

39

We are continuing to discuss thispoint with Google.

See Issue #957 on the Fledge repository on GitHub here (accessed 22 April 2024).
See Decision 21-D-11 regarding practices implemented in the online advertising sector dated 7 June 2021
(accessed on 22 April 2024).

40

23

Potential concerns

CMA views in January 2024
reportOur understanding is that theoption is for publishers toeither opt-in or out of themachine learning trigger.

Updated CMA views

We are keen to hear feedback
on whether this binary control
addresses publisher concerns.
Stakeholders have expressed
concern that machine learning
throttling could remove
discretion from the ad techecosystem. Some publishers
want to have the option to
trigger a PA auction, andaccess to the informationnecessary to decide whether
to trigger that auction.
We are focusing on GAM’s
approach to PA as one of our
top priorities and in-depth
discussions are ongoing. We
expect to be able to provide
further updates in our next
quarterly report.
URLs for loading scripts
into PA auctions musthave the same origin as
the IG owner.

Ad tech vendors commonly
host applications on separate
subdomains, moving these to
the same origin could incur
infrastructure costs andcomplicate reporting use
cases. Google has indicatedthat design changes are
possible, subject to resolving
concerns around the web
security model. 41

Google has indicated that designchanges are possible, subject toresolving concerns around the web
security model.
We will continue to monitor thisissue.

We will continue to monitor
this issue and welcome further
stakeholder feedback onprioritisation, i.e. is this acritical issue for the
ecosystem.

41 See issue #818 on the FLEDGE repository on GitHub here (accessed on 22 April 2024).

24

•

PA Services Concerns

Potential concerns
Latency for on-device
auctions. Testingsuggests that PA
auctions may be slower,
either due to device
constraints (e.g.
processing power
available), auction design(e.g. waiting for
information on thewinning contextual bid
before completing the PA
auction) or network
requests (e.g. fetchingbidding or scoring logic).

Moving processing to thedevice can raise
concerns about overall
page or device
performance, with
implications for searchengine optimisation anduser experience.

CMA views in January 2024
reportGoogle proposes to addressthese concerns via designchanges in Chrome and by
publishing guidance for adtechs on optimising theirapproach to PA. The designchanges add controls forsellers, allowing sellers to set
limits on the time andresources buyers canconsume. 42 The guidance
includes recommended bestpractice for buyers andseller. 43

Updated CMA views
Our views remain unchanged. We
anticipate that stakeholders will beable to provide more specificfeedback on latency at the end of the
Chrome-facilitated testing period.

We are monitoring latency
issues closely, recognisingthat high latency can lead to
unsold ad inventory andnegatively impact user
experience. We expect that
the Chrome-facilitated testing
period will provide further data
and we welcome ongoingstakeholder feedback,particularly on whether thetools and recommendations
Google has implemented are
sufficient.
Our understanding is that
Chrome uses separate
worklets for the PA auction
and page rendering. This
allows page rendering tocomplete before the PA
auction and should minimise
impact on page load times.

Our views remain unchanged. We
anticipate that stakeholders will beable to provide more specificfeedback on latency at the end of the
Chrome-facilitated testing period.

We anticipate that the
Chrome-facilitatedexperiments period will
provide further data on device
performance issues. We
welcome specific feedback
from market participants on
this issue.

42

See ‘Performance of Protected Audience Auctions’ in Google’s Q3 2023 feedback report (accessed on 22 April
2024).
43
See Google Developer Blog on ‘Improve Protected Audience API auction latency’ here (accessed on 22 April
2024).

25

Potential concerns
Fenced Frames restricts
available ad formats.
They do not currently
support native, or video
ads and stakeholders
have requested native
support for dynamic ad
sizing.

CMA views in January 2024
reportWe recognise significant
stakeholder concerns aroundvideo and native ads once
Fenced Frames are required.
Google currently intends torequire Fenced Frames noearlier than 2026. Google saysthat it has not yet designed asolution to render video inFenced Frames.
Stakeholders have raised
support for the VAST standard
as a specific concern. While
Google is not obligated tosupport all existing standards,
we are aware of the potential
disruptions that a lack of VAST
support could cause.
Discussion on native ads andsizing is ongoing. 44 We aremonitoring the issue andrecognise the potential impact
on publishers, advertisers, andusers. Restricting ad formats
could hinder the feasibility ofdynamic content within
existing native ad formats,limiting the potential for rivals
and new entrants to introduce
innovative advertising formats
beyond walled gardens andpotentially diminishing theoverall user experience.

Uncertainty about the
impact of restrictions ontransmitting signals fromvideo players in Fenced
Frames.

Our understanding is thatvideo ads currently send realtime signals to external
systems, including forreporting purposes. The
restrictions imposed underFenced Frames will blockthese signals. We will continue
to monitor this issue as
Google implements a solution
for video requirements aheadof the required use of Fenced
Frames no earlier than 2026.

44

Updated CMA views
Google has now confirmed its
commitment to ensuring support for
major ad formats before enforcing arequirement for Fenced Frame
rendering.
Stakeholders have also raised
concern that PA API with iframes
might also lack support for video andnative ad formats. This would be ofgreater concern given its immediate
impact at third-party cookie
deprecation, Google has in response
published a demo showing one
option for handing VAST in PA using
iframes 45. We would welcome further
industry feedback on the extent towhich this resolves this concern.
We note that discussions with
Google concerning the future
governance arrangements forPrivacy Sandbox are ongoing.
Google’s work to develop andimplement Fenced Frames are
expected to be incorporated underthat governance model.

See above

See issue #741 here and issue #311 here on the FLEDGE repository on GitHub (accessed on 22 April 2024).
On how the one ad-size gets decided, see issue #908 here; On the possibility of enabling multi-sized PA auction
output, see issue #825 here; and on implementing an additional Ad-Slot Size signal, see issue #869 here
(accessed on 22 April 2024).
45
See ‘Instream video ad in a Protected Audience sequential auction setup’ demo here (accessed on 22 April
2024).

26

Potential concerns

CMA views in January 2024
reportWe welcome further feedback
from market participants on
this use case, including onwhether other Privacy
Sandbox tools (e.g. Shared
Storage) offer options todeliver the necessary signals.

Updated CMA views

Google intends todeprecate event level
reporting for PA auctions,no earlier than 2026.
Once event-level
reporting has been
deprecated, the Private
Aggregation API will
become the only
reporting mechanism
available.

Google aims to prevent theuse of event-level reporting for
discovering the IG of individual
visitors to the publisher's site,aligning with the privacy
objectives of Fenced Frames.

Google has said that it anticipates
collaborating with the ecosystem toenable the necessary event-level
reporting without compromising user
privacy. Recognising concerns about
the impact on ad techs' bidding
strategy optimisation, Google
foresees the availability of a private
machine learning training model
based on TEEs well ahead of theremoval of the current event-level
reporting. We are continuing tomonitor developments.

As the Private Aggregation
API will become the only
reporting mechanism within
the PA API, the IG will bepassed solely through"generateBid" and to"reportWin" functions.
Our understanding is that this
could reduce the information
available to ad techs andcould have an impact on theirability to optimise their bidding
strategy. We are keen to hearfurther detail on the specificimpacts and proposals fordesign changes.

PA auction design shifts
data flows that werepreviously server toserver onto the device.
This raises concerns
about transparency, andcontractual issues (e.g.
as ad techs have nocontractual relationshipwith Google).

We recognise that Privacy
Sandbox changes, including
restrictions on access to
information that is currently
available, can impact ad techbusiness practices.

Concerns about therequirement to adopt
TEEs to operate PA’sserver-side elements,
such as the Bidding andAuctions Services andthe Key/Value Server.

We discuss concerns relating
to TEEs below.

We are working to identify
these issues, including
possible solutions.

Google has indicated thatsome off-device services will
be an optional extra for market
participants who want todevelop larger, more

46

Google’s reply to the IAB Tech Lab’s
Fit Gap Analysis refers to theconcern that ad techs using thePrivacy Sandbox tools will not have acontractual relationship with
Google, 46 as these tools are inherent
to the browser and developers
independently determine their usage.

Since the last publication, we areaware of increased concerns
regarding uncertain TEE
requirements and the unavailability ofBidding and Auction services beyond
the origin trial.

See the ‘Data Guarantees’ heading in Google’s response to the IAB Tech Lab’s report here (accessed on 22
April 2024).

27

Potential concerns

CMA views in January 2024
reportsophisticated models, allowing
stakeholders to choose
components aligning with theirobjectives.
We are working with Google toexplore the flexibility of serverto-server architecture and its
impact on market participants.

Updated CMA views
Google continues to emphasise ondevice functionality will suffice for adtechs to conduct PA auctions, andthat off-device Bidding and Auction
services will be optional.
This is supported by ongoing
improvements in latency, 47 withforthcoming updates providing
greater clarity on Bidding andAuction services costs and theoutline of the baseline system, 48 as
well as strategies for scaling up traffic
Bidding and Auction services beyond
the origin trial. 49
We have also heard concerns that
Google’s characterisation of serverside elements as ‘optional’ ismisleading as, in practice, most ad
techs will need access to real time
information from Key/Value servers.
Google states that running Key/Value
servers in TEEs will be required no
sooner than Q3 2025 and that
Google will provide at least 12
months’ notice before the TEE
requirement becomes mandatory.
We await the results of the testing
period and encourage additional
stakeholder feedback.

PA lacks adequate
authentication to verify
contextual responses,
K/V server-originatedresponses, or bid
submissions.

Stakeholders have raised concernsthat PA is insufficiently robust interms of validating the authenticity ofcontextual responses, responses
from a key-value server or bid
submission. For example,
stakeholders claim to have devised
effective attacks against PA.
These concerns have been raisedwith Google and we await its
response.

35.

Our concerns under D&I D – User Experience relate to the default enrolment
into PA and the information notice for PA being shown once, immediately after47

See the ‘Improve Protected Audience API auction latency’ page here (accessed on 22 April 2024).
See the ‘Bidding and Auction Costs’ presentation here (accessed on 22 April 2024).
49
See ‘roadmap’ within the Fledge GitHub repository here (accessed on 22 April 2024).
48

28

the Topics API dialogue box. We are continuing to engage with Google on
resolving these concerns and asking it to conduct further user research andtesting, to ensure adequate user comprehension of the API including its
distinction from the Topics API and the purpose of PA IGs, ease of accessing
the relevant user controls and enabling users to revisit their PA preferences.
Summary
36.

Google needs to resolve our concerns for PA API and our current view is that
this should involve taking the following steps:(a) Enhance Chrome UX to ensure disclosure of data processing activities
conducted by site owners and all advertising partners when delegating
permissions for IG creation to third-party partners or combining third-party
data.
(b) Develop a robust governance and monitoring framework to ensure thetimely delivery of scheduled privacy measures, particularly PETs, fraud
detection protocols, and up to and including revocation of API access, toensure that where abuses of the API are identified, Google responds
appropriately.
(c) Address the issues relating to GAM’s approach to PA, including by
ensuring that it does not distort competition in digital advertising between
Google and other market participants, in a way that could reinforce its
existing market position.
(d) In particular, resolve concerns related to use of a third-party (i.e. otherthan GAM) ad server to run the top-level PA auction with GAM
participating as a buyer in the PA component auction. Additionally, reflect
the need for publishers to have the same reporting visibility overcomponent auctions as GAM.
(e) Resolve ad format concerns, specifically the use of video and native ads
in Fenced Frames. Our understanding is that these formats are
particularly important to ad revenue and that they are currently
unsupported with Fenced Frames.
(f) Continue dealing with stakeholders' suggestions and providing support indeveloping solutions, where possible, regarding IGs, on-device latency,
and server-to-server architecture.

29

Measuring digital ads
Attribution Reporting API
Overview
37.

The Attribution Reporting API (ARA) aims to allow ad techs to measure
conversions without third-party cookies. A conversion occurs when the user
takes an action (e.g. creating an account or making a purchase) after clicking
on or viewing an ad. 50 Measuring conversions is necessary for several of adtech’s key functions, including budgeting, campaign reporting, optimisingbidding strategies, and pricing ad inventory.

38.

ARA supports two forms of reporting:(a) Event-level reporting. Event-level reports provide information about aspecific ad event (like click or view). The browser stores information about
ad events and conversions on-device and sends a report to the ad tech if
a conversion attribution occurs. Chrome adds delay and noise to thereports. The length of the delay is dependent on the ad tech’s
configuration, with a minimum 1-hour report window limit. Delay and noise
are intended to protect user privacy by preventing ad techs from using
event-level reports to track users across sites. 51(b) Summary or aggregate reporting. Summary reports capture information
about attributed conversions in a similar way as event level reports. The
ad tech must first specify which ad event and/or conversion dimensions
they would like to report on. When a conversion is attributed, Chrome
encrypts the ad event and conversion information and sends it to the adtech, with a random delay between 0 to 10 minutes or with no delay if thead tech opts in to instant reports. For instant reports there are additionalnull reports introduced. The ad tech can batch these encrypted reports
together and send to their aggregation service, a specialised server
running in a TEE on the public cloud. The aggregation service aggregates
the batched reports and adds privacy protections like noise. The ad tech
can then retrieve summary reports from the aggregation service. 52

50

See Google Developer Blog on ARA here (accessed on 22 April 2024).

51 ARA currently supports up to eight conversion categories for event-level reporting. See Google Developer Blog

on event-level reports here (accessed on 22 April 2024).
52 An overview of Aggregation Service for the Attribution Reporting API can be found on GitHub here (accessedon 22 April 2024).

30

39.

Chrome recommends ad techs to use summary and event level reports
together, as they provide complementary information. Google Ads has
published a technical explainer on how it is using ARA to measure
conversions. 53
Potential concerns

40.

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

Potential concerns
Key controls, such as epsilon
values and API rate limits,have not been tested.

Provisional CMA views based on ICO’s preliminary
assessment
We understand that key controls (e.g. rate limits, epsilon values,
reporting delays etc applied to both event and summary reports)
are set initially as placeholders/’strawmen’ during testing. For
example, for summary reports, parties running aggregation
services can use an epsilon value up to 64 while ARA is adopted
through third-party cookie deprecation – with an expectation thatan appropriate range will be identified in due course.
The ICO is concerned that key controls and parameters for the
ARA have not been effectively tested to establish the optimum
balance between utility and privacy. There is also a concern that
Google will not be able to gather useful feedback from ARA
customers as API callers are likely to have a vested interest inpreserving maximum utility. Effective testing is for Google todefine, but Google must justify why 64 is appropriate or test to findthe appropriate number.
Google has said that key privacy parameters are still under review
as parties continue to test and experiment with ARA. Google isexploring how governance for internal decision making will improvetransparency and strengthen guardrails. To support ecosystem
testing efforts, Google has provided a number of tools for testing,such as Simulation Library 54 and Noise Lab 55 and will also give adtechs enough time to test before any changes are made.
We await Google’s response on its governance process.

Any measurement productthat permits events to beconnected to an individual
will always present a crosssite tracking risk.

We understand that, for event level reports, a key productrequirement is an advertiser’s ability to learn that a particular addisplayed to an individual resulted in a conversion, and for thesesignals to inform/train machine learning models. Accordingly,
Google has provided sufficient space in the maximum value for thesource_event_id (64 bits) to allow an ad shown to an individual ona publisher site to be mapped to any relevant granular information
available to publishers or partners. This ID can then be associatedwith limited conversion data.

53 See Google Ads Developer Blog on ‘Optimally configure the Attribution Reporting API for ad measurement’here (accessed on 22 April 2024).

54 See Simulation Library repository on GitHub here (accessed on 24 April 2024).
55 To access the Noise Lab, see here (accessed on 24 April 2024).

31

Potential concerns

Provisional CMA views based on ICO’s preliminary
assessment
Google has acknowledged that, by necessity (i.e. model training),
the design of event level reports links limited conversion data backto a specific individual and event on a publisher site. While Google
has applied a range of controls to make reidentification harder (e.g.
limiting the information joined to between 1 and 3 bits (conversiondata) and applying event-level (i.e. not user level) differential
privacy), Google has also acknowledged that the granularity ofdata required for model training ultimately limits the application ofcertain controls (e.g. at a certain point, a lower epsilon would
undercut the bidding model use case).
As a result, Google has acknowledged that misuse of the API can
result in reidentification. We understand it is Google’s view that thisrisk is acceptable as the ARA significantly reduces both thepermissiveness and quantity of cross-site tracking currently
enabled via third-party cookie-delivered measurement products
while delivering a vital ad use case. Additionally, Google expects
that the API will be mainly used by well-intentioned advertisers(agreed to via the Privacy Sandbox attestation process), further
reducing the risk.
Based on the ICO’s preliminary assessment, we view it asprobable that a proportion of API callers will use cross-site
information derived from event level reports for purposes beyond
ad measurement and reporting. For organisations deviating from
Google’s intended use case, after consulting with the ICO, we view
it as likely that alignment to transparency and lawfulness principles
in the Applicable Data Protection Legislation will be particularly
impacted.
In response, Google has expressed its dedication to the long-termgoal of reducing the likelihood of successful abuses of the API.
However, its immediate goal is to help the ecosystem transition
away from third-party cookie-enabled products that enable far
more pervasive tracking.
We understand that Google does not intend to transition toaggregate-only reporting. Accordingly, we have asked Google toexplain what governance and monitoring can be implemented toensure that, where identified, Google responds appropriately toabuse of the API.

Navigation tracking will
undermine key ARA limits
placed on click events.

We understand that, across the Privacy Sandbox tools, no controls
are in place to explicitly prevent organisations using linkdecoration/navigation tracking to undermine limits applied to ARA.
As a result, for click events, it is possible for an ad tech to join auser’s identity cross-site via a navigation event. This underminesthe 3-bit limit applied to navigation event trigger data.
In response, Google has pointed to a range of anti-covert tracking(ACT) efforts that strive to make covert tracking more challenging.
We await further details to understand how these controls resolve
this concern.

Documentation, guidance
and wider public-facing
information relating to ARA
do not make clear the

The ICO noted a concern with Google that a range of public-facing
Google-produced documentation may have created ambiguity
regarding the application of PECR. As regards ARA (and also
applicable to wider Privacy Sandbox tools), the ICO’s position,

32

Potential concerns
requirement to consider thecollection of consent required
by PECR.

Provisional CMA views based on ICO’s preliminary
assessment
which we share, is that the storage and access of information for
non-essential purposes requires consent.
In response to this concern, Google is updating the EU Consent
Policy FAQ and the Privacy Sandbox Privacy-related Compliance
FAQ.
We await to receive these updates.

41.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the following potential concerns under D&I B – Digitaladvertising and D&I C – Impact on publishers and advertisers. In thetable below, we also include our updated views on each of the concerns
identified based on further submissions from Google and other market
participants since our last report was published in January 2024. New
concerns raised by stakeholders during the reporting period are included at
the end of the table.

Potential
concerns
ARA does notsupport some
types ofattribution thatare currently
available withthird-party
cookies, forexample multitouch attribution.

CMA views in January 2024 report

Updated CMA views

It is clear that Google’s ARA will notprovide the same functionality as
third-party cookies, given the desire tolimit the amount of personal
information shared.

Stakeholders have expressed further
concerns around Google’s approach
to multi-touch attribution, arguing that‘single touch’ attribution is likely toadvantage Google.

We consider that the changes Google
has made to ARA following
stakeholder feedback should increase
its utility overall, including the movefrom fixed to flexible event reporting
windows.

For example, a current user journey
may involve seeing an ad several
times on different properties (e.g. a
publisher site, their social media feed,etc) before the user takes an action.
Users may also act on their intent toconvert by searching for theadvertised product. Stakeholders areconcerned that Google is likely to be
the ‘last touch’ and therefore capture
more of the value from conversions
than other market participants.
We have shared this feedback with
Google and await its response.

Coarser
measurement
may make itharder for
publishers tovalue their adinventory.

See above

Stakeholders continue to express
concerns that reduced access to realtime, cross-site data could make it
more challenging to value ad
inventory. Although we anticipate thatthe results from the period of Chromefacilitated testing will give us greater
insight into the magnitude anddirection of any impact on publishers
and advertisers, given the desire tolimit the amount of personal
information shared, it is unrealistic to33

Potential
concerns

CMA views in January 2024 report

Updated CMA views

The proposed ’20
event peraggregatable
report’ limit
appears arbitrary
and undermines
ARA’s utility.

Many of the Privacy Sandbox APIs
require Google to define parameters.
Our current view is that a ’20 event’
per aggregatable report limit isreasonable, given that attempting tomeasure small numbers of events via
aggregate reports is unlikely to be
useful. Google has published detailed
guidance on tuning ARA, information
on working with noise and details of
how Google Ads uses ARA. 56 Our
current view is that this information
should allow market participants to
use ARA effectively.

Stakeholders continue to express
concerns about the values ofparameters that Google has defined.
Our January 2024 report recognisedthat the Privacy Sandbox design
requires Google to define someparameters and our view remains thatthe report limit is likely to allow market
participants to use ARA effectively.

Advertisers are
currently able toadjust theirspending on ad
campaigns in realtime. ARA
imposesreporting delays
and could lead towasted spendthat could
otherwise havebeen reallocated.

We understand that ad techs can tune
ARA to prioritise different types ofreporting, including the move fromfixed to flexible event reporting
windows. We are keen to understandwhether ARA can provide reportingthat minimises delay for ad spend
optimisation use cases.

The move to flexible event reporting
windows has been reflected in thetechnical specification 57 and also in
an explainer update. 58 Our
discussions with Google on this point
are ongoing.

ARA degrades
open display
measurementcompared withmeasurement
capabilities on
O&O adinventory.

More sophisticated attribution may bepossible on O&O inventory, forexample where the ad tech hasaccess to first party data. The
Commitments impose restrictions on
Google’s use for first-party data
(specifically Chrome browsing history
and Google Analytics) for
measurement on Google O&O
inventory.

Stakeholders continue to express
concerns that measurement using
ARA will be less effective than
measurement on O&O inventory. We
have previously stated that we areconscious of the risk that ad spend
could move away from open display
and into O&O inventory depending on
the overall impact of the Privacy
Sandbox changes. 59

We are considering whether further
restrictions on Google’s use of firstparty data are necessary.

Our discussions with Google on
further first-party data restrictions are
ongoing.

expect Google’s ARA to provide thesame functionality as third-party
cookies.

We welcome further feedback frommarket participants based on theirexperiments during the Chromefacilitated testing period.

Further, we have received feedback
that there are missing fields in theflexible reporting events, namely
currency and orderID.
We have shared this feedback with
Google and await its response.

56 See Google Ads Developer Blog on optimally configuring ARA here and the Google Developer Blog on the

ARA and Noise Lab here (accessed on 22 April 2024).
57 See the technical specification on the Attribution Reporting API repository GitHub here (accessed on 24 April
2024).
58 See the Flexible Event-Level Configurations explainer on the Attribution Reporting API repository on GitHub
here (accessed on 24 April 2024).
59 See paragraph 27 of the CMA’s Q4 2023 update report (accessed on 22 April 2024).

34

Potential
concerns
Marketparticipants will
be dependent on
Google’s APIs forad measurementin future, whichraises concerns
about the ability
to audit and verify
results.

CMA views in January 2024 report

Updated CMA views

Ad verification currently relies on
auditing of log-level reporting data,
which will not be available under
ARA.

Our discussions with Google on ad
verification use cases are ongoing.
We have clarified that we are keen tounderstand the differences between
common approaches to ad verification
using third-party cookies and theapproaches available using ARA.

Google needs to explain how it seesad verification use cases being
addressed under the Privacy
Sandbox.

We have previously stated that we do
not expect the Privacy Sandbox toprovide identical functionality of thirdparty cookies.
We have also raised stakeholder
concerns that Google is not bound bycontract to ensure verifiable server-toserver communication. There does
not seem to be a comparable feature
within the Privacy Sandbox tools
more broadly to verify that Google isthe other party to the data exchange.
In addition, the party relying on the
Privacy Sandbox tools does not know
how the data provided will beprocessed and has no way ofverifying that the expected processing
occurred. This can haveconsequences for commercial viability
and commercial contracts.
We await Google’s response thispoint.

Google’s
proposed
approach toattribution differsfrom theapproach taken
by otherbrowsers, whichmeans that there
may be limited
interoperability of
ARA with othersolutions.

We remain concerned that lack ofinteroperability could harmcompetition by creating additional
cost and complexity for businesses
seeking to measure digital ads.
Google needs to explain how it willcontinue its efforts to enhance greaterinteroperability of approaches toattribution and reporting over time.

We are aware that Microsoft has
proposed implementing ‘ARA withmodifications for better parity with
CPA billing’ in Edge. 60 We remainkeen to understand implications forinteroperability and efforts to improve
interoperability of approaches toattribution and reporting.

Google limiting
the number ofdifferent
attributions per

We are concerned about Google
limiting the number of different
attributions per advertiser to eight
conversion types, which may be

Google has introduced custom trigger
data, allowing ad techs to configure
trigger data values and/or

60

We await Google’s response on thispoint.

See the ‘API difference highlights’ explainer on the Privacy Preserving Ads repository on GitHub here
(accessed on 24 April 2024)43.

35

Potential
concerns
advertiser toeight conversion
types, potentiallyharming
advertisers who
have more thaneight types.

CMA views in January 2024 report

Updated CMA views

harming advertisers who have morethan eight types. Currently, ARA limits‘trigger data’ to 3 bits and this only
allows eight distinct conversion types.
Phase 2: Full Flexible Event-Level 61
would appear to indicate future
support for up to 32 values; however
there is currently no timeframe ordeadline for this.

cardinality. 63 The trigger data
supports 32 bits. ARA adds noise
depending on the number of distinct
trigger values, e.g. limiting thenumber of distinct trigger values with
reduce noise and vice versa. 64

The solution suggested within ARA
for attributing to multiple domains iscurrently restricted to three domains 62(which may be insufficient) andrequires the advertiser to register
these domains in the ‘click’ event(which would add overhead).

We understand that discussions
within Google on ARA supporting
multiple reporting domains forconversions is ongoing. 65
In the absence of further stakeholder
feedback, it is likely that the change toconfigurable trigger data will resolve
the concern about limiting tigger data
to 3 bits.

The lack of andneed for atransaction ID
where the data
passes from thebuy side to thesell side,
enabling the twoto connect.

We are aware of stakeholder requests
for Google to provide a transaction ID
to support attribution reporting. 66 Our
current view is to agree with Googlethat this could undermine theintended privacy model for ARA.

Our view remains unchanged.

The need to seek
explicit feedback
from advertisersconcerning
modification totheir commercial
contracts given
the changes toaggregation andattribution.

Stakeholders have expressed
concerns that Google needs to seek
explicit feedback from advertisersconcerning modification to theircommercial contracts given thechanges to aggregation andattribution, specifically whether
advertisers are willing to be billed on
the basis of noisy or aggregate
reporting. We continue to welcome
feedback from market participants,
particularly from advertisers on thispoint.

We understand that a small portion of
the ecosystem relies on attribution
data for billing, whether that is Cost
Per Action (CPA) or Cost Per Mille(CPM) and has raised concerns
regarding the impact of noise anddelay on billing. Google is responding
to these concerns on GitHub andwelcomes additional feedback frominterested stakeholders. 67

61

An overview of Phase 2: Full Flexible Event-Level reporting can be found on GitHub here (accessed on 22
April 2024).
62
See issue #1048 on the Attribution Reporting API repository on GitHub here (accessed on 22 April 2024).
63 See the Flexible Event-Level Configurations explainer in the Attribution Reporting API repository on GitHub
here (accessed on 24 April 2024).
64
See ‘Data Limits and Noise’ in the Event explainer in the Attribution Reporting API repository on GitHub here
(accessed on 22 April 2024)
65
See the minutes of the regular ARA stakeholder meeting on 5 February 2024 here (accessed on 22 April
2024).
66
See issue #15 on the Attribution Reporting API repository on GitHub here (accessed on 22 April 2024).
67
See Issues on the Attribution Reporting API repository on GitHub here (accessed on 24 April 2024).

36

Potential
concerns

CMA views in January 2024 report

Stakeholders
have expressed
concern that thelack of a key
discoverymechanism in
ARA would makeaggregatedreports
unsuitable for
their use cases.

N/A

Stakeholders
have expressed
concern that
adding noise toreports will haveadisproportionate
impact on smaller
ad techs.

N/A

Updated CMA views

We recognise that Privacy Sandbox
represents a significant change forthe ecosystem and reiterate that we
do not expect Privacy Sandbox todeliver identical functionality to thetechnologies (like third-party cookies)that it intends to replace. We also
recognise that Privacy Sandbox may
have business impacts (e.g. changes
to business practices).
In June 2023, Google proposed
adding key discovery functionality to
ARA and said that it intended to
publish a tool to help ad techs explore
the impact of threshold selection on
the precision/recall trade-off.
We are not aware of the timelines forshipping this proposal.
We have raised this concern with
Google and await its response.
We understand this concern to focus
on access to reliable signals forsmaller vs larger market participants.
Stakeholders have noted that thenoise added to reports can bedisproportionately limiting for smaller
ad techs who are likely to reach the
20-event threshold more slowly andmay not be able to rely on aggregate
reports as much as larger ad techs.
However, Google clarified that there
is no enforced minimum number ofconversion events per report. The
limit of minimum 20 events peraggregatable report does not exist.
We welcome further feedback frommarket participants, including on theirexperience of using the tools that
Google has provided to help ad techs
work with noise.

Stakeholders
have expressed
concern that thecurrent ARA
setup does notsupport manual
campaign
optimisation.

N/A

Stakeholders have expressed
concerns that some ad techs want tomanually optimise campaigns basedon granular reporting. Google has
discussed this scenario with ad techs
and proposed approaches to using
ARA to support manual campaign
optimisation. Google’s view is that
ARA allows for ad tech customisationand flexibility to solve a range of ad
tech use cases. For example, Google
suggested using different flexible
event-level configurations and, using

37

Potential
concerns

42.

CMA views in January 2024 report

Updated CMA views
event-level reports with summary
reports to reduce the impact of noise
and to meet stakeholders’ manualand automatic optimisation needs.

As regards the application of D&I D – User experience, similar to the position
for PA API, our concerns stem from the default enrolment into ARA, thesequencing of the PA API and ARA information notice after the Topics
dialogue box potentially leading to misperceptions about their association, andthe accessibility of the ARA settings page. We are continuing to engage with
Google on these, and other UX concerns.
Summary

43.

Google needs to resolve our concerns for ARA, and it has agreed to take thefollowing steps:(a) Develop a robust governance and monitoring framework to ensure that
ARA processes the minimum amount of data necessary to achieve its
purpose and that where abuses of the API are identified, Google
responds appropriately.
(b) Provide further details on proposed ACT measures that strive to makecovert tracking more challenging.
(c) Update the general Privacy Sandbox developer compliance guidance on
the requirement for API callers to obtain user consent.

44.

In addition to these steps, our current view is that Google should:(a) Secure greater interoperability and/or standardisation of approaches toattribution reporting. These currently appear fragmented with otheravailable solutions including Mozilla/Meta’s Interoperable Private
Attribution and Safari’s Private Click Attribution. The lack ofinteroperability could harm competition by creating additional cost andcomplexity for businesses seeking to measure digital ads.
(b) Explain how, in Google’s view, ad verification use cases will be addressed
under the Privacy Sandbox, including ARA.
(c) Seek explicit feedback from advertisers on the impact of changes,
particularly concerning modification to their commercial contracts given
the changes to aggregation and attribution.
38

Trusted Execution Environments
Overview
45.

Google introduced Trusted Execution Environments (TEEs) to support usecases where off-device processing is required while preserving the privacy ofuser data. Google has control of the Chrome environment where it candetermine the security and privacy characteristics of the browser. However,there are no such built-in controls outside the browser, which necessitates
TEE-based solutions for device to server interactions that extend thefunctionality of Privacy Sandbox APIs.

46.

TEEs are secure server configurations that are primarily secured throughappropriate hardware environments (served by the cloud providers – see
below). In addition, in a Privacy Sandbox context, code images and scripts
are developed and maintained by Google and further secured by anattestation mechanism that ensures the TEEs have not been modified by third
parties.

47.

Aggregation Service in a TEE is required for use of the ARA Aggregate API
and the Private Aggregation API. However, debug reports allow for the use ofAggregation Services outside of a TEE, and ahead of third-party cookie
deprecation most users have debug reports. There are also TEEs fordifferent contexts, such as the Key/Value and Bidding and Auction Servers for
PA. Google has updated the TEE explainer68 to provide more detail ontimeline and feature availability. Stakeholders continue to express concern
about on-device performance, meaning that off-device components (e.g. theBidding and Auction services for PA API) will not, in practice, be optional. We
are monitoring this issue and welcome further feedback from market
participants, in particular based on their experiences during the Chromefacilitated experiments period.
Potential concerns

48.

After consulting with the ICO, we are concerned that in the absence of TEEs
and other features at the point of third-party cookie deprecation, API callers
will be able to join user activity across the sites they visit (see D&I A –Privacy outcomes table in the PA API section above). We await to receive

68

For more detail, see the TEE explainer here (accessed on 22 April 2024).69 See Bidding and Auction Cost
explainer here and Aggregation guidance here (accessed on 22 April 2024).

39

further details from Google on how its proposed governance framework willaddress this concern.
49.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the following potential concerns under D&I B – Digitaladvertising and D&I C – Impact on publishers and advertisers. In thetable below, we also include our updated views on each of the concerns
identified based on further submissions from Google and other market
participants since our last report was published in January 2024. New
concerns raised by stakeholders during the reporting period are included at
the end of the table.

Potential
concerns
Cost andcomplexity of
adopting TEEs.
We have heard
concerns from adtech stakeholders
about thesignificant
financial andstaffing resources
required to adopt
and maintainTEEs.

CMA views in January 2024 report

Updated CMA views

Google has published certain
explainers to address this concern. 69
We expect that it will publish further
information (e.g. a cost explainer for
K/V) to help ad techs estimate thecosts associated with adopting TEEs.
We recognise that some of thesecosts will vary, for example dependingon specific deals with cloud providers
that an ad tech can negotiate.

Google has confirmed that the K/Vcost explainer will be published in H1
2024 to supplement previous B&A
self-assessment guidance and that it
will continue to proactively seek
feedback from expected users of K/Vregarding cost considerations.
We encourage stakeholders toprovide us with any further material
feedback on cost concerns where
they are able to, recognising that cost
targets can be sensitive businessinformation.
We understand that there is a risk thecost and complexity of adopting TEEs
could be greater to ad techs outsideof Google’s ecosystem, reliant on
Google Cloud Platform (GCP)
services. We are exploring the impactof this on ad techs and would
welcome stakeholder feedback on
non-negligible cost concerns.

Google currently
only supports two
public cloudproviders,
Amazon Web
Services (AWS)and Google
Cloud Platform(GCP).

69

Google has committed to support
other public cloud providers, based on
feedback from the ecosystem. Google
has stated that it will use ad tech
feedback on which cloud services
should be supported as a key
prioritisation criterion.
Although we agree this is a sensible
route forward, we recommend that
Google provide timelines for ensuringthat cloud providers, and any others

Google has now proposed criteria that
additional compute environments
offered by public Cloud Service
Providers (CSPs) must satisfy inorder to be eligible for processinguser data generated by Privacy
Sandbox APIs. We note that thismeans the environment must be
secure, private, isolated, remotely
attestable and the CSP must provide
an attestation report. Google willvalidate that the CSP and the remote

See Bidding and Auction Cost explainer here and Aggregation guidance here (accessed on 22 April 2024).

40

Potential
concerns

CMA views in January 2024 report

Updated CMA viewsas the market develops, aresupported within appropriate
timeframes. At the very least, Google
needs to provide objective criteria for
new cloud providers. Competition in
the cloud infrastructure level issubject to a separate, ongoing market
investigation by the CMA. 70

attestations are trustworthy, by
ensuring compliance with recognised
industry standards on cloud security.
In particular ISO 27001, ISO 27017
and ISO 27018, and certification fromcloud security industry bodies, i.e.
Level 2 in Cloud Security Alliance’s
STAR program.
Google has now published finalised
guidance and specification criteria for
onboarding new cloud providers. 71 In
addition, Google expects to publish atechnical explainer on its approach forsupporting new CSPs before thirdparty cookie deprecation, and to beready to add potentially eligible cloudproviders in 2025. We invite feedback
from stakeholders on thesemeasures, particularly on theprospect that some of the discussions
on the review process are likely to be
private to prevent disclosure ofconfidential information by CSPs andto avoid disclosing internal security
practices.
Furthermore, we understand that
Google does not have plans to
onboard alternative public cloudproviders ahead of third-party cookie
deprecation. We would like to invite
feedback on the fact that the earliest
approval for alternative public cloudproviders is likely to be in 2025.

Google has
limited support topublic cloud,meaning that adtechs cannot run
TEEs on theirprivate cloudinfrastructure.

Google has said that deploying TEEs
on private cloud environments
presents significant challenges. We
note the strong ecosystem interest in
private cloud (e.g. the issue wasraised in Google’s Q2 2023 and Q1
2023 feedback reports).
We have raised the issue with Google
and are seeking further clarity on thespecific security challenges.

We understand that Google plans tocontinue exploring TEE technologies
to be able to expand the choices
available to ad techs, while meeting
security requirements, and will take
into consideration the types ofsolutions available as they makedecisions about TEE requirements.
Google is exploring options forsupporting TEEs outside of public
cloud but is unable to confirm whether
and when support for TEE solutions
outside of public clouds will beavailable in production.
Google has proposed publishingfurther details on its technical70

See CMA, Cloud services market investigation.

71 See GitHub explainer here (accessed on 24 April 2024).

41

Potential
concerns

CMA views in January 2024 report

Updated CMA views
approach to private cloud TEEs, togather further ecosystem feedback
ahead of third-party cookie
deprecation. We encourage
stakeholders to provide feedback.
Our concerns remain about the
impact on publishers and advertisers,
in particular the cost of TEE adoption
plus the sunk costs of investment inprivate cloud infrastructure.

Self-preferencing
risk associatedwith running
TEEs on GCP.

We are aware of stakeholder
proposals for an entirely open-source
solution, including an open-source
TEE, that is inspectable andtransparent. We will need to consider
this as part of a range of solutions to
mitigate against the self-preferencing
risk.

Discussions with Google are ongoingon this issue.

Performancedegradation andscalability

N/A

We have received feedback fromstakeholders stating that adopting
public cloud for TEEs can have
performance implications, for example
having to use cloud components in
the hot path of an auction is not as
performant or reliable as tuned, onpremises hardware. We have also
heard scalability concerns on TEEs
being rolled out and scaled reliably tousers, especially as the TEE system
has never operated at the proposed
scale. Stakeholders have asked for a
six-month extension to the timetablegiven these concerns.
Some stakeholders have also said
that not having a Bidding and Auction
service available at third-party cookie
deprecation would lead to asignificant degradation in
performance given limited browserside resources. 72
We have relayed these concerns toGoogle and await its response.

Timings

N/A

Stakeholders have said that Google’s
recently proposed solutions cannot be
tested in the timeframes available dueto the preparatory steps that market

72

For more details, please see “Concerns about the requirement to adopt TEEs to operate PA’s server-side
elements, such as the Bidding and Auctions Services and the Key/Value Server” under the PA Services
Concerns heading above.

42

Potential
concerns

CMA views in January 2024 report

Updated CMA views
participants would need to undertakeprior to testing e.g. it could take up to
12 months to get regulatory approvalwith data protection/privacy regulators
to use one of Google’s suggested
workarounds with data storage.
We understand that given typicalcustomer journeys extend acrossdevices, it may have been critical forsome market participants that testingof ARA occurred holistically once
Android support for the ARA wasmade available. Android Privacy
Sandbox ARA was available fortesting on production devices startingin February 2023. App-to-web
attribution across Chrome andAndroid was available for testing on
production devices starting in May
2023.
We await Google’s response to theseconcerns.

Chromerestricting scopefor innovation
through its
implementation of
TEE services

N/A

Stakeholders have expressed
concerns that Chrome is currently
requiring the Google implementationof TEE services for on-device
auctions. Stakeholders have said thatrather than coupling to Google’s own
implementation, Chrome should
specify the behaviours that asatisfactory implementation of aTrusted Signals Server, Aggregation
Server, and any other required nonbrowser components, must meet.
This would allow for innovation within
acceptable privacy boundaries.
Google has noted in its Q1 2024
progress report that to allow for others
to run their own code in TEEs,
Privacy Sandbox will need to review
the code (and any changes) to
confirm it does meet the privacy
guarantees. Google welcomes
feedback on what benefits this would
provide which are not currently
possible.
Additionally, we have recently heard a
new concern that Google’s control
over the design of TEEs might allow it
to limit the ability of competitors toprovide alternative functionalities anddifferentiate their services. For
example, through control of thedesign of Bidding and Auction service
TEEs, Google might be able to stifle

43

Potential
concerns

CMA views in January 2024 report

Updated CMA views
its competitors’ innovations inmachine learning models.
Google has responded that it may
limit functionality in order to maintainsecurity and privacy, e.g. adding
noise to data, or disallowing raw user
data outside of a TEE. When thedesign limits functionality, the same
limitations apply to Google Ads. We
recognise that Google still has
discretion on defining the margin offlexibility provided to ad techs to
implement their functionality todifferentiate their services. We
welcome feedback on this point, in
addition to any concerns on Biddingand Auction service governance.

Governancearrangements for
coordinators.

Supporting alternative providers also
requires Google to onboard
coordinators for the Aggregation
Service on that platform. We areconcerned that delays in onboarding
coordinators could have a negative
impact on market participants, forexample giving them less time to test
their implementations and provide
feedback.

We understand that Google has madeefforts to mitigate any risk that the
timeline for onboarding third-party
coordinators could negatively impact
the ability of market participants toprovide feedback by allowing testingof new clouds before third-party
coordinators are onboarded. We also
understand that Google believes theoperational difference between (a)Google acting as both coordinatorsand (b) Google and a third party
acting as coordinators does notmaterially impact testing.
Google has confirmed to us that
Accenture is now operating as a thirdparty coordinator for Aggregation
Service on AWS, and that it will haveonboarded a third-party coordinator
for GCP ahead of third-party cookie
deprecation.
We note that Google’s selection
criteria for third-party coordinators
include a commitment to act as atrusted neutral party and responsibly
manage the privacy and security ofthe system. This includes low relianceon the partnership as a source ofrevenue, and an agreement to makea published statement about their role
as a coordinator; and technicalexpertise with cloud infrastructure andthe ability to meet operational
requirements. We invite further
feedback from ad techs on this point.
In addition, we have asked Google tospecify what controls will be put in44

Potential
concerns

CMA views in January 2024 report

Updated CMA views
place to ensure that Google does not
influence the second coordinator.
Google has said it has several
safeguards that mitigate the concernthat Google can influence the second
coordinator. These include requiring
the second coordinator to meet
policies to maintain integrity of thesystem and not act in a way that
undermines its security. Accenture
has attested to acting in the above
manner in a public statement 73 forAggregation Services on AWS, andGoogle has given us assurances thatthe second prospective coordinator
will make similar statements when
they start operating as coordinator.
Google will employ similar controls tomeet security best practices, including
limiting access to restricted
information, and documenting when
any access occurred.
Our discussions with Google are
ongoing on the question of monitoringof and appeal mechanisms for
coordinators.
We have also asked Google if there
are any plans or considerations toremove Google as a coordinator,
before or soon after third-party cookie
deprecation. However, there are noplans at this stage to remove Google
from being a coordinator, based on
ensuring operational success,developing and adding new
capabilities to the coordinator
services and for security value.
However, Google is open to reevaluating this, including based on
ecosystem feedback. We welcome
feedback on this point.
Stakeholders have also expressed
concern that wording in thecoordinator service reliability
guarantees, specifically the phrasethat Google does not ’make any
specific promises about thecoordinator service, any related
service, report, feature orfunctionality, their reliability,
availability, or ability to meet your73

See Accenture’s public statement here (accessed on 22 April 2024).

45

Potential
concerns

50.

CMA views in January 2024 report

Updated CMA views
needs’ protects Google without
offering similar protection for market
participants building on Privacy
Sandbox tools. We have flagged thisconcern to Google.

We are only considering the application of D&I D – User experience for userfacing APIs and so have not reviewed TEEs under this criterion.
Summary51.

Google needs to resolve our concerns for TEEs and our current view is that
this should involve taking the following steps:(a) Provide ongoing public updates on the estimated costs of deployment andtesting related to the TEEs for ARA and PA. This may include Google’soffer to publish a statement outlining its technical approach to private
cloud TEEs and asking for further stakeholder feedback on costs before
third-party cookie deprecation.
(b) Respond to our concern that Google Ads might benefit versus competingad techs from cost and latency efficiencies derived from using a cloudprovider also owned by Google (i.e. GCP).
(c) Provide further information on the governance of the third-party
coordinators, specifically the monitoring of, and appeal mechanisms for,coordinators.
(d) Clarify whether there will be a point at which the Coordinator Service will
have warranty language that protects both advertisers and ad techpartners that are being asked to use Privacy Sandbox tools for billing
purposes.

Strengthening cross-site boundaries
Related Website Sets
Overview
52.

Related Website Sets (RWS) is a carve-out to third-party cookie deprecation,
intended to mitigate site breakages. RWS allows a set of domains to be
declared as belonging to the same party. Google has said that RWS is notdesigned for ads use cases, but that there is no prohibition from using RWS
for ads purposes so long as that use complies with data protection laws.
46

When one site embeds another site and both are in the same RWS, Chrome
will allow the embedded site to access its own cookies, which in the absenceof RWS would be blocked as being third-party cookies; therefore, tracking
across the domains within a RWS will be possible. RWS consists of a ‘set
primary’ domain and ‘set member’ domains. 74
53.

Site owners declare related domains using one of three Google-defined
subsets. The subsets are based on use cases, reflecting the purpose of therelationship between the set primary and the set member:(a) Country code top level domains (ccTLDs): For example, google.fr is a
ccTLD for Google in France. The ‘ccTLD’ subset can contain an unlimited
number of domains meeting the formation criteria. In practice, the numberof domains is limited to 255, the current number of ICANN ccTLDs. 75(b) Service domains: For example, domains used to isolate sensitive
functions (such as supporting authentication flow) from user-facing
domains. ‘Service domains’ are domains that provide key infrastructure
for a service. The ‘service’ subset can contain an unlimited number ofdomains meeting the formation criteria.

54.

‘Associated’ domains: Google uses the example of maintaining user journeys
across distinct brand websites. RWS could enable those companies to sharecross-site data between those domains, if the set formation criteria were met.
RWS will automatically grant cross-site access to the first five domains listed.

55.

RWS relies on the Storage Access API to facilitate cross-site access fordomains in the ‘associated’ set. 76 The Storage Access API is subject totechnical controls that Google has said will discourage the use of the‘associated’ subdomain for ads use cases.

56.

The list of subsets may evolve. Google has told us that examples ofdeclarations may help Chrome and the broader web ecosystem identify
additional use case patterns to possibly create new subsets or new APIs.
Google lists set formation requirements by subset on the RWS GitHub

74

The RWS Submission Guidelines can be found on GitHub here (accessed on 22 April 2024).
The ICANNwiki ‘Country code top level domain’ can be found here (accessed on 22 April 2024).
76
An overview of how RWS uses the Storage Access API can be found on GitHub here (accessed on 22 April
2024).
7547

repository. 77 Google applies technical validation to RWS submissions. Thereis currently no validation other than the technical checks.
Potential concerns
57.

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

Potential concerns
The purposes for sets are
not clearly recorded by set
owners.

Provisional CMA views based on ICO’s preliminary
assessment
When submitting a set, we understand that set owners must
provide a description of the cross-site processing purposes for theservice and associated sets. Additionally, for associated sets, theRWS submitter must explain how/why users would expect the set
domains to be affiliated.
From the currently submitted sets, we observe that the free text
field available to submitters is often completed with limited
accuracy and/or for purposes that may be considered out of scopeof the proposal. 78
Based on this information and the ICO’s preliminary assessment,
we are concerned that service and associated sets may be utilisedfor purposes other than those specified by Google in the set
formation requirements. Additionally, we are concerned that
inaccurately recorded purposes for cross-site data sharing
undermines transparency for users visiting websites belonging to aset.
In response, Google is considering the addition of structured fields(e.g. an enumerated list of ’common’ rationales for set inclusion) to
improve the consistency and accuracy of information submitted by
set owners. This would also include a free text field. We await the
proposed update to the submission process.
However, outside of adding specificity to the submission process,Google has said that it will not actively limit how set owners choose
to utilise the service or associated sets. Outside of the technicallimitations, there are currently no restrictions in place regarding the
purposes of RWS. We understand Google views the technicalconstraints of the API suitable to limit harmful misuse of the API.
We await these potential updates and will reflect further together
with the ICO as we continue our analysis.

The purpose for the set
members sharing cross-sitedata is not clearly madeavailable to the user.

77
78

We understand that the Chrome Settings UI does not provide
information to explain why certain websites have grouped
themselves in a set to share cross-site data. While this information
may be available on RWS GitHub documentation, it is highly
unlikely that most users will ever visit this repository.

An overview of set formation requirements can be found on GitHub here (accessed on 22 April 2024).
See currently submitted sets on GitHub here (accessed on 22 April 2024).

48

Potential concerns

Provisional CMA views based on ICO’s preliminary
assessment
Together with the ICO, we consider that, in a post-third-party
cookie deprecation landscape, it is additionally important tohighlight where data is being shared cross-site. As a result, we areconcerned that the Chrome UI does not explain to users the
purpose of data sharing between set members. We consider that,currently, users will have insufficient clarity about the processing
occurring within service and associated sets particularly.
In response, Google has agreed to improve transparency in the
Chrome UI. Further, based on the proposed changes to set
submissions outlined above, Google is also exploring how
structured data from set submission may be presented to users in
the Chrome UI.
We await Google’s updates to the Chrome UI.

If misuse of RWS isobserved on a large scale it
will not be actively
addressed.

We are concerned that RWS (in particular the service andassociated sets) will be used for purposes beyond user-facing
purposes/user experience. Based on the ICO’s preliminary
assessment, we are concerned that cross-site data sharing, within
the bounds of RWS, involves a risk to replicate a range of data
privacy concerns the ICO identified in its 2019 Report and 2021
Opinion. Given this, we are concerned that Google has no process
or governance in place to address these risks if they materialise.
Initially, we had believed that RWS was a temporary solution toassist websites with user experience breakages during the thirdparty cookie deprecation transition. Google has clarified that there
is currently no intent to phase-out RWS.
We understand Google views the technical limits (e.g. 5+1 TLDs in
an associated set) placed on RWS are sufficient to limit the scopeof misuse of the API. Google has said that more stringent controlson the use of RWS should not be imposed as this would
necessitate a more centralised role for Chrome (contracts,
enforcement, etc) that would raise concerns from third parties using
RWS. Further, Google has said that sites using RWS must still
comply with their own data protection obligations.
Google intends to update its approach to governance for thePrivacy Sandbox as a whole. We await further information tounderstand if improvements in this area might resolve ourconcerns.

58.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the following potential concerns under D&I B – Digitaladvertising and D&I C – Impact on publishers and advertisers. In thetable below, we also include our updated views on each of the concerns
identified based on further submissions from Google and other market
participants since our last report was published in January 2024.

49

Potential
concerns
Google discretionin merging RWS
declarations into
the canonical list.

Lack of clarity
around thedefinition of‘ownership’.

CMA views in January 2024 report

Updated CMA views

Although only a handful ofsubmissions have been made to date,
it is clear a level of humanintervention is still required in somecases. This will become a moreurgent issue with scale as more
submissions are made.
We are concerned that this introduces
the possibility of arbitrary discretion
and would like Google to expand thegovernance framework to include ameans for submitters to appeal if they
disagree with a decision made by ahuman during the process. We haveraised specific stakeholder feedback
with Google. 79

We shared stakeholder feedback
around Google’s discretion inapproving requests to merge new
RWS declarations into the canonicallist with Google. Google published a
response on GitHub in March 2024.
Google’s response clarifies thereasons that the specific pull request
was rejected and notes that it intends‘to phase out human involvement andrely entirely on automated checks’. 80

We have considered stakeholder
feedback around issues relating toownership and data controllershipwithin RWS. We recognise Google’s
desire to implement clear,automatable validation checks that
effectively mitigate abuse. Automating
checks also reduces Google’s
discretion, therefore reducing the riskthat Google will govern RWS in waysthat risk distorting competition.
Google has implemented a /.wellknown/ metadata requirement thatessentially defines ‘ownership’ asadministrative access to the set
member domains. Developers place a
copy of the RWS declaration in the/.well-known/ folder on each set
member domain. This demonstrates
that they have access to modify files
on each domain in the set andprevents domains from being added
to the set without their agreement.
This removes some of the complexity
in defining either corporate ownershipor data controllership.

We believe that moving to automatedchecks, as part of a broader
governance process, is likely toresolve this concern.
We maintain our view that Google’s
approach to validating common
administrative access to domains isappropriate.

We agree with Google’s approach totechnical validation based on accessto a site’s /.well-known/ directory.
RWS limits
automatic crosssite data sharing
to the first five

79
80

We believe that limiting auto-granted
cross-site access to the first fivedomains in the ‘associated’ subset
can reduce the risk of abuse when

We have discussed the five-domain
limit further with Google. We note thatthe proposal evolved over time,
Google took and considered feedback

For example, see Movement for an Open Web’s blog on RWS here (accessed on 22 April 2024).
See Pull Request #148 on the Related Website Sets repository on GitHub here (accessed on 22 April 2024).

50

Potential
concerns
domains in the‘associated’
subset.

CMA views in January 2024 report

Updated CMA views

compared to third-party cookies. We
acknowledge stakeholder feedback
that it may be possible to combine
data from more than five domains in amanner that complies with dataprotection law. Google arrived at the
five-domain limit after consultation
with the ecosystem and undertaking
user research and analysis.
We expect Google to provide further
evidence in support of this finding.

on larger and smaller numbers before
settling on five.
Google provided us with user
research suggesting that a relatively
small number of associated domains(fewer than 10) can aid user
understanding. There are significant
caveats around the research, so we
do not consider it conclusive.
Google also explained its desire to
broadly align with the approaches that
other browsers use when dealing withsite breakages due to cookie
deprecation.
Stakeholders continue to express theview that limiting auto-granted accessto five domains is ‘insufficient’ for theirintended use cases, with somesuggesting that RWS should include afeature to allow domain owners toshare RWS data with a third party.
We believe that this could undermine
RWS.
Despite stakeholder concerns, we aresatisfied that Google’s decisionmaking process in setting the autogrant limit at five associated domains
was sufficiently robust. Changes tothe limit or attempts to abuse RWS
should be managed within the Privacy
Sandbox governance process that
Google will set out.

Prompting flow
can be disruptive
and undermine
user experience.

We consider that this strikes anacceptable balance between utility
and privacy. RWS is primarily aimed
at preventing site-breakages post
third-party cookie deprecation.
Prompting for additional cross-sitedata sharing requests by sites andservices enables user choice andintervention to prevent breakage
where access to wider cross-site data
sharing beyond the limits imposed by
RWS is required.

We maintain our view that the
prompting flow strikes an acceptablebalance between privacy and utility
when used to mitigate the risk of site
breakage.

Restrictions on
the ability to
combine data
across sites
disproportionately
affects sites
without access tologged-in users(e.g. news). Sites
with a large

RWS, and Privacy Sandbox as awhole, will limit site owners’ ability toshare cross site data between‘associated’ domains and thislimitation may affect publishers’ ability
to build first party audience data.
Some types of sites, specifically thosewith a high proportion of logged inusers, may be less affected as they
will have the option to combine data

We are considering whether further
restrictions on Google’s use of
Google first-party data regarding user
activity on sites other than those of
the relevant publisher and advertiser
are needed. Our discussions with
Google are ongoing.

51

Potential
concerns
proportion oflogged-in users(e.g. Google) areless affected by
the restrictions.

59.

CMA views in January 2024 report

Updated CMA viewson logged in users on the server side.
We are continuing to discuss theimplications of this with Google.
Paragraph 27 of the Commitments
includes specific provisions on
Google’s use of Google First-Party
Personal Data and Personal Data
regarding user activity on sites otherthan those of the relevant publisher
and advertiser to target and measureads.

As regards the application of D&I D – User experience, we note certain
positive UX implementations Google is planning to introduce including
structured rationale for set inclusions in RWS submissions and information
provision to enhance user understanding of how RWS works and theunderlying user benefits. However, we remain concerned that the RWS user
flow may not be intuitive enough, and that users may not be sufficiently
enabled to identify sites belonging to the same set and comprehend how theirdata is collected and shared across RWS member domains. We arecontinuing to engage with Google, which is also conducting further user
research to resolve our concerns.
Summary60.

Google needs to resolve our concerns for RWS, and it has agreed to take thefollowing steps:(a) Consider the addition of a structured field to set inclusions in RWS
submissions to allow for more concise characterisation of common
purposes for set membership.
(b) Improve transparency in Chrome’s UI by exploring how the structured
data from set submissions may be presented to users.

61.

In addition to these steps, our current view is that Google should:(a) Improve RWS governance, including by defining and implementing clear
policies relating to the Chrome team’s role in defining the use case-based
subsets, the set formation criteria, and the currently undefined process for
managing disagreements between the decision maker and RWS
submitter on whether a submission meets the criteria. Address feedbackon user control and user experience.

52

Federated Credential Management
Overview
62.

Federated Credential Management (FedCM) is intended to support federated
identity on the web following third-party cookie deprecation, allowing users tochoose which account to use to log in to a website via a dialog in the browser.
Google has said that identity federation has played a central role in raising thebar for authentication on the web compared to per-site usernames andpassword in terms of trustworthiness, ease-of-use, and security. 81

63.

Federated identity solutions currently rely on technologies such as iframes,
redirects and cookies – which provide vectors for user tracking across theweb, and would be restricted by Google’s Privacy Sandbox changes. Google
has proposed FedCM as a privacy-preserving solution to enable relying
parties (RPs) to provide users with a choice of identity providers (IdPs) for
sign-in and authentication.

64.

We are aware that both Mozilla and Apple are considering implementation ofa variation of FedCM tools in their browsers, and that standardisation
discussions are likely to continue in the newly chartered W3C Federated
Identity Working Group. 82
Potential concerns

65.

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

Potential concerns
Websites will use theclient_metadata_endpointand dialogs to obtain invalid
consent.

Provisional CMA views based on ICO’s preliminary
assessment
We understand that a website (RPs) can optionally use the client
metadata endpoint to return the site’s privacy policy and/or termsof service and display this, hyperlinked, in the Chrome-provided
sign-in dialog.
Under the Applicable Data Protection Legislation, valid consent forprocessing personal data must be freely given, specific, informed
and unambiguous. 83 Based on the ICO’s preliminary assessment,
we are concerned that websites (RPs) may rely on the sign-in
dialog and linked policies to obtain a user’s consent as the lawful

81 See Google Developer Blog on FedCM here (accessed on 22 April 2024).

82

For more information on the Federated Identity Working Group see here (accessed on 22 April 2024).
Article 4(11), Article 6(1)(a) and Article 7 GDPR. For more information on valid consent, see the ICO’s website
here (accessed on 22 April 2024).
83

53

Potential concerns

Provisional CMA views based on ICO’s preliminary
assessment
basis of processing. Google is planning to update its developer
guidance to make clear that presenting this information in the
dialog does not constitute consent. We remain concerned that asignificant portion of sites will use the Chrome FedCM dialog andclient metadata endpoint to attempt to obtain an invalid consent for
purposes beyond authentication.
We are continuing our discussions with Google on this point.

66.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the following potential concerns under D&I B – Digitaladvertising and D&I C – Impact on publishers and advertisers. In thetable below, we also include our updated views on each of the concerns
identified based on further submissions from Google and other market
participants since our last report was published in January 2024. New
concerns raised by stakeholders during the reporting period are included at
the end of the table.

Potential
concerns
FedCM might be
implemented in a
way whichnegatively
impactscompetition
between IdPs,
includingGoogle’s own‘sign in with
Google’, throughtechnical
complexity of
implementation.

CMA views in January 2024 report

Updated CMA views

We are working with Google andstakeholders to understand further the
impact of technical complexity on
IdPs which compete with Google.

Although Google has told us that it
disagrees that competition between
IdPs is relevant for the purpose of
assessing the impact of FedCM on
competition in digital advertising or
publishers and advertisers, it hasclarified that any technical complexity
in the implementation of FedCM for
IdPs is because it prioritised user
usability over ease of deployment
when designing the API. Google has
said that it has also sought tominimise technical complexity where
possible e.g. using existing IdPJavaScript SDK libraries that many
IdPs already provide, and that mostRPs auto-load into their websites.
Furthermore, Google has informed usthat it is developing features toincrease user choice of IdP. For
example, with Multi-IdP API, it isexploring ways to support multiple
IdPs to coexist cooperatively in the
FedCM account chooser. 84 We would
encourage it to continue these efforts.
In the absence of any further
stakeholder feedback, and based on

84

See issue #319 on the FedCM repository on GitHub here (accessed on 22 April 2024).

54

Potential
concerns

CMA views in January 2024 report

Updated CMA views

Google might
unfairly benefit
from greater useof federated ID
within advertisingsolutions, as
cross-domain
signals are
reduced.

Although we do not view support for ause case in which Google has aninterest to be, in itself, an act of selfpreferencing, we are keen tounderstand this dynamic further. We
would be concerned if Google
implemented FedCM in such a way
which benefited its own IdP and willcontinue to monitor this risk.

Google has told us that, although it
can envisage possible downstream
advertising use cases based on
signed-in users to various websites
and platforms, FedCM is not intended
to support advertising use cases, andhas not been designed withadvertising use cases in mind.

FedCM might
disintermediate
publishers,
restricting theirability to trackusers on theirproperty.

We consider this risk to be low giventhat it is the publishers’ choice
whether to support federated login as
opposed to managing user sign-inthemselves. However, we invite views
from publishers to understand if this isan outstanding concern.

Stakeholder have raised concernsthat FedCM could restrict publishers’
access to user email addresses,
which can be used in cross-site
identity resolution.

FedCM might notsupport thebroadest range offeatures, limiting
its effectiveness.

We are encouraged by engagementon GitHub with respect to additionaluse cases and will continue to monitor
the situation.

Google has told us that the initialdesign of FedCM was focused on
consumer federated identity use
cases, and that it is aware of API
details which need to be improved tosupport wider use cases. In particular,
Google has told us that its original
intention was for enterprise identity
use cases to rely on existing Chrome
enterprise policies. However, it has
now heard from enterprise identity
vendors that would prefer API-based
solutions. Google has told us this is
an area which it is actively
investigating.

the information currently available, we
do not consider that any technicalcomplexity for IdPs in implementing
FedCM will have a negative impact oncompetition between IdPs, including
Google’s own service, but we willcontinue to monitor developments.

We have asked Google to confirm
that it does not have any plans to use
personal data derived from its own
IdP, Google Sign-In, on third-party
sites for the targeting or measurementof digital advertising. We look forward
to receiving Google’s response on
this before coming to a view inrelation to this potential concern.

Based on the information currently
available, we do not consider that thisrepresents an outstanding concern.

Google has informed us of further
feedback it has received about thelack of cross-browser support for
FedCM.

55

Potential
concerns

CMA views in January 2024 report

Updated CMA views
We are aware that Google is working
to enable cross-browser support bycollaborating on developing FedCM
through the W3C Federated Identity
Community Group and W3C
Federated Identity Working Group.
Google has said that alternatives,
such as Storage Access API and
Cookie Access Heuristics, allow log-in
use cases to be addressed crossbrowser in interoperable ways.
We have been made aware of recent
stakeholder activity on GitHub raisingfurther use cases requests related to
FedCM. We will continue to monitor
the situation and encourageinterested parties to continue toengage on GitHub.

It may not be
feasible forindustry to adopt
FedCM ahead ofthird-party cookie
deprecation.

N/A

A stakeholder raised the point thathigh migration efforts and lack of
cross-browser standardisation meant
FedCM might not be a feasible shortterm solution at third-party cookie
deprecation.
In response, Google has told us that it
believes FedCM should be relatively
easy to implement but that it willcontinue to promote awareness andadoption of FedCM, including bysmaller IdPs. It also said it hopes thatthe recently launched W3C Federated
Identity Working Group will continue
to drive cross-browser support offederated identity solutions, and act
as a resource for developers to raisequestions and provide feedback.
We would invite further views fromstakeholders related to this potential
concern.

67.

As regards the application of D&I D – User experience, there are concerns
as to whether the user will receive sufficient transparency with respect to how
their data will be used for advertising purposes. Google has said that FedCM
allows IdPs to include links to the RP’s Terms of Service and Privacy Policy
on sign-in prompts. However, we remain concerned about the likelihood ofusers accessing the links and their ability to make informed decisions. Google
has also told us that it is looking into introducing a new ‘button flow’ feature
which would allow users to deliberately launch the sign-in screen, even if
there are settings enabled which normally block such prompts. We are56

continuing to discuss this and other changes to the FedCM user experience
with Google to ensure users can make effective choices.
Summary
68.

Google needs to resolve our concerns for FedCM and has agreed to take thefollowing steps:(a) Update its developer guidance to clarify that websites must not rely on
the client_metadata_endpoint and Chrome FedCM dialogs as valid
consent.

69.

In addition to these steps, our current view is that Google should:(a) Consider and respond with additional solutions that will further discourage
the use of the FedCM dialog box to obtain consent for purposes beyond
authentication.
(b) Confirm that it does not have any plans to use personal data derived fromits own IdP or Google sign-in on third-party sites for the targeting or
measurement of digital advertising.
(c) Continue to work closely with industry to support adoption ahead of thirdparty cookie deprecation, and eventually cross-browser standardisation.

Shared Storage API
Overview
70.

The Shared Storage API is a general purpose API that primarily supports twouse cases: (i) URL selection (including event level reporting to be deprecatedfrom 2026 onwards); and (ii) output for Private Aggregation API. It provides a
generic storage facility for cross-site data to meet legitimate use-cases thatwere previously facilitated by cross-site cookies.

71.

The API can be written to at any time into a shared data storage mechanism;however reads are restricted by ’output gates’, operation within secure
worklets (to prevent data exfiltration) and privacy-preserving mechanisms.

72.

The first gate is the content Selection output gate. This includes functionality
for creative rotation of ads, A/B testing, and a limited ability to provide trust
signals (although Google have made clear this only supports, not supplants,
Private State Tokens for this particular use case), among other functions. The
second gate is the Private Aggregation output gate, which sends reports to beaggregated and includes functionality for unique reach.
57

Potential concerns
73.

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

Potential concerns
At third-party cookie
deprecation, Shared Storage
API will be deployed without
a number of key technicalprivacy controls.

Provisional CMA views based on ICO’s preliminary
assessment
A range of planned PETs will not be implemented by Google until
at least 2026. These include: Fenced Frames; a replacement forevent level reporting and/or the enforcement of the Private
Aggregation API for measurement of the Select URL gate. We areconcerned that the absence of these features will allow API callers
to join user activity across sites.
Prior to the implementation of expected mitigations, Google has
implemented additional per-page entropy budget for the Select
URL gate. Based on the ICO’s preliminary assessment, we view
them as only partially effective. Google is exploring possible
monitoring of these controls to assess effectiveness against
misuse.
The ICO has told us that without these PET controls, the privacyguarantees are significantly undermined for the Select URL Gate,and that the Shared Storage API may not mitigate key issues the
ICO identified in the 2019 Report and 2021 Opinion.
We are working with the ICO and Google to understand further
details on Google’s proposed governance approach, and this will
include understanding if alternative assurances can be provided
ahead of 2026.

Future ‘gates’ may be added
to the Shared Storage API,and this may change the risk
profile of the API and
potentially wider Sandbox
Proposals.

We understand that, in the future, additional output gates may be
added to the Shared Storage API (e.g. in addition to the Select
URL and Aggregate Reporting gates). We are concerned that new
products/features added to the proposal will introduce additionalrisk to users that cannot be evaluated at the time of writing.
Google has said that its intent is to add meaningful functionality
without undermining privacy limitations of this and other Privacy
Sandbox APIs. Google is considering how a decision-making
process might be established to govern the addition of new use
cases to the Shared Storage API.
We await further information from Google and will consider this aspart of our wider work looking at governance and future decisionmaking.

Key controls, such as epsilon
values and rate limits, havenot been tested.

For the Private Aggregation API, as with the ARA API, we
understand that key controls (e.g. epsilon values and contribution
budgets) have been initially set as placeholders/‘strawmen’ during
testing and adoption of the API.
We are concerned that key controls and parameters for the Private
Aggregation API have not been effectively tested to establish the
optimum balance between utility and privacy. There is also a
concern that Google will not be able to gather useful feedback from
Private Aggregation ‘customers’ as API callers are likely to have a58

Potential concerns

Provisional CMA views based on ICO’s preliminary
assessment
vested interest in preserving maximum utility. Effective testing is for
Google to define.
Google has said that the current epsilon parameter can berevisited over time as technical improvements are made to theaggregation service. Google is exploring how they will work withcustomers to test and migrate to new epsilon values over time.

74.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the potential concerns under D&I B – Digital advertising and D&I
C – Impact on publishers and advertisers.

75.

The CMA does not currently have any specific or immediate major concerns
for this API, especially as it is primarily used to support or extend other
Privacy Sandbox APIs or as a general use API. Given its supporting role,
however, future governance and monitoring will be important.

76.

As regards the application of D&I D – User experience, the ICO has
expressed concern that the use cases fulfilled by the Shared Storage API are
not clearly presented to the user. Google has accepted this and has agreed torefresh the UI. We await more information on this.
Summary77.

Google needs to resolve our concerns for Shared Storage API, and it has
agreed to take the following steps:(a) Provide more information on governance and decision-making processes
and ensure these are adequate.
(b) Reconsider and update the UI.
(c) Consider how it will work with customers to test and possibly migrate to
new epsilon values over time.

Cookies Having Independent Partitioned State
Overview
78.

Cookies Having Independent Partitioned State (CHIPS) is intended to support
the embedding of third-party services within webpages after third-party cookie

59

deprecation, without re-enabling cross-site tracking. 85 It enables developers toread and write cookies from cross-site contexts, such as iframes, in a strictly
partitioned manner such that a cookie may only be accessed within thecontext of the top-level site where it was set. 86 Third parties who set
partitioned cookies on separate webpages are not able to join up thisinformation.
79.

Google has said that CHIPS is necessary to support users’ expectations ofbusinesses on today’s Internet and to facilitate website functionality such as:(a) Third-party embedded services including chat, maps, and payments;(b) Third-party Content Delivery Networks servicing access-controlled content
which must be authorised by the first-party site; and(c) Embedded ads relying on per site frequency capping or user preferences.

80.

Other browsers have considered measures to address these use cases.
Firefox’s solution involves partitioning all third-party cookies by default, while
Safari previously attempted to partition based on heuristics before instead
blocking all third-party cookies.

81.

CHIPS takes a different approach and requires developers to explicitly opt-in,which Google has said will reduce confusion and unexpected bugs. CHIPS isbeing discussed in W3C’s Privacy Community Group and appears to bemoving towards cross-browser support, with outstanding discussion relating toperformance and memory rather than security or privacy concerns. 87
Potential concerns

82.

The ICO has not raised any concerns under D&I A – Privacy outcomes for
CHIPS.

83.

We have considered the following potential concerns under D&I B – Digitaladvertising and D&I C – Impact on publishers and advertisers. In thetable below, we also include our updated views on each of the concerns85

An overview of the CHIPS proposal can be found here (accessed on 22 April 2024).
Google provides the following illustrative example: ‘For instance, when chatvendor.com is embedded on site
A.com, it could request a “Partitioned” cookie to be set. Later, when chatvendor.com is loaded on site B.com, itcannot access the cookie and associated data set by it when it was previously loaded on A.com. chatvendor.com
cannot join cookies that it sets across A.com and B.com to track users across the web, but chatvendor.com’s key
functionality of knowing who a user is across successive visits to a specific top-level site is still possible – without
A.com or B.com having to trust chatvendor.com more than they do today’.
87
See Chips repository on GitHub here (accessed on 22 April 2024).
8660

identified based on further submissions from Google and other market
participants since our last report was published in January 2024. New
concerns raised by stakeholders during the reporting period are included at
the end of the table.
Potential
concerns

CMA views in January 2024 report

Updated CMA views

The partitioningof cookies bydomain may
reduce the abilityof ad techs tocompete on thetargeting andmeasurement ofadvertising basedon cross-domain
tracking.

We accept that a reduction in crossdomain tracking is necessary toachieve the privacy benefits of thirdparty cookie deprecation. We willconsider this balance as part of ouroverall assessment of Google’s
proposals.

We have not received any further
feedback related to this potential
concern following our January report.
As previously noted, we accept that a
reduction in cross-domain tracking isnecessary to achieve the privacy
benefits of third-party cookie
deprecation. We will consider thisbalance as part of our overall
assessment of Google’s proposals.

CHIPS might be
implemented insuch a way which
does notsufficiently
enableadvertising use
cases.

We would like to understand further
the extent to which CHIPs preserves
existing advertising use cases.

Google has told us that CHIPS is notintended for ads use cases. We agreewith Google’s assessment in thiscase. CHIPS is one of several Privacy
Sandbox APIs that is aimed ataddressing non advertising use-casesthat will be impacted by third party
cookie deprecation such as sign-on
systems.

The partitioningof cookies bydomain may
reduce theeffectiveness oftools for thetargeting andmeasurement ofadvertising basedon cross-domain
tracking.

We accept that a reduction in crossdomain tracking is necessary toachieve the privacy benefits of thirdparty cookie deprecation. We willconsider this balance as part of ouroverall assessment of Google’s
proposals.

We have not received any further
feedback related to this potential
concern following our January report.

CHIPS might be
implemented withinsufficient
memory toenable the thirdparty services
required by, inparticular, small
publishers.

Google continues to make best efforts
to ensure CHIPS is implemented with
sufficient memory to support thegreatest range of use cases. We arealso pleased to see Google’s
engagement with other browsers, andwillingness to make changes in orderto progress CHIPS towards
standardisation.

Our view remains unchanged.

CHIPS may
impact the abilityof publishers tooffer SSO sign-inservices basedon authenticatedembeds.

We note Google’s intent to support
authenticated embed use cases
through Storage Access API with user
prompts and continue to monitor. We
would also like to understand theextent to which FedCM mitigates thisconcern by enabling SSO sign-in use
cases.

Google has since implemented a fix
for this in Storage Access API. We
welcome further feedback on theextent to which this fix resolves
stakeholder concerns.

61

As previously noted, we accept that a
reduction in cross-domain tracking isnecessary to achieve the privacy
benefits of third-party cookie
deprecation. We will consider thisbalance as part of our overall
assessment of Google’s proposals.

Potential
concerns

CMA views in January 2024 report

Updated CMA views

Implementationof both ‘normal’cookies andCHIPSpartitioned
cookies for SSO
during thetransition period
will create
significant
overheads formarketparticipants.
Even where
Storage Access
API is modified toresolve issues in
CHIPS, there is
not yet aconsistent crossbrowser
implementation ofStorage Access
API so this will
increase costs formarketparticipants.

N/A

This will be an ongoing concern for
CHIPS and other APIs where old andnew methods are operating inparallel. We welcome feedback fromstakeholders on the impact of thisissue. We have asked Google toconsider ways it can mitigate thesetransition costs.

N/A

Google has told us that it is making
progress with standardising both
Storage Access API and CHIPS
across browsers. Mozilla isimplementing CHIPS and Google iscurrently in discussion with Webkit(required for all iOS browser
implementations) regarding CHIPS
implementation. Mozilla have shippeda modified specification of the newly
specified Storage Access API that
reduces implementation differences.

84.

As regards D&I D - User experience, we have concerns around the user
controls for CHIPS and first-party cookies not being distinct from each other.
Google in response has said that distinct controls could lead to significant
breakage risk, user confusion and lack of meaningful privacy improvement.
We are continuing to engage with Google to ensure adequate user controls
for CHIPS.
Summary85.

Google needs to resolve our concerns for CHIPS and our current view is that
this should involve taking the following steps:(a) Ensure that the ability of publishers to offer single sign-in services via
authenticated embeds is preserved, especially during the transition period
where stakeholders (including and especially non-ad tech stakeholders)
may experience significant overheads in maintaining support for both oldand new methods.
(b) Ensure that CHIPS is implemented with sufficient memory to enable thirdparty applications relied upon by publishers.
62(c) Help mitigate costs for stakeholders who have to maintain parallel stacks
in the lead up to third-party cookie deprecation.
(d) Work towards a consistent cross-browser implementation of Storage
Access API where it affects CHIPS users.
Fenced Frames
Overview
86.

Fenced Frames aims to enforce a boundary between a webpage and any
cross-site content it embeds, such that user data cannot be joined up between
the two sites. Under Google’s PA proposal, Chrome renders the winning ad ina Fenced Frame. The requirement to render winning ads within Fenced
Frames will be enforced no sooner than 2026. 88

87.

Google is continuing to make gradual progress in enabling various Fenced
Frames solutions, illustrated by the increased GitHub explainer updates from
October 2023. Fenced Frames does not support the same use cases as
iframes currently. For example, PA supports video rendering using amechanism that relies on iframes, and Google has not yet designed a solutionthat is compatible with Fenced Frames, which could significantly impact
advertisers’ revenue.
Potential concerns

88.

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

Potential concerns
Outstanding cross-site
tracking risks remain
unmitigated.

88
89

Provisional CMA views based on ICO’s preliminary
assessment
We note that the Fenced Frames proposal currently
maintains a range of unmitigated cross-site tracking risks. 89
The ICO’s 2021 Opinion sets out its expectation that
proposals must address existing risks, as well as considering
any new risks that are introduced and how these will be
mitigated before any processing takes place in order tocomply with Applicable Data Protection Legislation.

The timelines of pending PA API capabilities can be found here (accessed on 22 April 2024).
See the Fenced Frames Explainer here (accessed on 22 April 2024).

63

Once we receive further updates on how Google is planningto address these risks, we will consider whether ourconcerns have been resolved.

89.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the following potential concerns under D&I B – Digitaladvertising and D&I C – Impact on publishers and advertisers. In the tablebelow, we also include our updated views on each of the concerns identified
based on further submissions from Google and other market participants
since our last report was published in January 2024.

Potential
concerns
Fenced Frames
does notcurrently
support use
cases such as
native andvideo
advertising,which may
impact theability of
publishers toeffectively
monetise theircontent.

CMA views in January 2024
reportGoogle should implementchanges to enable these key use
cases before requiring ads torender in Fenced Frames.

Updated CMA views

Fenced Frames
does notsufficiently
support brandsafety.

N/A

A stakeholder raised a concern
that, by restricting information
about page context, Fenced
Frames does not sufficiently
enable advertisers to ensure
brand safety.

See PA API section above.

Google has said in response thatadvertisers can ensure brandsafety within Fenced Frames byanalysing the page URL during
the contextual auction, andpreparing perBuyerSignals which
can be used to filter out ads which
do not meet brand safety
standards.
We welcome further feedback
from stakeholders on this concern.

64

Potential
concerns
Fenced Frames
does notsufficiently
supportexpandable ads
use cases.

CMA views in January 2024
reportN/A

Updated CMA views
A stakeholder raised a concernthat Fenced Frames does not
sufficiently enable advertisers todisplay expandable ads.
Google has confirmed that
expandable ads use cases are notintended to be supported.
According to Google, a key
privacy goal of Fenced Frames isthat the surrounding web pagecannot learn what ad is being
rendered, which would benecessary in order to support
expandable ads.
We welcome further feedback
from stakeholders on this concern.

90.

Currently, we do not have any outstanding concerns in relation to theapplication of D&I D – User experience.
Summary91.

Google needs to resolve our concerns for Fenced Frames and our current
view is that this could involve taking the following steps:(a) Provide further assurances on how it will mitigate cross-site tracking risks
within Fenced Frames.
(b) Continue to engage with industry on the design of Fenced Frames,
including by not enforcing its requirement until major ad formats aresupported.

Fighting spam and fraud on the web
Private State Tokens
Overview
92.

Private State Tokens (PST) enables trust signals to be transmitted between
websites to determine whether a user is trustworthy or engaged in spam or
fraud without allowing the user’s identity to be discovered across sites.
Instead, the PST aims to enable sites to collaborate in segmenting users into
‘trusted’ and ‘untrusted’ categories. To do so, a website that has alreadyestablished a user’s trustworthiness would be able to issue that user’s
65browser with PSTs. 90 These tokens could then be redeemed on otherwebsites establishing trust without identifying the user or providing informationon the origin of the token. The tokens themselves will allow for limited
information to be communicated.
93.

As part of the registration process for becoming a PST issuer, issuer websites
need to declare the intended purpose of the tokens. By design, it is notpossible to easily determine the purpose of a token. Therefore, while Google
may be able to infer some misuse of PST tokens over time, it is not easily
detectable.
Potential concerns

94.

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

Potential concerns
PST can be used for
purposes wider than antifraud or in ways that are
unfair to the user.

Provisional CMA views based on ICO’s preliminary
assessment
We understand that PST allows token issuers to assign a user oneof six values when issuing tokens that may be based on,
potentially, non-transparent issuer-defined metrics. Based on thisunderstanding and the ICO’s preliminary assessment, we areconcerned that:••

Tokens may be used to assign values to users forpurposes other than anti-fraud/security etc.
Tokens may intentionally or unintentionally influence auser’s browsing experience in a way which is unfair.

We understand that the PST enrolment process only conducts
technical checks and does not review the purpose and means ofprocessing undertaken by the issuer.
Google has said that with expected key rotation, in practice, anissuer will not be able to use all six metadata values
simultaneously. Additionally, as sites are limited to two issuers
only, it is Google’s view that sites will not want to ‘waste’ a limited
anti-fraud capability on a relatively poor cross-site tracking tool.
Further, Google believes that improvements to the issuer
declaration process (see below) can assist with preventing misuse
of PST.
Google has agreed to make it clearer that PSTs are ‘not intended
to convey arbitrary cross-site information’. 91
We discussed with Google the possibility of removing token issuers
if clear misuse was identified. On this final point, we await further
detail on Google’s wider approach to governance.

90
91

This website is known as the ‘issuer’. Any website can issue PSTs.
See the Private State Token API Explainer here (accessed on 22 April 2024).

66

The purposes of tokens are
not made sufficiently clear byissuers.

As regards the transparency of PST for users, we observe:
•
•
•

•

Registered PST issuers are recorded publicly in a JSON
file stored in the PST GitHub. 92
Each issuer’s application may also be viewed in the GitHub
issues where it was submitted. Purposes for PST use are
declared in a free text field and are not validated.
In the Chrome UI, information regarding PST is exposed
via a setting called ‘Auto-verify’, but with no information
linking to the third parties providing the services or their
purposes for processing.
Chrome is reliant on site owners using third party issuer
services to provide relevant information to consumers andmaintain relevant data protection compliance.

From the observations above, we are concerned individuals will not
be able to clearly understand all use cases PST may address now
and in the future.
Google has agreed to include the purposes from the issuer
application directly in the JSON file and is exploring updating theopen text field to a defined list. Additionally, Google has agreed toincrease visibility of the guidance for the use of PST in developer
documentation. Also, Google is considering updates to the PST(‘Auto-verify’) Chrome UI to make clearer to users the purposes ofprocessing and the roles third parties are likely to undertake.

95.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the following potential concerns under D&I B – Digitaladvertising and D&I C – Impact on publishers and advertisers. In thetable below, we also include our updated views on each of the concerns
identified based on further submissions from Google and other market
participants since our last report was published in January 2024.

Potential
concerns
PST could
centralise
Google’s powerby requiring sites
to rely on Google
to determine
whether a user
should betrusted.

CMA views in January 2024 report

Updated CMA views

While any entity can become a PST
issuer, we believe it is conceivablethat the main issuers will be wellknown sites that most people visit.
Given that Google owns several
domains that are among the mostvisited sites, it is in a strong position
to become a prominent and trusted
issuer that is relied on by many sites.

Google has told us that it does not
currently envisage issuing/using
PSTs. Our understanding is that theuse of PSTs is optional and that antifraud organisations can rely on othersignals besides PSTs.
However, we have received further
concerns from stakeholders regarding
the risk to competition of Google
becoming a dominant issuer of PST
tokens.
Given the above, we have evaluated
two possible solutions to this concern.

92

See the Private State Tokens issuers recorded here (accessed on 22 April 2024).

67

Potential
concerns

CMA views in January 2024 report

Updated CMA views
One of the options we considered
was for Google to formally agree not
to enter the market for PSTs in future.
Alternatively, we suggested that thedesign of PSTs could be modified to
introduce a limit on the number ofpartner websites that can redeem
tokens from an issuer, to reduce therisk of issuer dominance.
After careful consideration anddiscussions with Google, we came tothe view that these potential solutions
would not be appropriate given thelimited evidence that this concern
would lead to a material impact oncompetition in the ad tech market.
Google has reassured us that the useof PSTs issued by Google will not be
required, and that redeemers will beable to consume PSTs issued by athird-party other than Google.
Moreover, Google has said that thelargest proportion of adoption andinterest in becoming PST issuers hascome from small and midsize
businesses. Furthermore, it is unlikelythat any one issuer would be relied onby many sites. Google has said that
this is because anti-fraud use-cases
span a wide range of threats, so
different verticals would likely havetheir own issuers.

Google could
abuse its position
as a dominant
PST issuer.

To mitigate the risk to competition of
Google becoming a dominant issuerof PST tokens, we recommend that
Google provide policy or technicalsafeguards that would prevent it fromabusing its position. This could be
enforced through the registration andgovernance mechanisms that have
yet to be clarified in the PST proposal.
We would particularly welcome
governance policies that specify why
certain issuers might be disallowedfrom issuing PST tokens.

Google informed us that it is working
to define objective criteria on how
PSTs can be used, and thecircumstances in which an issuer
would be removed for violating thosecriteria. Google envisages publishing
this guidance ahead of third-party
cookie deprecation.

There will not beenough choice of
PST issuers.

Our understanding is that Google has
already provided demos and guides
to help with setting up and running an
issuer, but this does not guaranteethat there will be enough competitionand enough choice of issuers that arebroadly trusted. To obtain greater
assurance on this, Google could
provide a target for how many PST
issuers are expected to exist (and be

Google has told us that it is actively
seeking to encourage adoption andincrease the number of PST issuers.
Google also considers it likely that theuse of PST for anti-fraud use cases
will span a wide range of threats, so
there would be a variety of issuersthat specialise in different verticals.

68Potential
concerns

96.

CMA views in January 2024 report

Updated CMA views

actively used to redeem tokens) by
the time third-party cookies are
deprecated.

We have not received further
feedback from stakeholders on thispoint. We will continue to monitor
developments.

As regards the application of D&I D – User experience, our understanding isthat PST is enabled by default (except for those who had previously blocked
third-party cookies), although users can opt-out or otherwise negate thefunctioning of PSTs using an ‘Auto-verify’ feature in Chrome. As mentioned in
the D&I A – Privacy outcomes section above, given that PST currently
permits a non-exhaustive range of use cases, we are concerned that market
participants may use PST data for purposes besides verification. We consider
this to be problematic, as users will not be made aware of the other purposes
for which their data may be used. In response to our concerns, Google isexploring ways to ensure better transparency of how PSTs may be used andto prevent misuse of PSTs. We are continuing to engage with Google on thisand other concerns relating to user experience, including around PST user
controls.
Summary

97.

Google needs to resolve our concerns for PST, and it has agreed to take thefollowing steps:(a) Provide clear registration and compliance guidance for PST issuers inpublished guidance. The guidance will specify that PSTs should not be
used for purposes other than anti-fraud and Google is exploring amechanism for users to report complaints about potential misuse.
(b) Improve transparency for users on the purpose of PSTs by including thisinformation in the issuer application and increasing the visibility of relevant
guidance.
(c) Update the PST (‘Auto-verify’) Chrome user interface to make clearer tousers the purpose of processing and third-party roles.

69

Limiting covert tracking
Bounce Tracking Mitigations
Overview
98.

Bounce Tracking Mitigations (BTM) is intended to address cases where sites
use a ‘stateful bounce’ to identify users across different sites. A ‘statefulbounce’ allows sites to replicate the cross-site tracking functionality of thirdparty cookies. For example, the user navigates to Site A, Site A redirects theuser to Site B, Site B accesses state (e.g. sets a cookie, accesses local
storage, and so on) and redirects the user again either back to Site A or toanother site.

99.

These redirects can happen quickly, and users may not be aware of them.
Google’s implementation of BTM relies on user interaction. If the user hasinteracted with the site that they are redirected to (Site B in our example
above) within the last 45 days, the ‘stateful bounce’ will be allowed, otherwise
the state (e.g. the cookie set by Site B in our example) will be deleted.

100.

Google has identified some use cases that rely on stateful bounces that willcontinue to work because they involve user interaction. These use cases
include: (i) federated authentication, (ii) single sign on; and (iii) payments. 93
Google has invited specific feedback on whether user interaction is the mostappropriate signal to indicate that the stateful bounce is part of a use casethat should be supported under BTM. 94
Potential concerns

101.

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

Potential concerns
Sites frequently visited byusers will still be able to use
bounce tracking.

Provisional CMA views based on ICO’s preliminary
assessment
We are concerned that large sites, that may retain a large
percentage of a population group as monthly active users, would
still be able to undertake effective bounce tracking.
We are currently discussing this with Google and we will provide an
update in the next quarterly report.

93

An overview of out-of-scope use cases can be found here (accessed on 22 April 2024).
See issue #24 on the Navigation-based Tracking Mitigations repository on GitHub here (accessed on 22 April
2024).

94

70

102.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the following potential concerns under D&I B – Digitaladvertising and D&I C – Impact on publishers and advertisers. In thetable below, we also include our updated views on each of the concerns
identified based on further submissions from Google and other market
participants since our last report was published in January 2024. New
concerns raised by stakeholders during the reporting period are included at
the end of the table.

Potential
concerns
There is a riskthat the current
implementation of
BTM will
disadvantage
competitors that
rely on legitimate
use of browser
storage.

CMA views in January 2024 report

Updated CMA views

Our understanding is that the userinteraction requirements of BTM may
undermine the ability of competitorsand other stakeholders in the Privacy
Enhancing Technology (PET) market
to use redirect flows for legitimate
purposes. Google’s response to thisissue 95 recommends using additional
consent flows or the Storage AccessAPI. However, we were informed bystakeholders that these options would
add an unacceptable level of user
friction that would break their use
case.
We are continuing to discuss with
Google how these concerns may beresolved. This includes exploring analternative implementation of BTM
that could use list-based approaches
to identify trackers, or adapting theShared Storage API in a way thatwould allow legitimate use of browser
storage by PETs.

Stakeholders have reiterated theirconcern that Google is placing
disproportionate user interaction
requirements on alternative solutions
beyond what is required by dataprotection law. Specific stakeholder
proposals for resolving the issue haveincluded an ‘allow list’ approach,where Google would be required tofacilitate access to bounce tracking
and unpartitioned client-side storage
for alternative solutions whose crosssite data processing has been
accredited by an independent
external auditor. We are discussing
the feasibility of this proposal andalternative approaches with Google.

Sites that are
regularly visitedby users (i.e.
more than once
every 45 days)
will still be able touse bounce
tracking.

We are concerned that Google would
be able to circumvent the protections
provided by BTM because of the large
volume of user interactions that
Google sites receive. This could give
Google an advantage overcompetitors that have smaller
audiences.
We have asked Google to confirm
that it will not use bounce tracking
outside of their accepted use cases(e.g. login and payments).

We are currently discussing thisconcern with Google, and we will
provide an update in the next
quarterly report.

95

See issue #64 on the Navigation-based Tracking Mitigations repository on GitHub here (accessed on 22 April
2024).

71

Potential
concerns
There is a riskthat BTM will
reducecompetitors’ability to use linkdecoration.

CMA views in January 2024 report

Updated CMA views

We have received concerns that
Google’s implementation of BTM
tampers with URL strings.
Our understanding is that linkdecoration is not affected in thecurrent implementation of BTM orother Privacy Sandbox proposals.

Our views remain unchanged.
However, as noted in the D&I A
section for ARA, our understanding isthat link decoration currently allows
ad techs to join a user’s identity
across sites via navigation events.
Google has pointed to a range of anticovert tracking (ACT) efforts thatstrive to make covert tracking morechallenging. We will review ourposition in response to any further
details or controls that may be sharedby Google in response to the concern
around navigation tracking.

There wasinsufficientindustry
consultation
before therelease of BTM.

Industry stakeholders have had theopportunity to comment on Google’s
BTM proposal since it was announced
publicly in September 2022. Possible
avenues for stakeholder engagement
include the corresponding GitHub
repository 96 and relevant W3C
groups.

Our views remain unchanged.

BTM currently
has a bug thatcauses it todelete Privacy
Sandbox API
storage.

N/A

Google has told us that it has
identified cases where BTM clearedstorage related to Privacy Sandbox
APIs, and that this primarily affects adtechs using their own domains for
click tracking and API calls.
Google estimates that the current
impact of this bug is minimal, affecting
less than 1% of users in the Mode-B
experiment. Google has disabled
BTM in Mode B Chrome-facilitatedtesting experiment traffic until a fix is
confirmed.

103.

96

As regards the application of D&I D – User experience, we consider that
Google has taken adequate precautions to ensure that BTM does notadversely affect user experience. Such precautions include periodic reviews
and deletion of stored data only if the user has not interacted with a site in 45
days, as well as a 1-hour grace period that allows the user to complete theirinteraction before the site host’s storage is deleted. These precautions help tominimise the impact of BTM on legitimate use cases such as payment flows.

See the Navigation-based Tracking repository on GitHub here (accessed on 22 April 2024).

72

104.

We will continue to monitor how BTM impacts user experience in technologies
that currently rely on redirection and browser storage for legitimate use cases(e.g. PETs and authentication).

105.

Although BTM will not be enforced until after third-party cookie deprecation,
BTM is currently available for testing/use by anyone who has already blocked
third-party cookies. This gives stakeholders and users an opportunity tomonitor and feedback on the impact of BTM on user experience before it
becomes fully operational.
Summary106.

Google needs to resolve our concerns for BTM, and our current view is that
this should involve taking the following steps:(a) Resolve concerns related to the disproportionate consent requirements
imposed by BTM on alternative solutions, potentially making it harder forcompetitors to use redirect flows for legitimate use cases.
(b) Confirm that the current BTM implementation would not allow sites with alarge first party presence (like Google’s sites) to use bounce tracking. We
are waiting for Google’s confirmation on this point.

User-Agent Client Hints/User-Agent Reduction, IP Protection, DNS-over-HTTPS,
Storage Partitioning and Network Partitioning
Overview
107.

The purpose of User-Agent Client Hints (UA-CH), which follows from UserAgent Reduction (UAR), is to limit passive fingerprinting of users, limiting theamount of information the browser automatically delivers about the user to the
web server it interacts with through the User-Agent String. The User-Agent
String is transmitted as a request header in every HTTP exchange between
client and server. The process is generally opaque to users. UA-CH therefore
enforces a model whereby the server must actively request identifying details
about the client that could be used for fingerprinting (e.g. device model) rather
than passively receive them.

108.

DNS-over-HTTPS is a protocol that encrypts the interactions between client(browser) and Domain Name System (DNS) provider to enable further privacy
protection for browsing habits, preventing surveillance of sites
requested/visited. DNS-over-HTTPS also prevents active attacks that attempt
to divert browser-traffic to malicious servers (a common attack in public wi-fi
settings such as cafes and airports, including for phishing purposes). As a73

further security measure, DNS-over-HTTPS traffic can also be mixed withother HTTPS traffic on the same connection.
109.

IP Protection is a proposed privacy feature in Chrome that aims to avoid
sharing a user's real IP address with eligible third parties. Under the current
proposal, a privacy proxy will be used to anonymise eligible users’ IP
addresses. 97 Google will use two proxies where the first is run by Google andthe second by an external content delivery network (CDN). Google’s aim is to(i) stop a destination website from seeing a user’s original IP address and (ii)prevent any single proxy from seeing both the user’s original IP address andtraffic content.

110.

Storage Partitioning isolates some web platform APIs used for storage orcommunication if used by an embedded service on the site, i.e. in the thirdparty context.

111.

A browser’s network resources, such as connections, DNS cache, andalternative service data are generally shared globally. Network State
Partitioning will partition much of this state to prevent these resources frombeing shared across first-party contexts. To do this, each request will have anadditional ‘network partition key’ that must match in order for resources to bereused.
Potential concerns•

112.

User-Agent Client Hints/User-Agent Reduction

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

Potential concerns‘Critical Hints’ is likely to be
used for non-compliant
fingerprinting.

Provisional CMA views based on ICO’s preliminary
assessment
The key difference between the User-Agent String and UA-CH isthat UA-CH changes the model of receiving information frompassive to active. Rather than a site passively receiving all theavailable information for requests, UA-CH requires the site to makeactive requests for the hints it needs, in such a way that a browser
may observe such calls and intervene, depending on site
permission policies. In theory, this should be beneficial for user
privacy, as the amount of information made available by default
has been reduced.

97 An overview of the IP Protection proposal can be found here (accessed on 22 April 2024).

74

The ICO has told us that this proposal has limited effectiveness asa stand-alone anti-fingerprinting tool and would ideally work
alongside other Privacy Sandbox proposals. The ICO considers
that the effectiveness of this proposal has been undermined by thedeprecation of the Privacy Budget proposal and the limited scopeof the IP Protection proposal.
We await more information from Google to better understand thefuture intent for this API given the demise of Privacy Budget.

113.

Based on stakeholder feedback and our own analysis of the API, we haveconsidered the potential concerns under D&I B – Digital advertising and D&I
C – Impact on publishers and advertisers.

114.

Although we do not currently have concerns about UA-CH/UAR, we are keen
to ensure that Google does not remove or limit access to critical hints in the
future. A stakeholder has drawn our attention to a research paper 98 publishedlast year that studied the use of UA-CH on thousands of websites. The paper
notes that Google accounted for both the overwhelming majority of ‘criticalhint’ requests (high entropy, potentially identifying) and exfiltration of this data
to external servers. We are awaiting comment from Google.

115.

We have also asked Google to clarify its normative language in the UA-CH
developer documentation giving the directive that sites ‘should not’ makeheavy use of critical hint requests as this implies Google may impose some
restriction in the future. Given the evidence above that Google is currently the
primary consumer (and exfiltrator) of critical hint data we want to emphasise
the importance of not restricting this capacity for other market participants.

116.

We are only considering the application of D&I D – User experience where
we are looking at a user-facing API and so have not reviewed UA-CH under
this criterion.
•

117.

IP Protection

After consulting with the ICO, we have considered the following potential
concerns under D&I A – Privacy outcomes. In the table below, we also
include our provisional views on each of the concerns identified.

Potential concerns

98

Provisional CMA views based on ICO’s preliminary
assessment

See Senol and Acar (2023) here (accessed on 22 April 2024).

75

Users must sign into their
Google account to benefit
from IP Protection.

We understand that the IP Protection proposal is still underdevelopment. If Google requires users to be signed-in to a Google
Account to authenticate and thereby limit fraudulent behaviour, weare concerned that users will not be able to benefit from thisPrivacy Sandbox proposal without agreeing to wider terms andconditions associated with signing into a Google Account. This
limits the overall benefit of the proposal.

The proposal requires
Google to take account of:• defining andmonitoring tracking
activity;• authenticating users;• contracting aContent Delivery
Network (CDN); and• managing andupdating a block list.

Together with the ICO, we require further information to inform ourview in four areas: monitoring tracking activity; the authentication ofusers; the relationship with the CDN; and the management of a
block list.

118.

As regards IP Protection, based on stakeholder feedback and our own
analysis of the API, we have considered the following potential concerns
under D&I B – Digital advertising and D&I C – Impact on publishers andadvertisers. In the table below, we also include our updated views on each of
the concerns identified based on further submissions from Google and othermarket participants since our last report was published in January 2024.

Potential
concerns
Google may
continue tobenefit from user
activity data while
limiting
competitors’
access to thesame data.

CMA views in January 2024 report

Updated CMA views

We may suggest that Google
removes itself from the first ‘hop’ anduse a second independent third-party
instead. We will also need tounderstand whether data collected
through sign-ins can be used in
Google advertising and whether
requiring user sign-in for IP Protection
could be replaced by alternativemeans for user authentication.

Given the underlying technologies
and design for IP Protection in its
current state, we do not consider that
there would be significant benefit incompelling Google to relinquish thefirst hop, especially as the design now
requires a Google login to activate IP
Protection.

76

Furthermore, the requirement for a
Google login will inevitably reduce
uptake and, therefore, further reduce
the overall footprint of IP Protection,
mitigating both utility concerns (fewer
Chrome browsers will engage IP
Protection) and specific privacy
concerns regarding an associatedGoogle login. The design – if
implemented as stated – will prevent
Google from benefiting from the login
requirement and their administrationof the first hop and given IP
Protection will not be fully deployed
until well after third-party cookie
deprecation, this primarily becomes afuture governance issue.

Potential
concerns

CMA views in January 2024 report

Updated CMA views

Google’s ability tocontrol the
inclusion of ad
tech rivals on thislist could
advantage its adtech services,
especially if they
are not subject tothe same
restrictions in the
future.

Google will need to provide further
detail on the governance process. We
may suggest that independent thirdparty governance be required toensure fairness and transparency.

We welcome further clarity from
Google regarding future governancearrangements – especially regarding
the final form, or source, of the tracker
list.

Competition
betweenproviders of VPN
services may beforeclosed.

This is beyond the scope of theCommitments but an issue that wewill consider where appropriate.

Our view remains unchanged.

Publishers andadvertisers that
rely on IP
addresses forgeographicallytargeting andpersonalisingcontent will beforced to offer aworse service.

The provisions for GeoIP within IP
Protection proposals will allow ad techand publishers to continue to optimise
content to approximate geographic
location. As with the Topics API, there
may be no ‘right’ level of granularity
for all market participants. We willneed to consider loss of precision intargeting against privacy benefits.

Coarse GeoIP data will serve mostuse cases and, in any event, will only
apply to those trackers on the final
tracker list, in third party contexts andwill only be functional for signed inusers.

Publishers andadvertisers may
be less able toeffectively identify
fraudulent
activity.

We will need further specifications
from Google on how block lists orother options will be applied.

For other use cases such as antifraud or anti-spam, Google is offeringother APIs such as PST and Shared
Storage (SelectURL can be used toindicate trust level for the client, forexample).

Google may
provideinsufficient notice
for ad techs to
implement
alternative
solutions with
their publishers
and test andcomment back on
proposals.

We will need Google to clarify andseek feedback on sufficient notice tobe provided to ad techs to implement
alternative solutions with their
publishers and test and comment
back on proposals.

A stakeholder has asked that Google
provide a minimum notice period of
12 months to implement alternative
solutions. We have not received
feedback from Google on this specificsuggestion.

However, we would welcome further
consideration from both Google andthe wider ecosystem of alternatives(for anti-abuse purposes) to theGoogle login requirement as thedesign continues to evolve in future.

77

119.

As regards the application of D&I D – User experience, as the IP Protection
proposal develops further, we will keep the relevant user experience underreview to ensure users have adequate choice and control.
•

DNS-over-HTTPS, Storage Partitioning and Network Partitioning120.

DNS-over-HTTPS, Storage Partitioning and Network Partitioning areclosely aligned with implementations by other browsers with the common aim
of improving online privacy. The ICO has not raised any concerns. At present,
we do not have any concerns under any of the D&I Criteria regarding these
APIs.

121.

Furthermore, DNS-over-HTTPS will be removed from the list of proposals weare monitoring as it is not Privacy Sandbox specific. However, Google willkeep us updated of any substantive design changes.
Summary122.

Google needs to resolve our concerns for UA-CH/UAR and IP Protection andour current view is that this could involve taking the following steps:(a) As regards UA-CH/UAR:(i) Provide more information to better understand what limits are placedon access to critical hints.
(ii) Provide assurances that it will not further remove or limit access tocritical hints in the future, especially in light of the findings of theresearch paper presented above.
(b) As regards IP Protection:(i) Ensure an adequate governance process to ensure fairness andtransparency.
(ii) Provide specifications on how block lists or other options will beapplied.
(iii) Need for sufficient notice to be provided to ad techs to implement
alternative solutions with their publishers and test and comment backon proposals.
(iv) Provide more information on how the IP Protection proposals would
affect user experience.

78

(v) Provide more information on monitoring tracking activity; theauthentication of users; the relationship with the CDN; and the
management of a block list.

Other updates covering the reporting period
Update on testing and trialling
123.

Google launched in January 2024 a combined end-to-end experiment utilising
1% of traffic for which Chrome disabled third-party cookies as part of its ModeB testing initiative. Using Mode B traffic will ensure that third-party cookies are
not used in auctions intended for testing the Privacy Sandbox tools. This test
will seek to estimate the potential direction and scale of impacts on Google
and the advertisers and publishers who rely on its advertising services.

124.

Our wider evidence base will also include testing results from third-party
market participants. We have engaged with a wide variety of market
participants who have begun or submitted plans to run tests of the Privacy
Sandbox tools during Q1 and Q2 2024.

125.

As mentioned in our last update report, our assessment will not consider
these testing results in isolation but alongside a wider evidence base. This will
include evidence gathered from across the industry on how the Privacy
Sandbox tools might affect their business operations. We are also asking third
party testers to submit a range of quantitative and qualitative information with
their results and will continue to engage with market participants on their
testing plans.

126.

We encourage market participants to conduct tests in line with our guidance. 99
The testing period will run to the end of Q2 (during which third party testers
can submit results to the CMA).

127.

One point that has been brought to our attention is that not all experimental
traffic which DSPs are receiving from SSPs is labelled. Some DSPs havesubmitted that the share of experimental impressions which are unlabelled
may be different across treatment and control groups. We encourage DSPs toassess whether this issue is affecting their experiments and to consider
potential mitigations available within their experimental designs.

99

See CMA’s Guidance to third parties on testing dated 29 June 2023 and Additional CMA guidance to third
parties on testing dated 26 October 2023.

79

128.

For those ready, results can be submitted to privacysandbox@cma.gov.uk.

Actions and conclusions of the Monitoring Trustee
129.

The Monitoring Trustee has not informed the CMA of any instances of Google
being non-compliant with its obligations under the relevant paragraphs of theCommitments.

130.

Although the Monitoring Trustee’s quarterly report represents a snapshot in
time, Google is subject to continuous monitoring for the duration of theCommitments. Therefore, monitoring activities may be reported on as inprogress or otherwise in the process of discussion, negotiation, investigation,or consideration, with a future road map of monitoring work at any given time.

131.

During the reporting period, the Monitoring Trustee has overseen Google’s
activities relating to paragraphs 25-27, 30-31, and 33 of the Commitments.
These activities are largely a continuation of, and build upon, the work
undertaken in the previous periods, including:(a) Developing a deeper understanding of Google's internal data control
systems in order to robustly test Google’s proposals to address its
commitments on Chrome browsing history, Google Analytics data, and ad
inventory on websites not owned and operated by Google. These
commitments only apply after Chrome ends support for third-party
cookies, but we are working to ensure that these controls are fully
implemented well in advance of third-party cookie deprecation. In thecurrent reporting period, there was a particular technical focus on antiabuse activities, as well as identified paragraph 26 data use instances.
(b) Continuing to review compliance artifacts around internal decision-making
processes (e.g. logs and records) to test whether Google’s internal
processes are being followed in practice.
(c) Reviewing Google’s proposals for new technologies and the risk thatthese could self-preference Google through their design, development or
implementation. This has included scrutinising Google’s Key Design
Decisions to test their compliance with Section H of the Commitments.
Select examples for the reporting period include engagement with Google
regarding developments around Related Website Sets, trusted services
within the PA API and ARA, and Bidding and Auction Services within the
PA API.
(d) Engagement with Google regarding the API user attestation andenrolment process.
80

(e) Working to develop potential approaches and structures to support
ongoing monitoring and compliance following third-party cookie
deprecation.
132.

As explained below, the Monitoring Trustee has been working closely with theTechnical Expert, as well as with the CMA. Submissions (or extracts ofsubmissions) from stakeholders which are relevant to multiple elements of thecompliance regime are frequently shared between the CMA, Monitoring
Trustee, and Technical Expert to ensure that they are fully addressed.

Technical Expert
133.

As mentioned in previous update reports, the Technical Expert aims to
support the Monitoring Trustee by providing the following skills which are vitalfor effective monitoring of the Commitments:(a) Analysing Google’s data access and flows;(b) Analysing technical access controls and security; and(c) Providing general ad tech expertise and advice.

134.

We have also continued our direct dialogue with the Technical Expert.
Discussions have focused primarily on market trends and issues concerning
the design and implementation of Google’s Privacy Sandbox proposals. We
have taken account of views and comments from the Technical Expert in our
ongoing discussions with Google on the design and proposed implementationof the Privacy Sandbox tools and in identifying the remaining potential
concerns described in the section above.

Engagement with market participants
135.

We are continuing to engage with market participants in the wider online
advertising ecosystem to ensure that we become aware of, and understand,concerns about the Privacy Sandbox tools and their impact.

136.

Our own stakeholder engagement is not intended as a substitute for market
participants’ direct interactions with Google, and we would encourage
participants to raise substantive concerns through existing channels including
W3C. Google is required under the Commitments to respond to reasonableviews and suggestions, as summarised in Google’s quarterly report which is
published alongside this document. It is important that Google responds
substantively to feedback, and we will highlight to Google where we do notconsider that it has provided an adequate response and ensure that it does
so.
81

137.

Since the publication of the CMA’s last report, in Q4 2023, our engagement
has had a particular focus on encouraging and guiding industry testing,following the publication in October 2023 of our additional guidance note 100 tomarket participants considering testing.

138.

We asked interested stakeholders their views on the issues set out in the lastquarterly report. In total we heard from 25 stakeholders. Concerns raised
through responses from these stakeholders were largely in areas that wewere already aware of, but there were some new issues identified. Concerns
raised throughout the stakeholder engagement process have been raised with
Google in a confidential manner, and directly informed our role overseeing thedesign and implementation of its proposals.

139.

Details of the concerns raised by market participants related to the specificAPIs have been included in the relevant sections above. Other concerns
raised have included the following:

Use of data
140.

Market participants have suggested that Google should clarify (a) thescope of data that will not be used, and (b) how and where this data is
not going to be used, with respect to each of paragraphs 25, 26 and 27of the Commitments. We are aware that there are questions and concerns
around Google's use of data. We have passed these comments to Google,
and we are considering these as part of our work on first-party data. Google
has said that it agrees that the scope of the data commitments is importantand that it is engaging with the Monitoring Trustee and us with respect to thedata covered by these commitments, and the technical mechanisms to ensure
that, after Chrome ends support for third-party cookies, data will only be usedin line with the requirements of the Commitments.

141.

The Chrome browser has access to many different types of data. Market
participants have suggested that it would be helpful to have more clarity
over:(a) What Google means by ‘browsing history…’ as there is acommitment not to use personal data of this kind for targeting
advertising. Clarifications would include the usage of browsing
history tied to an authenticated Chrome user’s account, the usage of100

See CMA’s Additional CMA guidance to third parties on testing dated 26 October 2023.

82

URL and content data, activity within sites, and any location tied tothat history.
(b) How and where data can move in Google pipelines to understandboth the direct and indirect ways targeted advertising can or cannot
benefit. For example, if Google were to draw inferences from its
Chrome and Account Data for non-advertising purposes, and thatthen fed into targeting or other predictive models for advertising,
this would negate some of the value of the Commitment.
(c) As above, we have raised this with Google. Google has said that it has
set up internal controls to guarantee that browsing history data cannot be
used in contravention of the Commitments, directly and indirectly, for ads
targeting and measurement purposes.
(d) Google as an entity should be prevented from using a broader set ofdata than just browsing history, even if that is broadly defined, fortargeting advertising purposes on their open web integrations. If
Google is able to use account data, search history, YouTube history,
Gmail etc, for targeted advertising across the web and are only
restricted on URL usage from a browser bar, that will not be ameaningful restriction.
(e) Google notes that under paragraph 27 of the Commitments, after Chromeends support for third-party cookie, Google will not be allowed to use its
first-party data to track users to target or measure ads shown on thirdparty websites across the web. However, Google is not prohibited fromusing its first-party data, except personal data from Chrome browsing
history and from Google Analytics that customers have not shared orexported to other services for advertising purposes, for the targeting andmeasurement of ads shown on its O&O properties.
Timing142.

Market participants have raised concerns over the lack of clarity on
timelines for third-party cookie deprecation, and some have suggested
that the Privacy Sandbox will not be in a position to be switched on in
2024. Market participants also raised concerns over the process for how
cookies will be phased out, including that Google does not set out how
third-party cookie deprecation will be scaled from 1% to 100%. They also
note that a faster phaseout could have a greater revenue impact on
smaller ad techs which may struggle to properly train machine learningmodels until third-party cookie deprecation extends beyond 1% and are83more likely to need time to coordinate with others in the industry ascompared to vertically integrated players like Google.
143.

We have shared these concerns with Google. Given the time needed toresolve outstanding issues and take account of testing results, Google has
said that it will not complete third-party cookie deprecation by the end of thisyear. Subject to resolving our remaining competition concerns, Google is now
aiming to proceed with third-party cookie deprecation starting in early 2025.
Under the Commitments, it is for Google to decide when the Standstill Period
is triggered.

Fees
144.

Market participants have made the following comments about potential
fees:

145.

What fees (if any) will Google charge in connection with the Privacy
Sandbox tools, including but not limited to fees associated with: (a) API
access, (b) registration fees, (c) data fees, and/or (d) licensing fees? If
Google does charge fees, what criteria is Google willing to commit to or
at least share publicly with respect to making such determinations?
How much prior advance warning will Google provide to themarketplace regarding any fees?

146.

We agree it is important that Google clarifies whether there will be any
charges in relation to the Privacy Sandbox, and to provide transparency. We
have raised this with Google.

Other
147.

Market participants have suggested that PETs such as Privacy Sandbox
are seeming to go beyond basic legal requirements which set new waysof operating for the industry.

148.

We understand this to mean going beyond basic legal requirements relating todata protection. This is a concern we have heard before. Although Google is acompany that can make its own decisions including how it approaches dataprotection, under the Commitments, Google is required to consider the D&I
Criteria in designing, implementing and evaluating the Privacy Sandbox
proposals. The D&I Criteria include impact on privacy outcomes andcompliance with data protection principles, but it is one of five criteria, andother factors that will need to be considered include impact on competition indigital advertising, and impact on publishers and advertisers.
84

149.

Google has said that while it has sought to ensure that the Privacy Sandbox
APIs enable compliance with applicable legislation and has engaged with the
ICO and us in their development, it does not consider the basic legal
requirements to be a cap on what it can offer to the industry and to users. It isseeking to improve Chrome users’ privacy while providing effective
alternatives to third-party cookies, which in some circumstances includes
improvements to user privacy beyond what may be legally required of Googleor those using the technologies.

150.

Market participants have suggested that companies are concerned overthe lack of viable alternatives to the Privacy Sandbox. As mentioned in
the competition concerns section of the report, we appreciate that Google’s
market position allows it to have a significant impact on the viability ofalternative technologies that may compete with the Privacy Sandbox tools
following the removal of third-party cookies, so we are continuing to engage
with Google on this issue.

151.

Market participants have suggested that a lack of interoperability means
publishers will need to adjust their content to suit the unique frameworkand technical requirements of each platform on which it is distributed.
As noted in this report, Google is required to consider the D&I Criteria indesigning, implementing and evaluating the Privacy Sandbox proposals. D&I
C looks at the impact on publishers and advertisers. We have shared thisconcern with Google.

152.

Market participants have suggested that input received by the CMA and
Google until now has largely come from outcome-based performance
vendors, and so the use case for self-service DSPs is not being
considered. In their view, this means it is degraded at best which could
lead advertisers to move spend to platforms where granular reporting isavailable post third-party cookies, such as Google O&O inventory. We
appreciate the need for a wide range of use cases to be considered andraised this concern with Google. Google has said that there are multiple selfservice DSPs who regularly provide public feedback on the APIs and that
Chrome is actively engaging on typical self-service DSP topics like video andthird-party ad servers.

153.

Market participants have requested that Google retains dynamic linkdecoration following third-party cookie deprecation. This is not in scopeof Google’s Commitments and our assessment, but we have raised thiscomment with Google.

154.

Market participants have suggested that third-party cookie deprecation
on mobile devices should not happen before full interoperability
85between web and app is achieved. We have raised this comment with
Google. In response, Google has agreed that it is desirable to support app
and web interoperability and noted that it has launched cross app and web
attribution measurement and is exploring web-to-app targeting solutions.
155.

However, Google has said that it is not planning to delay third-party cookie
deprecation on mobile web, and it does not have a goal of 100% coverage atthe end of third-party cookie deprecation. Rather, it expects compatibility on
Android for cross app and web measurement to be reasonably high at thirdparty cookie deprecation and to increase over time as users update theirphones.

156.

Market participants have suggested that Google should make its
guidance on experimentation clearer to support stakeholders withtesting. In their view, developer guidelines do not have clear
instructions on how testing would be performed at scale for reliable A/B
testing.

157.

Testing is an important part of the process to inform decisions around thePrivacy Sandbox. We have published guidance for ad techs, publishers, adadvertisers on how they can test the APIs in a way that would contribute to
our assessment of the Privacy Sandbox tools, which we recommend
stakeholders consult in the first instance in case of doubts about testing. 101
We appreciate the work stakeholders are doing to provide test results. We areaware that some stakeholders have had questions about experimentation andwanted more clarity on the guidance. We consider this to be important andhave raised this with Google.

158.

In addition, several stakeholders have alleged specific breaches of
Google’s Commitments:(a) It has been alleged that Google is in breach of the Commitments inparticular section D (Transparency and consultation with third parties) andSection H (Non-discrimination). It has been claimed that Google is selfpreferencing its advertising products and services, and using
competitively sensitive information provided by an ad tech provider or
publisher to Chrome for a purpose other than that for which it wasprovided.

101 See footnote 99.

86

(b) While we do not consider that there has been any ‘breach’ of provisions in
sections D and H of the Commitments, we have raised the substance ofthe concerns with Google under paragraph 17.a.ii. of the Commitments,
where appropriate.
(c) It has been alleged that, in relation to the classification based on hostnames under Topics API, Google impairs its rivals’ ability to monetise
their ad inventory in competition with Google’s O&O ad inventory. It has
been alleged that, if Google’s designs restrict rivals from interoperating
and competing with its ad systems offered to rival media owners tomonetise their ad inventory or common advertiser prospects for such
digital advertising solutions, the combination of this interference with the
impaired effectiveness of Google’s proprietary API ad systems violates
both the spirit and the letter of Google’s commitments, particularly
paragraph 30.
159.

While we do not consider that there has been any ‘breach’ of provisions in theCommitments, including paragraph 30, we have raised the substance of theconcerns with Google under paragraph 17.a.ii. of the Commitments, whereappropriate.

160.

In relation to ARA, it has been alleged that by reducing to 3 bit storage andadding ‘fake data’ of the results rivals’ systems receive, Google’s design only
degrades rivals’ ad solutions but not the optimisation of matching paid content
across its O&O properties’ ad inventory. It has been alleged that this would
shift spend from across the open web towards the largest online publishers—
such as Google’s O&O properties – and that this ‘discriminatory design’ would
seem to violate both the spirit and the letter of Google’s commitments,
particularly paragraph 30.

161.

As regards to the alleged violation of paragraph 30 of the Commitments, it is
not clear to us how such a violation arises where the functionality available toGoogle through the ARA is the same as for third parties.

162.

A further submission put forward information on alleged preferential treatmentof Google [via Chromium], which it has been claimed is in breach of theCommitments.

163.

We have already raised the substance of these concerns with Google underparagraph 17.a.ii. of the Commitments, where appropriate.

87

IAB Tech Lab – Privacy Sandbox Fit Gap Analysis for Digital Advertising164.

The report from IAB Tech Lab’s Privacy Sandbox taskforce provides useful
insights. Google has published its own response to the report. 102

165.

Within the report, IAB Tech Lab raises a number of concerns regarding thedifferent aspects of the Privacy Sandbox. Several stakeholders reiterated
concerns raised by IAB Tech Lab in responses made to our last quarterly
report. There are certain concerns raised, such as around governance, that
we are actively considering and are currently in communication with Google
about.

166.

In Google’s response to the IAB Tech Lab report, it notes that it largely
focused on the technical assessment, and that it plans to engage theecosystem and update its public FAQs in relation to other questions andconcerns raised, such as around fragmented documentation, commercial
requirements, third-party audits, industry accreditation, scalability,transparency and future governance. We consider that clarity over thesequestions is important. We welcome Google’s plan to update its public
information and have followed up with Google to understand its progress on
this.

167.

Google has said that it has provided updates on several of these areas. It hasaddressed:(a) Fragmented documentation by updating the navigation of the developer
pages of the Privacy Sandbox to be use case focused, using similar
categorisations to the IAB Tech Lab in its recent Privacy Sandbox Task
Force report. 103 Google plans to use this use case-based approach to
documentation going forward.
(b) Commercial requirements under the ‘Data Guarantees’ section of theabove Google response to the IAB report, 104 and some Google Ads
products have shared their approaches as set out in the FAQ for Ad
Manager and Privacy Sandbox. 105

102

See Google’s response to the IAB Tech Lab’s report here (accessed on 22 April 2024).
See the developer pages of the Privacy Sandbox here (accessed on 22 April 2024)
104
See the ‘Data Guarantees’ heading in Google’s response to the IAB Tech Lab’s report here (accessed on 22
April 2024).
105
See the FAQ for Ad Manager and Privacy Sandbox here (accessed 22 April 2024).
103

88

(c) Third-party audits under the ‘Algorithm Integrity Guarantee’ section of theabove Google response to the IAB report. 106(d) Regarding accreditation Google would expect those bodies to continue
accrediting products, including their use of technologies, rather than thetechnologies by themselves.
(e) Regarding scalability, Google has said that it continues to be open to datafrom developers that demonstrates issues.
(f) Regarding transparency and governance, Google has said that it
continues developing in the open on GitHub and at forums like W3C while
engaging with the CMA under the Commitments.
Stakeholder engagement
168.

Our focus for stakeholder engagement over the next quarter will be on guiding
ongoing industry testing of the Privacy Sandbox APIs and working with
Google to resolve outstanding concerns.

169.

Given the global nature of Google’s developments, we welcome feedback
from organisations both within and outside the UK.

Engagement with the ICO and international authorities
170.

We have continued to work together closely with the ICO in implementing theCommitments. The ICO’s role has included:(a) Participating in discussions with us and Google on the development of thePrivacy Sandbox tools, analysing data protection impacts with a specificemphasis on user controls and assessing compliance with data protection
legislation;(b) Engaging directly with Google on these issues by holding separate
meetings which we have also attended;(c) Continuing to work with us on plans for the wider assessment of thePrivacy Sandbox tools, including assessing privacy impacts; and106

See the ‘Algorithm Integrity Guarantee’ Google’s response to the IAB Tech Lab’s report here (accessed on 22
April 2024).

89

(d) Engaging with market participants on proposed alternative technologies tothird-party cookies and similar advertising technologies.
171.

We have also continued to engage with our international counterparts anddata protection authorities on the implementation of the Commitments in aneffort to identify any issues of common concern and ensure consistency ofapproach.

Next steps
172.

Over the next three months, we will focus on working with Google to resolve
the concerns we have identified in this report ahead of the Standstill Period.

173.

We are planning to publish our next update report and Google’s progress
report in July 2024.

Contact details
174.

We would welcome views from interested parties on this report, as well as on
any other relevant publications (e.g. Google’s own quarterly report). The
relevant contact details are:
CMA: privacysandbox@cma.gov.uk; adam.gayton@cma.gov.uk;
angela.nissyrios@cma.gov.uk; and chris.jenkins@cma.gov.uk.
Monitoring Trustee (including communications for the Technical Expert):
trustee.services@ing.com; matthew.hancox@ing.com; anddavid.verroken@ing.com.
Google: Feedback - Chrome Developers.

90Annex 1 – current proposals in the Privacy Sandbox
1.

At the time of publication, the list of proposals in the Privacy Sandbox include
the following arranged by use case:

Use Case: Showing relevant content and ads
2.

Currently, third-party cookies and other forms of cross-site tracking allow forinterest-based user profiles to be established and users to be targeted withads corresponding to their profile (interest-based targeting). Cross-site
tracking is also used to allow advertisers to retarget customers that havepreviously visited their website, for remarketing purposes.

3.

Google has developed two proposals to enable ads targeting and retargeting
respectively without third-party cross-site tracking.
(a) Topics(b) Protected Audience

Use Case: Measuring digital ads
4.

Cross-site tracking may also be used to determine whether and how manyads have been served successfully to users (measurement), to help assess
ad effectiveness by determining whether views and clicks on ads led toconversions (attribution), and to limit how often a specific user is shown an ad(frequency capping). It also supports the reporting of the outcomes of ad
auctions to advertisers and publishers to facilitate payment and show
performance of contracts.

5.

Google has developed the following measurement and reporting tool that
does not rely on third-party cookies:(a) Attribution Reporting

Use Case: Strengthen cross-site privacy boundaries
6.

Google has developed a proposal for companies to declare relationships
among sites, so that browsers allow limited third-party cookies access for
specific non-ads purposes such as facilitating a user-journey across several
sites:(a) Related Website Sets

91

7.

Another tool allows users to log into particular sites without sharing theirpersonal information with those sites:(a) Federated Credential Management

8.

A range of other boundary APIs have been developed:(a) Related Website Sets(b) Shared Storage(c) CHIPS(d) Fenced Frames

Use Case: Fighting spam and fraud on the web
9.

Tracking a user’s browsing activity across the web is a way to establish
whether that user can be trusted or should be considered as conducting
fraudulent or spam activities.

10.

Google has developed a new API to enable trust in a user’s authenticity to beconveyed from one context to another, to help sites combat spam and fraud,
without passive tracking:(a) Private State Tokens

Use Case: Limiting covert tracking
11.

Other forms of web functionality, while not dependent on cross-site tracking,currently require the provision of information that is sometimes used tofacilitate cross-site tracking. An example is the information provided throughthe User-Agent String which provides information about the user’s browser
and device to the website that the user is visiting, and which is useful for
optimising the user’s viewing experience. A further example is the IP address,
which is useful for detecting fraud and the geographical tailoring of content.
Google has developed a range of proposals aimed at limiting covert tracking
without breaking currently supported use cases:(a) Bounce Tracking Mitigations(b) User Agent Reduction (including User-Agent Client Hints)(c) Storage Partitioning92

(d) Network State Partitioning(e) IP Protection (previously Gnatcatcher)93

Annex 2 – context and framework of our assessment
12.

We have summarised below the framework for our assessment as set out in
Google’s Commitments.

The Commitments framework
13.

The Purpose of the Commitments is to address the competition concerns we
identified during our Competition Act 1998 (CA98) investigation, namely that,without sufficient regulatory scrutiny and oversight, the Privacy Sandbox
proposals could: 107(a) distort competition in the market for the supply of ad inventory and in themarket for the supply of ad tech services, by restricting the functionality
associated with user tracking for third parties while retaining thisfunctionality for Google;(b) distort competition by the self-preferencing of Google’s own advertisingproducts and services and O&O ad inventory; and(c) allow Google to deny Chrome web users substantial choice in terms ofwhether and how their Personal Data is used for the purpose of targetingor measurement and delivering advertising to them.

14.

The Commitments state that Google will design, implement and evaluate thePrivacy Sandbox proposals by taking into account the following factors (theD&I Criteria), which will inform the answer to the question of whether or not
the Purpose of the Commitments, as defined above, has been achieved. The
D&I Criteria are: 108(a) impact on privacy outcomes and compliance with data protection
principles as set out in the Applicable Data Protection Legislation (D&I A– Privacy outcomes);(b) impact on competition in digital advertising and in particular the risk of
distortion to competition between Google and other market participants(D&I B – Digital advertising);

107
108

See paragraph 7 of the Commitments.
See paragraph 8 of the Commitments.

94

(c) impact on publishers (including in particular the ability of publishers togenerate revenue from advertising inventory) and advertisers (including inparticular the ability of advertisers to obtain cost-effective advertising)(D&I C – Impact on publishers and advertisers);(d) impact on user experience, including the relevance of advertising,transparency over how Personal Data is used for advertising purposes,
and user control (D&I D – User experience); and(e) technical feasibility, complexity and cost involved in Google designing,developing and implementing the Privacy Sandbox (D&I E – Technicalfeasibility for Google).
15.

Under the Commitments, Google will work with us without delay to seek toresolve concerns raised and address comments we made with a view toachieving the Purpose of the Commitments. 109 Google will inform us of how it
has responded to those comments. In practice, this means that Google willtake action or provide the CMA with assurances on the actions it will take (orrefrain from) to resolve any remaining concerns.

16.

In the event that we cannot reach mutual agreement or resolve concerns
within 20 working days of written notice by the CMA (unless extended bymutual consent), we may take action, including by reopening the CA98
case. 110 We have not served any such notice to date.

17.

The Commitments also require that Google will not implement the removal of
third-party cookies before the expiry of a Standstill Period of no less than 60days after Google notifies the CMA of its intention to implement such
removal. 111 Google may increase the length of such a Standstill Period at any
time between giving such notice and the period’s expiry. At the CMA’s
request, Google will increase the length of this Standstill Period by a further
60 days to a total of 120 days.

18.

During the Standstill Period, we may notify Google that competition law
concerns remain such that the Purpose of the Commitments will not be
achieved. 112 Google will work with us without delay to seek to resolve
concerns raised and address comments made by the CMA with a view toachieving the Purpose of the Commitments. Google will inform us of how it

109

See paragraph 17.a.ii of the Commitments.
Pursuant and subject to the provisions of section 31B(4) CA98. See paragraph 17.a.iii of the Commitments.
111
See paragraph 19 of the Commitments.
112
See paragraph 21 of the Commitments.
110

95

has responded to those comments. In practice, this means that Google willtake action or provide the CMA with assurances on the actions it will take (orrefrain from) to resolve any remaining concerns.
19.

As part of the Commitments to the CMA, we will monitor Google’s compliancewith those assurances following deprecation of third-party cookies.

20.

If Google fails to comply with the Commitments, including any of theassurances provided to us, the CMA may continue its investigation under
section 31B(4)(b) CA98 or apply to the court for an order under section 31E
CA98. In the event of a material change of circumstances, the CMA also may
continue its investigation under section 31B(4)(a) CA98. Where the CMA
continues an investigation under section 31B(4) CA98, the CMA’s powers to
impose interim measures and/or to make an infringement decision become
available to the CMA again.

21.

Accordingly, if Google fails to respond to our concerns or does not provide therequired assurances, we could oppose the removal of third-party cookies – inwhich case we would expect to continue (reopen) the CA98 investigation if
Google stated that it would push ahead with third-party cookie deprecation.

Proposed approach during the Standstill Period
22.

Once Google triggers the Standstill Period, we expect to assess the evidence
from the testing and trialling results, along with our own analysis of thepotential impact of the Privacy Sandbox changes, informed by stakeholder
responses.

23.

In making this assessment, we recognise that the Privacy Sandbox
represents a significant change for the entire ad tech ecosystem, and that theecosystem will experience significant impacts – for example, impacts onrevenue, on the cost of advertising, or on business practices due to changes
in measurement and reporting. We expect the Chrome-facilitated testing
period (which will run from Q1 to Q2 2024) to provide data on the direction(i.e. positive or negative) and potentially the scale of impacts on publishers
and advertisers in particular.

24.

We will consider any impacts (e.g. revenue loss) in the overall context of thePrivacy Sandbox changes, including the potential to deliver benefits to
consumers. The Commitments do not require that there be no loss of revenue
to publishers and advertisers from the deprecation of third-party cookies andtheir replacement with the Privacy Sandbox tools. However, the Commitments
require that Privacy Sandbox is implemented in a way which does not infringe
competition law and minimises the impact on revenue to the extent possible,
96while also considering privacy impacts and the legitimate aim of compliancewith data protection principles as set out in the Applicable Data Protection
Legislation through reducing cross-site tracking.
25.

The scale and direction of impacts on the ecosystem could change over time,
as ad techs optimise their systems, retrain machine learning models using
signals from Privacy Sandbox APIs and new Privacy Sandbox functionality
becomes available. Our stakeholder engagement on specific challenges, likelatency concerns around Protected Audience auctions on-device, suggeststhat some stakeholders are optimistic that they can iteratively improve overtime. Our assessment will consider the scale and direction of impacts
alongside any evidence on potential improvements (or degradations) thatmight occur.

26.

Similarly, some existing ad tech business models will be disrupted where they
currently rely on cross-site tracking technologies, including third-party cookies.
The purpose of the Commitments is not to support specific business models.
In assessing the Privacy Sandbox changes our focus will be on the likely
impacts for competition and consumers overall.

Engagement with the ICO
27.

To support and inform the CMA’s assessment, the ICO has focused on D&I A– Privacy outcomes and, where relevant, D&I D – User experience. These
criteria, together with the ICO’s direct scrutiny of Google’s compliance withdata protection principles as set out in the Applicable Data Protection
Legislation, provide the mechanism by which the ICO is examining the APIs,
supporting our analysis to determine whether the Privacy Sandbox delivers
positive privacy outcomes and choice for individuals.

28.

In our Commitments Decision, we cited the ICO’s Opinion on data protection
and privacy expectations for online advertising proposals dated 25 November
2021 113 as a resource that provides additional regulatory clarity on the dataprotection expectations that online advertising proposals should meet.
Accordingly, when assessing D&I A – Privacy outcomes and D&I D – User
experience, the ICO has drawn upon its 2021 Opinion, particularly section 5
which sets out the Commissioner’s expectations. These principles andrecommendations for ad tech market participants developing new solutions
provide a framework to ensure that the interests, rights and freedoms of113

See the 2021 Opinion.

97

individuals are respected. 114 This framework is rooted in the Applicable Data
Protection Legislation. 115 These principles and recommendations remain
applicable and in the context of the Commitments the ICO has used them toconsider Google’s Privacy Sandbox proposals.
29.

As well as considering future developments, the ICO’s 2021 Opinion also built
on the ICO’s update report into ad tech and real time bidding dated 20 June2019 (together, the 2019 and 2021 Publications). 116 Both in its 2019 and2021 Publications, the ICO sets out expectations that the ad tech industry
addresses a range of issues. 117 As stated at the time, these data protection
issues relate to several types of harm that organisation needed to consider aspart of a risk-based approach to data protection. The ICO’s expectations havenot changed: where new online advertising products are proposed, they must
address the issues it identified in the 2019 and 2021 Publications and mitigate
any new or different risks and harms they involve in order to comply with dataprotection principles and the UK data protection law. In summary, when
considering the Privacy Sandbox against D&I A and D, its previous work andidentified systemic issues have been front of mind for the ICO.

30.

Coming to a position on how effectively Google has taken into account D&I A– Privacy outcomes requires the ICO to sets out a view on the impact of thePrivacy Sandbox on privacy outcomes.

31.

The ICO’s position on possible privacy benefits is, again, informed by its
assessment of the compliance with Applicable Data Protection Legislation
using the approach set out in its 2019 and 2021 Publications. The ICO’s 2021
Opinion, in particular, sets out the requirements for the industry to address arange of data protection concerns that it continues to observe after identifying
them in the ICO’s 2019 Report. 118 As stated at the time, the ICO sets out
expectations that ‘new proposals for enabling online advertising must address
the issues and harms highlighted [in the 2019 Report]’. 119 The ICO’s
evaluation of the Privacy Sandbox tools, and their possible benefits, is based

114

See paragraphs 43-46 of the 2021 Opinion.
See page 2 of the Commitments. ‘Applicable Data Protection Legislation’ is defined to mean all applicabledata protection and privacy legislation in force in the UK, including the Data Protection Act 2018, the UK General
Data Protection Regulation (GDPR) (and regulations made thereunder) and the Privacy and Electronic
Communications (EC Directive) Regulations 2003 (PECR).
116
See the 2019 Report.
117
See paragraphs 16-17 of the 2021 Opinion.
118
See page 16 of the 2021 Opinion.
119
See page 19 of the 2021 Opinion.
115

98

on the risk and likelihood of these previously identified concerns being
replicated in a post-Sandbox ecosystem.
32.

As set out in the ICO’s 2021 Opinion, the ICO has noted that both PECR anddata protection law are technology neutral. 120 It continues to be the ICO’sview that concerns highlighted in its 2021 Opinion were predominantly the
result of industry practices and not the underlying technologies. 121
Accordingly, where the ICO has identified a possible concern, its current viewis also informed by the risk and likelihood of misuse by third parties using thePrivacy Sandbox tools based on information available and its historicobservations about potential data protection law non-compliance issues in thead tech ecosystem.

33.

Under the Applicable Data Protection Legislation, the principle ofaccountability ensures that those responsible for the processing of personal
data are able to demonstrate how they are complying with their obligations.
Taking a data protection by design approach to governance andaccountability at the outset will assist Google and the parties using thePrivacy Sandbox APIs to comply with their data protection obligations moreeasily and to demonstrate this to data subjects and regulators.

120

See page 20 of the 2021 Opinion.
While maintaining its position regarding technology neutrality, it is also the ICO’s view that the characteristics
of a technology can contribute towards the ease by which websites and third parties are able to comply with dataprotection legislation.
121

99