Privacy Sandbox: The Sandcastle the Tide Took Back

It is Saturday morning, 18 October 2025, and you are in the kitchen in your dressing-gown, reading the news with the first tea of the day. Somewhere in California, on Friday afternoon, a vice president of Google published a blog post of about 460 words. Somewhere in your company's project tracker, there is an epic called "Privacy Sandbox readiness". It was created in March 2022. It has 41 subtasks, two of which are marked done. It has outlived three project managers, one office move and a fiddle-leaf fig that nobody was assigned to water.

You read the post twice. Topics: retired. Protected Audience: retired. Attribution Reporting: retired. Related Website Sets, the thing your developer spent a sprint on so that your .com.au and .co.nz sites could share a login cookie: retired. IP Protection, which Google said in April it planned to launch in Incognito by the end of September: retired.

By the second cup, you have opened a spreadsheet. It has a column called "What we built for the cookieless future" and a column called "What we do now". Only the first column has anything in it. You look at the vendor invoice for "Topics-enriched audience segments" and try to decide whether you have paid for a product or a small piece of history.

Stop there. Close the spreadsheet for a minute. Almost nothing you run today broke on Friday, and a lot of what you worried about for six years has just been taken off the list. Third-party cookies are still on in Chrome, and Google says they are staying. The retirement is a clean-up of tools that most of the web never used. It is also a very useful moment to find out which of your tools did use them, and what you do instead.

Google was unusually direct about the reason. The APIs are going, in the words of Anthony Chavez, the Privacy Sandbox vice president, "after evaluating ecosystem feedback about their expected value and in light of their low levels of adoption". That is a polite way of saying that the industry was invited to build on the sand for six years, and most of it stayed on the car park. It matters here because Chrome is 55% of all Australian browsing and 72% worldwide as of September 2025.¹ What Chrome does to ad measurement is what the web does to ad measurement.

So here is the plan. First, the thing the Sandbox was built to replace, which you already know from every music festival you have been to. Then six years of "next year", told quickly, including the part where I told you about it in 2021. Then we go into the butler's pantry, to see how the three big APIs actually worked, because that is the only way to tell whether your stack used them. Then why the tide came in, what did not change about consent, and a (made-up) analytics lead who checks her stack in a week.

Let's get into it.

Part 1: The Stamp on Your Hand

Start with something you have done without a name for it. You go to a festival with several stages, each run by a different promoter. At the first gate, a person with an ink pad stamps a small green badger on the back of your hand. Now every gate you walk through, a staff member glances at your hand, sees the badger, and writes down "badger was here, 2:14 pm, Main Stage". None of the stages talk to each other. They do not need to. The stamp does the talking, and the person who owns the ink pad collects the notes.

That stamp is a third-party cookie. A cookie is a small piece of text that a website asks your browser to keep and send back later. When the website you are visiting sets it, it is a first-party cookie, and it is how the site remembers your cart or your login. When a different domain sets it (an ad server, loaded inside the page as a script, an image or an iframe), it is a third-party cookie. The ad server sets one identifier on news.example, and your browser sends the same identifier back when the same ad server loads on shop.example, recipes.example and the weather site you check every morning. Hand, stamp, notebook.²

At the machine level, it looks like this. Your browser requests a script from ads.example while you are on news.example. The response comes back with a header like Set-Cookie: id=7f3a9; SameSite=None; Secure. SameSite=None means "send this cookie in cross-site requests too". The next time any page anywhere loads something from ads.example, your browser attaches id=7f3a9 to the request. The ad server now has a row in a table: 7f3a9 read about interest rates, looked at hiking boots, and checked the Hobart forecast twice. It did not need to ask anybody.

Safari stopped honouring that stamp. By March 2020, WebKit's John Wilander wrote that "cookies for cross-site resources are now blocked by default across the board", which made Safari "the first mainstream browser to fully block third-party cookies by default". Safari had been tightening its cookie rules since 2017, and I covered what that did to marketing measurement in my post on Intelligent Tracking Prevention. Chrome did not follow, and the reason it gave is where the Sandbox begins.

