Chrome’s third-party cookie phaseout, the 1% rollout and an update on proposed solutions

Posted by Jonas Jaanimagi On January 17, 2024 ad tech matters, android, chrome, google, Privacy, privacy sandbox, third party cookies

Note – on Feb 7th 2024 IAB Tech Lab’s Privacy Sandbox Task Force published draft commentary and analysis on the challenges associated with the industry’s adoption of Google’s Privacy Sandbox proposals. This analysis includes 45 specific use-cases, grouped into five programmatic advertising ‘pillars’, with both a technical assessment and potential business impact analysis for each use case.To access a summary of this analysis please click here

Note – on April 24th 2024 Google announced a delay to Chrome users having third-party cookies disabled, pushing it back into 2025 (as per the updated timeline below). To view this announcement with links to future updates from both Google and the CMA simply click here

image source:

Regardless of Chrome’s timelines, our overall advice remains the same – the changes are coming and we are keen for everyone across the eco-system to understand the proposed changes, prepare for those changes and start testing as soon as possible. This advice is not just for Chrome – but across the full range of different browsers for web, and operating systems for in-app environments.

In the past months, we have been covering a number of critical topics in relation to mitigating signal loss and consumer privacy reforms. We’ve covered topics such as the responsible management of consent & privacy signals (click here) as well as reviewing IAB Tech Lab’s recently released draft proposals for auditing the adherence to these signals through the supply chain (click here).

With regards to signal loss we’ve regularly reviewed (with support of our various councils) the portfolio of options available to industry as third-party cookies continue to deprecate as an identifier for advertising across many of the devices and environments through which consumers access the internet. From ID solutions guidance, to contextual targeting guidance and IAB Tech Lab’s Seller-Defined Audiences guidance.

As a critical element of this guidance we have also regularly provided updates on the timings (click here), plans and implications of future third-party cookie deprecation within Google’s Chrome browser – as it remains the most widely used browser in Australia.

image source:

In this article we want to provide an update in four key areas, with the intention of helping to support industry to understand these proposed changes, prepare for those changes (both for in-house teams and for those working closely with any vendor partners) and if appropriate – start testing as soon as possible.

Sellers need to initially focus on their own domain(s) and how to ensure buyers can meaningfully access audiences – whilst buyers need to be able to test for how to most effectively target, optimise and measure without third-party cookies. As mentioned previously, these efforts may be run in-house, through vendor partners or else a combination of both.

1. Chrome’s 1% global rollout – Chrome’s Tracking Protection feature, which limits cross-site tracking by restricting website access to third-party cookies, has now been rolled out to 1% of users globally since Jan 4th 2024. We’ll review the rollout and provide some guidance and background on the current proposed timings.

2. An update on the Privacy Sandbox APIs – there is an extensive list of APIs that are in various stages of readiness for both web-based and in-app environments. These keep evolving (often including name changes) so we’re keen to provide an update on the key proposals, their status and share some useful links.

3. Chrome Third-Party Cookie Deprecation Trials – guidance and recommendations with regards to preparing for, auditing cookies and ultimately testing for cookie deprecation and the Privacy Sandbox APIs in Chrome.

4. Other major browsers and operating systems – we will also share some info and updates on the other large measurement APIs being developed by the likes of Apple (in both iOS & Safari), Mozilla Firefox, Microsoft Edge and the Meta owned apps (i.e. Facebook & Instagram).

This includes info and a link to the recently revealed Apple AdAttributionKit – which has been designed to present, process, and register postbacks for in-app ads in the App Store and also alternative app marketplaces (from iOS 17.4 onwards).

1. Chrome’s 1% Rollout

For some time now Google have clearly been communicating that 2024 would be the year that we would globally see increased numbers of Chrome users having their third-party cookies disabled, with ongoing testing periods continuing through to the end of 2024. Thereafter a consultation period with the UK’s CMA (Competition and Markets Authority) will follow and subject to the outcome of any review of related competition concerns – the plan was to to start disabling third-party cookies for all Chrome users worldwide by the end of 2024. This has now changed (see note above).

Note that this agreed timeline does not currently include any of the Android in-app only proposals and is subject to change (the below is correct as of January 2024). Due to the announced amendments to this timeline we will publish a follow-up in late April 2024.

image source:

It is often forgotten that currently the timings for all the privacy proposals for Chrome are subject to discussions between the CMA and Google, based upon the legally binding ‘Commitments‘ made by Google in February 2022. It’s well worth keeping an eye on the quarterly updates (Q3 2023 is here and Q4 2023 is here) from the CMA on the privacy proposals to keep across the timings – as well as obviously the publicised timelines on the website.

As for the 1% rollout, this has now been live since Jan 4th this year, is totally random in terms of consumers included and is estimated to be impacting some 30m users globally that are using the latest stable version of the Chrome browser (currently version 120).

