SameSite Cookies, Chrome 80, Privacy Sandbox – What's What?
Why Google is rushing to bury cookies in the past, and what it will result in for everyone else.
SameSite Cookies, Chrome 80, Privacy Sandbox – What’s What?
Why Google is rushing to bury cookies in the past, and what it will result in for everyone else.
What’s the point of recent Chrome updates?
Since 2016, Chromium has supported the SameSite cookie attribute, which limits access to cookies to same-site requests. The attribute has three values:
- Strict – exclusively within the website they were initially set on.
- Lax – within the website and when the user opens a URL by following a link (top-level navigations using a safe HTTP method).
- None – along with any cross-site requests.
In theory, SameSite helps protect data from unreasonable tracking and cross-site request forgery. But if website developers have not set the attribute, the server automatically assigns SameSite=None, treating cookies as third-party and sending them freely. According to Google, as of March 2019, only 0.1% of cookies are marked as SameSite.
Therefore, in May 2019, Google and Microsoft published the “Incrementally Better Cookies” draft, proposing that all cookies be treated as first-party by default. As an experiment, these settings were introduced for a small number of Chrome users in October 2019. In February 2020, Google officially launched the new settings in Chrome 80 Stable.
Now, cookies can be sent to third-party domains only through HTTPS, and only if their attribute is explicitly changed from the default SameSite=Lax to SameSite=None.
So far, the new settings have been rolled out to a fraction of Chrome 80 Stable users, and their proportion is gradually increasing. With Chrome 81–82 Canary/Dev/Beta, the SameSite behavior will extend to 50% of users and continue to grow.
Microsoft Edge and Mozilla Firefox will roll out similar settings.
Settings have changed, so what?
If everyone moves to HTTPS and sets appropriate cookie attributes, nothing will change for websites, users, or advertisers. The internet will work as before—just a bit safer.
The fun part begins with the next step. In Google’s view, good cookies are dead cookies. Google expects to get rid of third-party cookies within two years and suggests HTTP State Tokens and a set of APIs instead. This initiative is called Privacy Sandbox.
The internet relies on cookies
Authentication; browser history; media element views (players, banners, share buttons); metrics, measurement, and tracking; webpage adjustment to device, browser, and user settings—all rely on cookies to store and transfer relevant data.
However, the versatility of cookies becomes a disadvantage, as it enables uncontrolled user tracking.
Google proposes using HTTP State Tokens instead. The browser sends an encrypted token to the website server via an HTTP header—only one token per origin and only through a secure channel.
The token value is controlled by the client, not the server, and looks like a random fixed-length byte string. The server knows nothing about the user, but can sign verified tokens with its encrypted key and return attributes such as:
- token creation timestamp,
- delivery context (same-origin, same-site [default], cross-site),
- token lifetime (1 hour by default),
- token value.
What will change when cookies are removed?
Since websites cannot track users without data (ignoring fingerprinting and other workarounds), the principles and mechanisms of monetisation based on online advertising will need a complete overhaul. User targeting is likely to be gone for good.
Google proposes several substitute APIs:
1. Anti-fraud: Trust Token API
The website issues non-personalized encrypted tokens to trusted users, which can be “spent” on other websites.
2. Ad conversion measurement
The current version does not support impression counts; only aggregated click data are available. The browser generates conversion reports based on redirects and sends them in bulk several times a day, with noise applied. Reports include metadata about the impression, the conversion, and the credit the impression received (0–100).
3. Aggregated reporting
The API determines the number and frequency of unique views of an ad campaign across multiple domains.
4. Interest-based targeting: FLoC (Federated Learning of Cohorts)
Based on browsing history, browser ML algorithms group users into broad cohorts with similar interests and send this information through Client Hints (which will replace the User Agent string).
5. Retargeting: TURTLEDOVE
Advertisers form interest groups—lists of users for retargeting. The browser regularly requests ads for a particular group and pre-caches creatives. When a user opens a website, the browser requests a contextual ad and runs an auction between it and a pre-loaded interest-based ad.
Are these changes for the better or not?
The overall trend of giving users control over their data is undoubtedly positive. The growing use of cryptography is also beneficial. At the same time, cookielessness only prevents tracking through cookies—there are still many ways to track a unique user, over which they have no control.
Online advertising, however, faces major challenges:
- essential functionality moves to the browser side, and no one knows exactly how to make it all work;
- Google’s proposed APIs do not cover all use cases and are still crude;
- the absence of personalized ads may impact publisher monetisation;
- the power dynamics between ad-tech, publishers, advertisers, and browsers will shift;
- transitioning to a cookie-less internet in two years may not be painless—and at whose cost?
And the final question:
Does the advertising industry use cookies and track users out of necessity— or simply because it can?
Only time will tell.