Google's argument, from the first day, was that blocking the stamp without a replacement would make things worse. If the festival bans ink pads, the promoters do not give up. They start writing down your height, your shirt colour and the brand of your shoes, and they match you that way. That is fingerprinting, and unlike a stamp, you cannot wash it off.

So the Sandbox proposed a different arrangement. Keep the notebook, but give it to the browser. The browser watches where you go, keeps its own private record, and answers a small number of narrow questions from the stages, without ever handing over the stamp. That is the whole idea in one sentence: move the memory of your browsing from the ad server's database to your own device, and let the device decide what to reveal.

It is an elegant idea. It is also a sandcastle: it only stands if the sea stays out, and in this story the sea was the third-party cookie.

Part 2: Six Years of "Next Year"

In August 2019, Justin Schuh, a director of Chrome engineering, announced the Privacy Sandbox. He opened with "Privacy is paramount to us, in everything we do", and he made the fingerprinting argument directly: "large scale blocking of cookies undermine people's privacy by encouraging opaque techniques such as fingerprinting". He also gave a money number. When cookies were removed from ad requests, he said, publisher funding fell "by 52% on average".³ And he gave a warning that turned out to be the most accurate sentence in the whole project: standards changes of this size "generally take multiple years".

The companion Chromium post that day described the ambition with a line I still love. A browser, it said, could avoid revealing "that you are a member of a group that likes Beyoncé and sweater vests" "until it can be sure that group contains thousands of other people".⁴

Then came the dates. Please keep count.

In January 2020, Chrome set its first deadline for removing third-party cookies: "Our intention is to do this within two years." The first ad-selection proposal was FLoC, Federated Learning of Cohorts, which grouped browsers into cohorts by browsing history. The EFF was not impressed. In March 2021, it called FLoC "a new way to make your browser do the profiling that third-party trackers used to do themselves".

In June 2021, the date moved. Google now planned to phase out third-party cookies "over a three month period, starting in mid-2023 and ending in late 2023".

In November 2021, a Tasmanian consultant with a fondness for tea published a post called "Google's Privacy Sandbox: What Advertisers Need to Know". It said Chrome would phase out third-party cookies by 2023. It explained FLoC and Trust Tokens in detail, and it told you to get familiar with both. If you have that post open in another tab, please close it gently. It did nothing wrong. It simply believed what it was told, which is the most common failure in this whole story.

In January 2022, two months later, Google dropped FLoC and announced that Topics "replaces our FLoC proposal". In February 2022, the UK's Competition and Markets Authority (CMA) accepted legally binding commitments from Google about how it would build the Sandbox, because removing cookies from the world's biggest browser was also a competition question. In July 2022, the date moved again, and Chrome would now begin phasing out third-party cookies "in the second half of 2024".

In 2023, the APIs finally shipped. Google targeted Chrome 115 for general availability, from late July 2023, for six APIs: Topics, Protected Audience, Attribution Reporting, Private Aggregation, Shared Storage and Fenced Frames. The origin trial ended on 20 September 2023, and Google's developer guide later reported the APIs as "available for 99% of Chrome users". In December, Google announced that from 4 January 2024, 1% of Chrome users would have third-party cookies restricted by default. The sea wall was built. One per cent of the beach was dry.

In April 2024, the date moved again. Google said it would "not complete third-party cookie deprecation during the second half of Q4" and now expected to proceed "starting early next year".

max_tokensPOST./v1/messages

Then the dates stopped moving, because the plan itself changed. In July 2024, Google wrote that "instead of deprecating third-party cookies, we would introduce a new experience in Chrome that lets people make an informed choice". The cookies would stay unless you chose otherwise. On 22 April 2025, that choice screen went too. Google decided to "maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt". The same post noted that "a lot has changed since we announced the Privacy Sandbox initiative in 2019", and it promised one new thing: IP Protection in Incognito mode, "which we plan to launch in Q3 2025".