Affected users are notified upon opening Chrome on a desktop or on an Android device (as per the below). Should they want to re-enable third-party cookies, then this can be done by clicking on the eye icon and selecting that option.

image source:

Some informal feedback is coming through from the early results of testing and the only meaningful data is that the impact is measurable, but seemingly less than was initially seen following the rollout of Apple’s AppTrackingTransparency (ATT) framework in iOS almost three years ago.

We will share results and any useful pan-industry feedback as soon as we can.

2. An Update on the Privacy Sandbox APIs

A number of key proposals are now in-play having been shipped (complete with updated online demos) and some are still in development.

The key APIs and features to be aware of are listed below:

Topics API – enables interest-based advertising and content personalisation. This API is now in general availability and for an explainer click here, and for a demo and walk-through simply click here

Protected Audience API (formerly known as FLEDGE) – enables remarketing and custom audiences. This API is now in general availability and for an explainer click here, and for a demo simply click here

image source:

Attribution Reporting API – enables measurement of ad impressions and conversions. This API is now in general availability and for an explainer click here, and for a deeper dive and use cases click here

Private State Tokens API – as known as ‘Trust Tokens’ these enable anti-fraud and anti-spam capabilities by exchanging limited, non-identifying information across sites so as to verify a user’s authenticity without passive tracking. This API is now in general availability and for an explainer and some use cases click here

Shared Storage API – enables unlimited, cross-site storage write access across different sites even if they belong to different domain without having direct access or being able to read any values. Shared Storage uses a concept called ‘gates’ to conduct various privacy preserving operations (as per image below). This API is now in general availability and for an explainer click here, and for a demo simply click here

image source:

Private Aggregation API – generates aggregate data reports using data from Protected Audience and cross-site data from Shared Storage. This API is now in general availability and for an explainer click here

Fenced Frames – acting as a more secure version of the classic iframe these allow developers to securely embed content onto a page without sharing any cross-site data. Fenced Frames provide strict separation between the embedded content and the embedding page which ensures no cross-site data sharing, protecting user information and preventing tracking practices. This proposal is now in general availability and for an overview click here

Related Website Sets – previously called ‘First-Party Sets’, this feature allows developers to declare relationships among sites (up to five, plus one primary domain), so that browsers allow limited third-party cookie access for specific purposes. Not an ads solution but critical for publishers to be aware of. For an overview simply click here

Federated Credential Management (FedCM) – enables federated identity services allowing users to sign in to sites and services without directly sharing user credentials with the website(s) or identity provider, by using the browser as a secure intermediary. This is still in development… but for an explainer click here

Cookies Having Independent Partitioned State (CHIPS) – also known as ‘partitioned cookies’ this will allow developers to opt a cookie into partitioned storage, with a separate cookie jar per top-level site. Each partition is associated with a specific top-level domain and when a third-party service sets a CHIPS cookie on a website, it’s only stored within the website’s partition. This means the cookie can’t be accessed by other websites, even if they use the same third-party service. This is still in development… but for an explainer click here

3. Key Recommendations & Considerations

We will start with providing some guidance, links and recommendations for testing the Google Privacy Sandbox APIs and features that are generally available. Thereafter we’ll also share some information and updates on other proposed approaches that are also enabled on-device or in-browser, which is one of the portfolio of recommended privacy-preserving approaches.

image source:

For previous guidance on the other post third-party cookie deprecation options, please follow the links below:

Chrome third-party cookie deprecation trial

The starting point for preparing to test for the changes to come is fairly straightforward, but once the technical work is required we recommend you dedicating genuinely competent people to engage with the more technical aspects through the auditing and testing processes.

Also, remember that any publishers that use third parties that rely on cookies do not necessarily need to sign up for the deprecation trial. Instead they should audit the third-party cookies used on their site(s) and contact the third-party vendors they work with to ensure that they are prepared for the changes to come.

Chrome recommends three phases:

image source:

Prior to entering the testing phase it’s advisable to run a Cookie Audit process to identify, review and understand both the first and third-party cookies. Chrome do provide some guidance on this (click here) using the built-in DevTools resource to run this manually, but there are automated solutions also avilable if you do your research. Any cookies marked for third-party usage can be identified by their ‘SameSite=None‘ value. A third-party-cookie demo tool (as per image below) is also available if you click here

image source:

It’s also worth looking at the recently released Privacy Sandbox Analysis Tool (PSAT) which can be added as a Chrome Extension (click here) and looks very useful. PSAT can help developers to better understand the usage of third-party cookies during any browsing sessions. To achieve this, PSAT seamlessly leverages the Chrome DevTools Protocol (CDP) to debug and collect information about sites being loaded during a browsing session.

image source:

Having run a cookie audit, the initial steps for registration and setup for testing are listed below. These are provided simple to get you going, along with some handy links at the end.

Step1 – register

Registration for the Chrome deprecation origin trials began in early December 2023 and the trial itself will run from January 2024 through to late December 2024. Developers are expected to make necessary changes and plans by the trial end date.

Origin trials like this are generally open to everyone, although there are some ‘Participation Criteria’ to be aware of. Chrome has opted to work with to implement Disconnect’s tracker protection lists to identify scripts and domains labelled as advertising. is fairly widely used by popular browsers for similar purposes on the web – and Chrome will apply the following process for registration requests:

  • If the third-party origin matches a known advertising domain, including if the origin matches an entry on the Disconnect advertising list, then the registration request will be rejected. In general, entries on the list will match all subdomains below the specified origin. Some entries, however, include a path element. These more specific entries will match the given origin, but not subdomains.
  • Steps to reproduce a broken user-facing experience must be provided. In particular, this should be an experience for the user operating the device where the cookie is stored, and not a user performing later analysis of data. If Chrome cannot validate a broken user experience then the registration request will be rejected.

If there are no issues with the above, then one can register. Click here to register for the Third Party Cookie Deprecation trial.

– set flags for testing

Flags are experimental features you can enable to potentially enhance the privacy, security, usability, speed, or overall performance of the Chrome browser. Intended for developers and advanced users, flags point to features that Google is testing to see how they behave before deciding whether or not to officially add them to the browser. The flags for Chrome’s Third Party Cookie Deprecation trial are below:

chrome://flags#third-party-cookie-deprecation-trial -> enabled
chrome://flags/#tracking-protection-3pcd -> enabled
chrome://flags/#tpcd-metadata-grants -> disabled

– add the trial token

There are three options here. Provide the token in an HTTP header, provide the token in a meta tag or else inject the token using JavaScript. The JavaScript options is shown below:

image source:

Step4 – validate your token

Only one valid token is needed to activate the deprecation trial. If you have registered for both first-party and third-party matching, it is not an issue if you provide both tokens within the page. The deprecation trial only enables third-party cookies for the origin registered for the trial.

These are simply the initial steps to get you going and ready for testing and we strongly recommend that our members fully engage in the process of reviewing all the initial design proposals, participate in any available testing processes (whether directly or via key tech partners) and then share feedback. To share feedback on these deprecation trials simply click here

Other Handy Links:

Chrome-facilitated testing modes – this guidance provides an overview of the testing modes Chrome plans to provide and how to access experiment group labels. To review this click here

Privacy Sandbox Demos – the IAB Tech Lab setup a ‘Privacy Sandbox Task Force’, dedicated to conducting a rigorous technical and operational analysis of the forthcoming Privacy Sandbox modifications and their implications for digital advertising use cases. Index Exchange have also very recently donated an advanced Privacy Sandbox Demo tool to the Privacy Sandbox Taskforce and we will be sharing insights from these tests as they emerge. However, they will all be made available on dedicated Privacy Sandbox Demo site. Simply click here to access these demos.

CMA guidance to third parties on testing – the CMA have proposed two experimental designs that market participants can use to test the effectiveness of the Privacy Sandbox, and how they align with Google’s planned launch of two testing modes in Chrome. To review this simply click here

Criteo’s Privacy Sandbox Testing – an example of a vendor that has actively been testing Privacy Sandbox for some time now. They are open about the statistical framework applied and the modelling choices made – and also share some hypotheses related to the competitive market and the behavior of business KPIs. Criteo apply the framework using Criteo’s own data to estimate what they and other DSPs might see. To read this article simply click here

Summary of useful links (see below) from Google to support testing:

4. Other major browsers and operating systems

Whilst Chrome (and Android) are important due to their prevalence with consumers, it’s also critical for industry to keep across what is happening with all of the most popular devices, browsers, applications and operating systems in terms of potential signal loss and mitigating for the related impacts.

Apple – The default cookie policy on Apple’s iOS, macOS, iPadOS, tvOS, and watchOS is to disallow a third-party to set new cookies unless it already has cookies. This means that to be able to use cookies at all as third-party, the domain first has to become first-party and set its initial cookie(s) there.

In Safari browsers Intelligent Tracking Prevention (ITP) by default blocks all third-party cookies. There are no exceptions to this blocking. Third-party cookie access can only be granted through the Storage Access API and the temporary compatibility fix for popups.

For in-app environments running Apple’s iOS and we’ve seen the repercussions of Apple’s App Tracking Transparency feature (ATT) since April 2021 continue to limit measurement effectiveness within the iOS mobile advertising ecosystem as users opt-out of being tracked across apps and websites for advertising purposes. We have covered the implications of these changes in the past (click here).