Five days before that post, on 17 April 2025, a US federal court held that Google had monopolised open-web digital advertising markets. Google did not link the two, and I will not do it for them. I will only note that it was a busy few days in Mountain View.

With cookies staying, the CMA's reason to supervise the Sandbox fell away. Google asked to be released from its commitments on 7 May 2025. And on Friday, 17 October 2025, two things happened on the same day: the CMA closed its case, and Chavez published the retirement list.

Count the deadlines: within two years (2022), late 2023, the second half of 2024, early 2025. Four dates, then no date, then no plan. Schuh's "multiple years" was, if anything, modest.

Part 3: Inside the Butler's Pantry

stop_reasoneval:.pass

To check whether your stack depended on any of this, you need to know what these APIs looked like when they ran. They leave distinctive marks in code and in HTTP headers. So let's replace the festival with a better picture for the browser's new job: a butler.

A good butler knows everything about the household. He knows who visited, what they ate and which of them the dog dislikes. He writes it all in a locked diary in his pantry. When a merchant knocks at the back door and asks, "What does the household like?", he does not hand over the diary. He answers one small, careful question, and then he closes the door. Each of the three big Sandbox APIs was one kind of question the butler would answer. We are committed to the butler now, so let's meet the three merchants.

Topics: "What sort of thing does this household like?"

The first merchant wants to show a relevant advertisement and asks about interests. The butler's answer is the Topics API.

Each week (Google calls it an epoch), Chrome looks at the hostnames of sites you visited and maps each one to topics from a fixed public list, such as "/Pets & Animals/Pets/Dogs". At the end of the epoch, it works out your top five topics. When a caller (an ad tech script on a page) asks, Chrome returns up to three topics, one from each of the last three weeks. Each one is picked at random from that week's top five, and with a 5% chance it is a random topic from the whole list.⁵

The clever constraint is the one that makes it different from a stamp: a caller only receives topics it has observed. If adtech1.example was present on the running site and the dog site, it can learn "Running & Walking" or "Dogs". It cannot learn "Hotels & Accommodations" from a travel site it was never on. The butler only tells each merchant about rooms that merchant has already seen.

In code, Topics has distinctive marks. A script calls document.browsingTopics(). Or a fetch() includes the option browsingTopics: true. Or an iframe has a browsingtopics attribute. On the server side, the implementation guide shows the request header Sec-Browsing-Topics carrying the topics, and a response header Observe-Browsing-Topics: ?1 telling Chrome to record the visit. Keep those names. We will search for them in Part 6.

Protected Audience: "Would anyone like to bid for this space?"

The second merchant wants to do remarketing: show hiking boots to the person who looked at hiking boots. With a stamp, the ad server remembers that 7f3a9 looked at boots. With the butler, the browser remembers.

The Protected Audience API (it was called FLEDGE until 2023) works in two steps. First, on the boot shop's site, a buyer (usually a demand-side platform) asks the browser to add you to an interest group. The browser stores its name (for example custom-bikes), its owner (for example https://dsp.example) and some configuration: where to fetch bidding code, which ads it may show, and where to get live data. The call is navigator.joinAdInterestGroup().

Second, later, on a news site with an ad slot, a seller calls navigator.runAdAuction(). Now the auction happens inside your browser. Each invited interest group's bidding code runs on your device and produces a bid, using fresh data from the buyer's Key/Value service. The seller's scoring code ranks the bids. The winning ad renders in a fenced frame, a special kind of frame that keeps the ad apart from the page around it. Reports go out through reportWin() and reportResult().

It is a whole auction house moved into the pantry. The butler invites the merchants in, lets them write sealed bids on his own paper, reads the bids himself and then pins the winning notice to the kitchen wall. Nobody takes the diary home. It is also a great deal of engineering for every ad tech company involved, which becomes very important in Part 4.

Attribution Reporting: "Did my advertisement work?"

The third merchant wants to know whether his advertisement led to a sale. With a stamp, this is easy: the same identifier appears on the ad click and on the checkout page. The Attribution Reporting API asks the butler to connect the two without handing over an identifier.

On the ad side, the link or image carries an attributionsrc attribute, and the ad server responds with an Attribution-Reporting-Register-Source header describing the campaign and the site where a conversion is expected. That is a source. On the shop's checkout page, a pixel or fetch registers a trigger, the conversion. The browser matches the two itself, then sends one of two report types.

Event-level reports link one click to very coarse conversion data: three bits for a click (so one of eight categories) and one bit for a view. They are noised, which means a small share of reports are random, and they are sent with a delay.⁶ Summary reports carry richer, aggregated numbers (for example, 518 conversions from one campaign), and they are processed through a separate Aggregation Service rather than read directly.

The butler, then, will confirm that "someone who saw your notice later bought something, roughly in the category of 'shoes', probably", and he will send the letter some time later, with a small chance that he made it up. For a direct-response marketer used to a click ID on every order, that is a hard sell. Safari never liked it either; WebKit's position was negative, and it built its own Private Click Measurement instead.

page_viewtool_use

The rest of the pantry

A few other APIs supported the big three. Private Aggregation and Shared Storage let scripts write cross-site data that could only come out in aggregated or very limited form. Related Website Sets let one organisation declare that several of its domains belong together, published in a public JSON file on GitHub, so cookies could flow between them with less friction. And every company that wanted to call the ad APIs had to enrol with Google: a process Google said would take "at least five weeks", ending with a public attestation file at /.well-known/privacy-sandbox-attestations.json on the enrolled site. That file is a useful clue, and we will look for it.

Part 4: Why the Tide Came In

Here is the one-line version: the butler was only useful if the stamps were banned, and the stamps were never banned.

Every one of these APIs asked ad tech companies to do something harder than what they already did. Protected Audience moved the auction into the browser. Attribution Reporting gave coarser, slower and noisier data than a click ID. Topics gave a handful of broad interests instead of a full browsing history. The industry would accept that bargain only if the easier option disappeared. In 2019, the plan was that it would. By 2025, it would not.

The CMA's own tests, run in the first half of 2024, show the cost of that bargain. The CMA and Google identified three APIs that could be tested with numbers (Topics, Protected Audience and Attribution Reporting), and testers compared traffic with cookies against traffic without cookies but with the Sandbox. On the selling side, where the CMA had the most comparable results, publisher revenue per impression was "around 30% lower without TPCs even accounting for the availability of the Privacy Sandbox". Businesses focused on retargeting were hit harder. The castle held back some water, but not much.

So when Chrome kept cookies, almost nobody had a reason to finish their Sandbox integration. The CMA's closing decision says it directly: third-party analysis showed that uptake "remained modest and stable" after April 2025, and "fewer than 20% of sites had adopted PA API auctions", citing a September 2025 study by Garrett Johnson. The CMA's view was that the tools "will not in their current state of development be materially valuable complements to TPCs". Low adoption was not a surprise. It was the rational response.

The CMA process also contains two details that I think tell the story better than any summary.

First, when the CMA consulted on releasing Google, it received fifteen responses, and "all fifteen respondents to the consultation were against releasing the Commitments". Their worry was that Google might change its mind again, restrict cookies later, and leave rivals exposed. The CMA released the commitments anyway, because the conduct it was worried about (removing cookies) was no longer planned.⁷

Second, IP Protection. In April, Google said it planned to launch it in Incognito mode in Q3 2025. In October, it was on the retirement list, and the CMA recorded the result plainly: IP address information "will remain available in standard and Incognito mode". Q3 2025 ended on 30 September. The feature was retired seventeen days later. If you were waiting to test it, you can stop waiting.

What Google kept

The retirement is not a full clearance. Chavez named three things that stay, and Google's feature status page, updated the same day, fills in the rest.

CHIPS (Cookies Having Independent Partitioned State) stays. It is a cookie attribute, Partitioned, that gives an embedded service a separate cookie jar for each top-level site. A chat widget on shop.example can remember your conversation there, but it cannot read the same cookie when it loads on news.example. In festival terms, each stage stamps its own hand, and the stamps wash off at the gate.