The SKAdNetwork (often shortened to SKAN) stands for StoreKit Ad Network and is Apple’s privacy-focused framework for measuring the effectiveness of mobile ad campaigns on iOS devices. Now on version 4, the API involves three participants:

  • Ad networks that sign ads and receive install-validation postbacks after ads result in conversions.
  • Source apps that display ads from the ad networks, or websites that display the ads in Safari.
  • Advertised apps that update conversion values as people engage with the app.

It’s worth reviewing the capabilities of each version as it’s released and the current hope is that v5 will include measurement and attribution for retargeting as standard.

image source:

It’s also worth noting that IAB Tech Lab has a tool for managing and maintaining SKAdNetwork ID list. Advertisers, DSPs, and networks can register their SKAdNetwork IDs and IAB Tech Lab will publish a list of all registered IDs that can be downloaded by app developers and publishers. To access this simply click here

In terms of actual measurement and attribution Apple uses the Private Click Measurement (PCM) tool. PCM is a privacy-preserving framework for attribution and ad measurement on web browsers. It uses encrypted, ephemeral data to track click-through rates and conversions without compromising user privacy. To learn more about PCM click here

There is also a proposal from Apple for a tool called Private Ad Measurement (PAM) which is in development to allow marketers  to measure, in a private manner, the effectiveness of advertisements delivered across the open internet. You can access the dedicated GitHub for this proposal here

In early February 2024, Apple have revealed a new measurement framework called AdAttributionKit – to support advertising attribution for alternative app marketplaces from iOS 17.4 onwards.

AdAttributionKit and SKAdNetwork are both frameworks that enable ad attribution and user engagement measurement for conversions. AdAttributionKit works with both the App Store and alternative app marketplaces, while SKAdNetwork works specifically only with the App Store. To learn more about AdAttributionKit click here

Meta – have been working on a number of internal and collaborative projects in this space. For example, the Private Lift Measurement tool was released in 2021 and allows marketers to measure the incremental number of conversions, and how much those conversions are worth, without actually sharing consumer-level data between two parties. Meta have also been openly developing privacy-enhancing technologies  (PETS) for ads based upon Secure Multi-Party Computation (MPC), On-Device Learning and Differential Privacy. For more info on these efforts simply click here

As a collaborative project, Meta have also been working together with Mozilla on a proposal called Interoperable Private Attribution (IPA) which is a proposal for a new web platform API for advertising attribution. You can access the dedicated GitHub for this proposal here

Additionally, if you are marketing heavily on Instagram and/or Facebook it may also be worth reviewing the latest changes to Meta’s detailed targeting options based upon privacy and sensitivity guidelines. In mid-January 2024 Meta will be removing or consolidating some of the more detailed targeting options that relate to topics that people may perceive as sensitive. To review these changes simply click here

Microsoft Edge – as the Edge browser also leverages the same underlying codebase (Chromium) as Chrome it’s likely that if the proposals for Privacy Sandbox are widely adopted by industry in the longer term that Microsoft may also recommend some of these approaches.

Note – in March 2024 Microsoft released their Ad Selection API proposal for Edge with some links to guidance for testing (as per the image below). To review this update simply click here

image source:

Prior to this, back in 2021 – Microsoft released a proposal called PARAKEET (Private and Anonymised Requests for Ads that Keep Efficacy and Enhance Transparency) as a differential privacy proposal. This uses a proxy server that stands between the user and the ad company. Users would have a unique ID known only to the proxy server. When a web page requests an ad, the request is routed via the trusted proxy server. A small amount of statistical noise is then added to each result so as to mask the user’s actual private data (as per the below). To review the proposal on GitHub simply click here

Mozilla Firefox – Firefox first enabled cookie blocking in 2015 within Firefox’s ‘Private Browsing’ mode called Tracking Protection. Since 2018 Firefox aggressively blocked third-party cookies in all browsing modes via Enhanced Tracking Protection (ETP), which automatically protects users’ privacy as they use the application. Essentially this was done by blocking trackers based upon maintained inclusion and exclusion lists. To review the details around ETP simply click here

Since 2022 Firefox has been running an updated privacy feature called Total Cookie Protection as standard, which restricts the functionality for all third-party cookies – not just for those on any defined lists.

Total Cookie Protection works by creating a separate ‘cookie jar’ for each website a user visits. Rather than allowing trackers to link up user behaviour on various sites, they just get to see specific behaviours on individual sites. Any time a website, or third-party content embedded in a website, deposits a cookie in the Firefox browser, that cookie is confined to the cookie jar assigned to only that website. No other websites can reach into the cookie jars that don’t belong to them to find out what the other websites’ cookies know about those users.

image source:

To read more about Total Cookie Protection simply click here

If you have any feedback on this article or wish to provide further supportive guidance which we can share with industry, please do get in touch with us by email


Jonas Jaanimagi