FedCM (Federated Credential Management) stays. It is a browser-level way to sign in with an identity provider that still works for people who say "no" to third-party cookies.⁸

Private State Tokens stay. These were called Trust Tokens when my 2021 post introduced them, which makes them the one prediction from that post that survived. They let one site vouch that a visitor seemed human to another site without passing an identifier, to help fight fraud.

The status page also keeps the unglamorous plumbing: the Storage Access API, bounce tracking mitigations, storage partitioning, User-Agent Client Hints and Fenced Frames. And for measurement, Google says it will keep working on an interoperable Attribution standard in the W3C's Private Advertising Technology Working Group, with other browser makers. That is a standards proposal, not something you can deploy this quarter.

utm_source=SELECT

Notice the pattern. What survived is the part of the Sandbox that fixes cookies and sign-in without rebuilding advertising. What went is everything that tried to rebuild advertising inside the browser. The status page adds more names to the retired list than the blog post does, including Script Blocking and Probabilistic Reveal Tokens, which never launched at all. Google says the phase-out will follow Chrome's normal deprecation process and that documentation for retired technologies will stay online. As of this week, it has not published removal dates, so neither will I.

Part 5: The Consent Question Never Left

Now the part that I most want you to take to your next meeting. Retiring the Sandbox changed a lot of engineering plans. It changed nothing about your consent obligations.

This surprises people, because the Sandbox was often sold as "privacy-preserving advertising", and it is easy to hear "privacy-preserving" as "no consent needed". That was never true, and Google's own documentation said so. On the Topics implementation guide, in a caution box, Google wrote that "accessing topics involves accessing information stored on the user's device", and that in the EU and UK, "ePrivacy laws require you to obtain consent from the end user before you access this data", "just the same as you need consent for cookies".

Here is why, and it comes down to what the law actually regulates. The EU and UK rules do not regulate cookies as such. They regulate storing information on, or reading information from, a person's device. In the UK that is regulation 6 of PECR (the Privacy and Electronic Communications Regulations). The ICO's draft guidance, updated in July 2025, lists what that covers: cookies, tracking pixels, link decoration, web storage, fingerprinting techniques, and scripts and tags. The test is the act of storage or access, not the brand name of the technology.

Walk each API through that test. Topics reads a list of interests the browser stored on your device. Protected Audience writes an interest group to your device and later reads it to run an auction. Attribution Reporting stores a source registration and later reads it to match a conversion. Each one stores or reads something on the device. So for advertising, each one needed the same consent as the cookie it was meant to replace. The butler was more discreet than the stamp, but he still lived in your house.

The ICO's chapter on online advertising is blunt about the purpose too: "The use of storage and access technologies for online advertising purposes requires consent". That covers ad selection and delivery and any tracking and profiling that goes with it.⁹ And the CMA, in the decision that closed its case, added a footnote reminding everyone that "under regulation 6 of PECR, consent may be required to store or access data on a user's device", and that Google itself "will still be required to comply with UK data protection law".

So there are two practical consequences.

First, if you removed consent gating from a Sandbox integration because someone told you it was "privacy-safe", that was a problem before 17 October, and the retirement does not fix it retroactively. Check it.

Second, the retirement means the third-party cookie is, once again, the main cross-site tool in Chrome for the foreseeable future. Your consent banner, your consent management platform and your consent mode set-up are all doing the same job they did in September. I wrote about what happens when that job goes wrong in No Consent, No Conversions. Nothing in October changed that article.

The ICO also gives a useful hint about direction. It says contextual advertising "more readily enables you to comply" with both PECR and UK GDPR than other kinds of targeted advertising. When the fancy replacement disappears, the old, boring alternative does not become less compliant. It becomes more attractive.

Part 6: Ingrid Checks Her Stack

aria-labelgtm.js

Meet Ingrid. She is made up. She runs analytics and ad operations for a mid-sized apple and cider business in the Huon Valley that sells online to Australia, New Zealand and the UK. She has a .com.au site, a .co.nz site, a .co.uk site and a shared checkout. She has Google Tag Manager, a server-side container that a contractor set up in 2023, one demand-side platform, a retargeting vendor and a consent platform. On Monday, 20 October, her manager forwards her the Google post with one word: "Us?"

Ingrid gives herself a week. Here is what she does, step by step.

Monday: search the code and the containers

Ingrid exports every Tag Manager container as JSON, pulls the site's front-end repository, and saves the HTML of the home page, a product page and the checkout confirmation page from a normal browser session (after accepting all cookies, so that the ad tags actually load). Then she searches all of it for the marks from Part 3:

• Topics: browsingTopics, browsingtopics, Sec-Browsing-Topics, Observe-Browsing-Topics
• Protected Audience: joinAdInterestGroup, runAdAuction, fencedframe
• Attribution Reporting: attributionsrc, attributionReporting, Attribution-Reporting-Register-Source, Attribution-Reporting-Register-Trigger
• Related Website Sets: requestStorageAccessFor

Her own code has none of them. That is the common result: a site's own code rarely called these APIs directly.

Tuesday: look at what the vendors load

Vendor scripts are where the Sandbox usually lived, so Ingrid opens Chrome's DevTools on the same three pages. In the Network panel she searches the request and response headers for Sec-Browsing-Topics and Attribution-Reporting-Register-Source. In the Sources panel she searches the loaded scripts for browsingTopics and joinAdInterestGroup.

She finds attributionsrc on the retargeting vendor's click tracker and a browsingTopics call inside the demand-side platform's tag. So two vendors were at least asking the butler questions. That tells her what to ask them, not what to fix herself.

Wednesday: check the public records

Ingrid checks two public clues. First, she requests https://<each domain>/.well-known/privacy-sandbox-attestations.json. If that file exists, someone in the company enrolled with Google to call the ad APIs directly. Her domains return 404, which confirms that only vendors called them.

Second, she searches the Related Website Sets JSON file for her three domains. They are there: the 2024 sprint submitted them so that the shared login would survive cookie deprecation. That integration is now on the retired list. Because Chrome still allows third-party cookies by default, the login still works today, but she writes it down as the only item that is truly hers to replace. She also finds a Permissions-Policy: browsing-topics=() header that a developer added in 2023 to keep Topics off the checkout. It can stay; it does no harm, and it can be removed later, in a normal clean-up.

Thursday: ask the vendors three questions

Ingrid sends the same email to both vendors:

1. Which Privacy Sandbox APIs does your tag call on our site, and for which feature?
2. What do you use instead when the API is not there (in Safari, in Firefox, or in Chrome for users who block third-party cookies)?
3. Is any of that fallback set or read before our consent platform says yes?

The first question maps the damage. The second tells her whether anything will change: usually, a vendor already has a non-Sandbox path, because Safari users never had these APIs. The third question is the one from Part 5. It is the question that matters most, whatever the answer to the first two.

Friday: choose the replacements

By Friday, Ingrid's spreadsheet has both columns filled in. For her, the replacements are ordinary:

• Measurement: first-party data first. Her orders, her CRM and her own first-party cookies are the base. I explained the difference in Cookie Party, and it matters more now, not less. Conversion data goes to ad platforms through their consent-aware server-side integrations, sent from the server container she already pays for. Google's own description is the reason to like it: the server runs in an environment you control, and "only you have access to the data in the server until you choose to send it elsewhere". If server-side tagging is new to you, start here.
• Remarketing: her own customer lists, uploaded with consent, plus contextual placements (cider content, apple content, Tasmanian food content). No browser auction required.
• The shared login across three domains: move sign-in to a single domain with a redirect, or look at FedCM if her identity provider supports it, rather than depending on cross-site cookies that another browser already blocks.
• Embedded widgets: her reviews widget and chat widget are the kind of third-party embeds that CHIPS was built for. She asks both providers whether their cookies use the Partitioned attribute.
• Fraud: no change. Her payment provider already handles it, and Private State Tokens, if she ever needs them, are staying.

Then she writes a four-line reply to her manager: "Two vendors used retired APIs. Both have fallbacks. Our only direct dependency is the three-domain login, which still works and which I will move to one sign-in domain next quarter. Consent gating checked and unchanged."

That is the whole job. It took a week because she did it properly, not because it was big.

A short checklist for your week

If you want Ingrid's week in one list:

1. Search your code and container exports for the API names above.
2. Search the headers and scripts in DevTools on your key pages, with consent accepted.
3. Request /.well-known/privacy-sandbox-attestations.json on each of your domains.
4. Search the Related Website Sets JSON for your domains.
5. Ask each ad and measurement vendor the three questions.
6. For each dependency, write the first-party or server-side replacement next to it.
7. Confirm that every tag that stores or reads data on the device waits for consent where your law requires it.

Final Thoughts

Back to the kitchen on that Saturday morning, and the epic with 41 subtasks. Most of those subtasks can now be closed with a clear conscience and a short comment: "Retired upstream, 17 October 2025." A few of them, the ones that said "improve first-party data" or "move conversions server-side", should stay open, because they were always the real work.

The Privacy Sandbox was a serious attempt to solve a real problem. The idea of moving the notebook from the ad server into the browser was elegant, and parts of it (partitioned cookies, federated sign-in, fraud tokens) will outlive the rest. But it was built on a beach, and its survival depended on the sea staying out. When Chrome kept third-party cookies, the tide came back in, exactly as tides do. That is not a scandal. It is geography.

The takeaway is simple. Check whether your stack depended on a retired API. It probably did so only through vendors, and they probably have fallbacks. Then put your effort where it was always going to pay off: data you collect yourself, with consent, sent from a server you control. That castle is built on rock, and it does not need anyone's roadmap to stay standing.

So this week, run the seven checks. Close the subtasks you can. Leave the good ones open.

Now, if you'll excuse me, my tea has gone cold while I wrote this, and a 2021 blog post is looking at me from another tab. I think I will put the kettle on first.

Notes

1. StatCounter puts Chrome at 55.01% of all Australian browsing and 71.86% worldwide in September 2025. It is one tracker's sample, so treat the figures as a good indication, not a census. ↩

2. The festival stamp is the short version. The difference between first-party and third-party cookies, with a party analogy that got out of hand, is in the 2022 Cookie Party post on this site. ↩

3. Google's footnote says the 52% figure came from Google Ad Manager data for 500 global publishers, in an experiment from May to August 2019 where cookies were turned off for a random share of each publisher's traffic. It is Google's own study, of Google's own product. ↩

4. In a Tasmanian winter, a sweater vest is not a fashion statement. It is the second of four layers, and nobody can see it. ↩

5. The random topic exists so that no single topic returned can be taken as proof of your interests. If a caller gets "Dogs", it cannot be sure you like dogs; there was a one-in-twenty chance the browser picked a topic at random. ↩

6. In the event-level reports, noise means that for a small share of registered sources the browser sends random report data instead of the true result. The delay stops a site from linking a report to a visit by the time it arrives. Both protect the individual and cost the advertiser precision. ↩

7. James Rosewell, co-founder of Movement for an Open Web, the group whose 2021 complaint started the CMA case, warned in AdExchanger's report that Google "is a known recidivist" that "could easily U-turn again". The CMA's answer was that, if Google did change course, renewed scrutiny under competition law, including the new digital markets regime, may be appropriate. ↩

8. Chavez's post says CHIPS and FedCM have "support from other browsers". Google's own feature status page, updated the same day, still said "FedCM isn't supported in other browsers yet", with Mozilla building a prototype. Check your users' browsers before you rely on FedCM alone. ↩

9. The ICO's draft guidance adds that measuring how well the advertising worked does not need a separate consent, because measurement is part of the same advertising purpose. It still needs the advertising consent itself. ↩