
Google starts testing its replacement for third-party cookies - kiyanwang
https://www.engadget.com/google-tests-ad-trust-tokens-223104543.html
======
Havoc
Google leading this effort is completely ridiculous.

Whatever comes out of it is bound to either not be great for privacy or it
will be an improvement but hit the smaller players. ie everyone not google. eg
take away Cookies to prevent tracking. Leaving them the only one company with
sight of near everything (google analytics & Adsense & Chrome). And we already
know from recent revelations that google isn’t above peeking under the hood of
data sources they shouldn’t.

Whole thing seems insanely monopolistic to me.

~~~
mda
Do you have any actual technical counterpoints?

~~~
imglorp
I think the problem is the hens are watching the fox design the coop. They've
been invited to participate, but the fox has unlimited resources at its
disposal for research and planning while the hens are of meager means.

So yes, it may be unkind to prejudge the fox, but based on years of prior
malice towards all poultry in the yard, and without fully understanding its
plans, we have to assume it won't turn out well for us chickens.

Cluck.

------
kelnos
I'm really confused. I'm reading the spec[0], which seems to explicitly state
that it's not possible (modulo some possible vulnerabilities with mitigations
that they later list) to track a user across the web using these tokens. Yet
many of the comments I read here are talking about this being a way for
websites to track users?

This spec document also doesn't really list use cases for this. Why would I
want this? The linked article seems to suggest it's so Google can reduce ad
fraud, which of course I don't give a damn about, and don't want my user agent
doing anything that helps advertisers, ever.

Hopefully Firefox does not implement this, and hopefully if they don't,
websites don't somehow penalize browsers that don't support it.

[0] [https://github.com/WICG/trust-token-
api#overview](https://github.com/WICG/trust-token-api#overview)

~~~
nwellnhof
Trust tokens are only one of several separate proposals to remove third-party
cookies. The so-called Privacy Sandbox will also include other technologies.
Tracking cookies are planned to be replaced with Turtledove and FLoC. The
latter is about running machine learning algorithms _in your browser_ to infer
your interests.

[https://www.chromium.org/Home/chromium-privacy/privacy-
sandb...](https://www.chromium.org/Home/chromium-privacy/privacy-sandbox)

~~~
eis
> The latter is about running machine learning algorithms in your browser to
> infer your interests.

Oh nice, sounds like my information will now not only be sent to someone else,
I even will be doing the computation for them to increase their margins and
pay with reduced battery life. Awesome!

~~~
everdrive
Do we think this will use javascript? Perhaps we can just block javascript.

------
SquareWheel
Much better article: [https://www.zdnet.com/article/google-launches-chrome-
extensi...](https://www.zdnet.com/article/google-launches-chrome-extension-
for-ad-transparency-trust-token-api/)

Trust Token Github page: [https://github.com/WICG/trust-token-
api](https://github.com/WICG/trust-token-api)

I'm glad to see it uses Privacy Pass as a basic mechanism.

------
alextheparrot
From [https://github.com/WICG/trust-token-api](https://github.com/WICG/trust-
token-api)

> Token Exhaustion Attack

> Issuers issue many tokens at once, so users have a large supply of tokens.

> When the issuer detects a site is attacking its trust token supply, it can
> fail redemption (before the token is revealed) based on the referring
> origin, and prevent browsers from spending tokens there.

I think there’s an interesting trade-off between attack surface and
specificity of the token here. A token meaning “This user has only accessed 6
sites in this network” is meaningful only if there’s a single token, as the
next access can cause the token to be inconsistent with reality (It states a
falsity now).

At the same time, it states the issuer can block redemption based on the
referrer. I think that’ll be interesting, as an allow list format will lead to
only “big players” being able to use this API (As they are the only ones who
they trust to not adversarially redeem tokens) whereas a deny list you’re
playing a game of whack-a-mole where new domains can be popped up for this
purpose.

edit: added the last part of the quote for completeness

------
mikro2nd
"Trust tokens are meant to foster user trust across sites"

Can anyone shed light on what exactly this "trust token" mechanism is? It
sounds to me like some sort of cryptographic identifier that will enable
Google to track our every move (to the limited extent we use Chrome and
Google's websites) but this would be contradictory to their claim of non-
identifying privacy.

~~~
JPLeRouzic
[https://github.com/WICG/trust-token-
api#overview](https://github.com/WICG/trust-token-api#overview)

For what I understand, a provider who trust a user, stores in her browser a
set of kind of certificates, that basically declare "I "provider NNN", states
that this user has been authenticated by me".

Another party will ask for one trusted token, verifies that it is really
signed by provider NNN, and can trust that each time this token is resent, it
is the same user.

The privacy is respected on the user side has the third party has no idea who
is this user. The trusted tokens could even have a short life. Third parties
therefore should have great trust in the trust token provider.

It is as if Google authorized other parties to use its own cookies.

Indeed this means that other parties trust "provider NNN". I guess that Google
wants to become a more central identity provider than today, where it has to
share this role with Facebook and a few other companies.

~~~
ocdtrekkie
Sounds like something I still will expect my privacy-respecting browser to
block in its entirety. It's not meant to benefit me, it's designed to prevent
"ad fraud".

~~~
gruez
>Sounds like something I still will expect my privacy-respecting browser to
block in its entirety

prepared to get penalized by recaptcha for not having it enabled.

~~~
FridgeSeal
So nothing will change then?

ReCaptcha already appears to have some grudge against me, presumably by virtue
of running Firefox and comprehensive ad-blocking, so blocking yet another
google thing isn't going to make my life substantially worse.

~~~
hetspookjee
May I ask what kind of setup you're running with Firefox? I'm having Firefox
on a MBP with only uBlock but I rarely get any recaptcha. Am I mistaken in
thinking I'm securing my privacy?

~~~
mcintyre1994
Are you logged into Google? Not on Firefox itself, just in one of their
properties. I have the same setup and don’t get recaptcha either, I think it’s
probably because I’m either logged into my personal long-standing gmail or my
work g suite account. My guess is if I used the container stuff to isolate
Google like I do Facebook then it would start triggering it.

I do get recaptcha all the time in Safari on iOS despite being logged into
Google there too, not sure what that’s about.

~~~
WorldMaker
I only login to Google in a dedicated Firefox Container, and yes I'm getting
really sick of ReCaptcha. It's amazingly user hostile at this point, and I
suppose that it doesn't help that I need two or three attempts at this point
to "pass" its challenges, because its machine learning algorithm and I
disagree on what constitutes a "street sign" or something dumb like that. It's
making me want to avoid websites that use ReCaptcha challenges altogether.

------
Animats
And, let me guess, you can't block "trust tokens" in Chrome.

~~~
rasz
You cant disable service workers either (except using hack with uBO)

------
speedgoose
Well, how can we tell Google that they shouldn't have a say on this topic?

~~~
encom
Stop using the invasive malware that is Chrome.

~~~
speedgoose
That will do nothing I'm afraid. I already don't use Chrome, and even if I
spend all my free time asking people to stop using Chrome for weird technical
reasons from their point of view, I'm afraid that will do nothing compared to
the advertising power of Google.

~~~
danaris
Indeed: it is far past the time when individual action would make a difference
to Google. The only way to actually get them to listen is going to be to
consistently vote for people who a) have a reasonable chance of winning their
election, and b) support modernizing and enforcing our antitrust regime. (It
is likely that this will need to be done incrementally, and it may require
first replacing (b) with increasing levels of support for getting corporate
money out of politics.)

------
0xy
So this will be used entirely for invasive tracking by Google's advertising
arms. Calling it a "trust token" is gaslighting, since the data being
collected and distributed to advertising companies is not properly disclosed
nor easy to disable.

Google has a habit of obscuring such practices, like the hard-coded "X-Client-
Data" tracking backdoor header they send to DoubleClick and is _impossible to
disable_ , and _never disclosed to anyone_.

If they'll do "X-Client-Data", you can be sure this backdoor will be even
larger.

~~~
joshuamorton
So I think we've had this conversation before, but what do you believe that
header is used for?

Are you claiming that Google uses it for things beyond what they claim to and
that Google is lying when it claims to not be using the header for ad
tracking?

~~~
0xy
Without repeating the same arguments, it's possible that Google is using it
for tracking purposes because their public statements were ambiguous. That
aside though, this behavior is never disclosed to users and is __impossible to
disable __.

Do you think the average user knows that Chrome is sending unique identifiers
to DoubleClick? Of course not, it was never disclosed and they were never
given the option to disable it.

~~~
joshuamorton
Can you explain what is ambiguous about "This information helps us measure
server-side metrics for large groups of installations; it is not used to
identify or track individual users."

> Do you think the average user knows that Chrome is sending unique
> identifiers to DoubleClick?

What's your actual concern? What you've described here applies to nefarious
data like the IP address.

~~~
0xy
Okay I presume you've never worked in the ad or tracking industry, because the
data being sent to DoubleClick without notification is __gold __for tracking
purposes.

This can also be considered anti-competitive behavior. DoubleClick has access
to orders of magnitude more tracking data than its competitors.

IP Addresses cannot be used to differentiate devices. X-Client-Data can,
easily.

My concerns are:

\- Their statement is ambiguous, and does not rule out use for tracking or
advertising purposes, nor does it rule out future use for individual user
tracking.

\- This "feature" was added sneakily. No notification, there's no user
disclosure. Nothing. That just screams suspicious, given the value of the data
being sent.

\- It __cannot be disabled __. This is the key point. _Why can 't it be
disabled?_

\- DoubleClick is in the whitelist for no reason other than ad tracking
purposes. The amount of websites who make calls to DoubleClick and __not __GTM
or GA must be vanishingly small. So the argument that you want to collect the
most data is disingenuous. 87%(!!!) of the top 100,000 websites globally make
calls to GA.

My concern is Google has sneakily added a feature that can be used for
tracking purposes while refusing to disclose it to end users and making it
__impossible to disable __.

~~~
joshuamorton
> Okay I presume you've never worked in the ad or tracking industry

Yes and no. I work on tooling very similar to the actual, intended, use of the
x-client-data header (aggregate performance analysis).

> because the data being sent to DoubleClick without notification is gold for
> tracking purposes

What does it provide that other data that is accessible does not?

> IP Addresses cannot be used to differentiate devices.

Ah, I see, so in the case of multiple logged-out but non-incognito chrome
users in the same household, x-client-data could be used to better target ads
to specific devices in the household, instead of the household as a whole.
That's the "gold" here?

> \- This "feature" was added sneakily. No notification, there's no user
> disclosure. Nothing. That just screams suspicious, given the value of the
> data being sent.

Sure, sort of, in 2012[0]. Doubleclick was added a bit later, in 2014[1]. The
reasoning, at the time, is provided in the linked bug[2]. Sure looks
nefarious. So was this an 8+ year scheme?

Now, there are (at least) two possible ways to look at this, either it's an
almost decade long scheme, or alternatively no one on chrome had any intent of
ever tracking individual users, and it wasn't even considered.

The bug also provides some more insight, doubleclick and GA serve different
types of data, and that might matter for measuring things about QUIC.

> DoubleClick is in the whitelist for no reason other than ad tracking
> purposes. The amount of websites who make calls to DoubleClick and not GTM
> or GA must be vanishingly small.

Literally the first website I picked, CNN.com, has doubleclick sources, but
not GTM or GA (at least as far as I can tell).

> and does not rule out use for tracking or advertising purposes

I will once again ask for a scheme by which the header is both useful for
tracking or advertising, and isn't used for tracking individual users. It
seems like you're claiming that Google is attempting to split hairs and say
that tracking individual devices is different from tracking individual users.

I've explained before why something like x-client-data can actually be a
useful privacy-preserving tool elsewhere[3] (since it allows you to join
across a quasi-identifier instead of a PII-identifier).

[0]:
[https://chromium.googlesource.com/chromium/src.git/+/f89fdab...](https://chromium.googlesource.com/chromium/src.git/+/f89fdab13152123f737dc84f5910362fa6569f7f%5E%21/chrome/browser/renderer_host/chrome_resource_dispatcher_host_delegate.cc)

[1]:
[https://chromium.googlesource.com/chromium/src.git/+/64d617e...](https://chromium.googlesource.com/chromium/src.git/+/64d617ec7c502ea5ce5ec8f6f97580000541a854)

[2]:
[https://bugs.chromium.org/p/chromium/issues/detail?id=379341](https://bugs.chromium.org/p/chromium/issues/detail?id=379341)

[3]:
[https://news.ycombinator.com/item?id=22244282](https://news.ycombinator.com/item?id=22244282)

~~~
0xy
>Literally the first website I picked, CNN.com, has doubleclick sources, but
not GTM or GA (at least as far as I can tell).

I can see they're preloading GTM scripts, which means those requests are
absolutely made. I can't tell if the script is executed, but that doesn't even
matter since it's requested.

Just open up your network console and filter by "Google". There are numerous
requests to Google services, including Google.com and GoogleTagServices.com.

>I will once again ask for a scheme by which the header is both useful for
tracking or advertising, and isn't used for tracking individual users.

Tracking groups of users.

>So was this an 8+ year scheme?

Even worse. Google had 8 years to adequately disclose to users the DoubleClick
tracking or allow them to disable it. To this day, disabling is not possible
(not even via config).

>Ah, I see, so in the case of multiple logged-out but non-incognito chrome
users in the same household, x-client-data could be used to better target ads
to specific devices in the household, instead of the household as a whole.
That's the "gold" here?

Yes, this is why ad networks tend to run fingerprinting scripts.

Tracking specific devices is huge. That's partially why the ad industry took a
huge hit when Safari cracked down on third-party tracking.

~~~
joshuamorton
> Tracking groups of users.

I asked for a scheme. How are they differentiating between individual devices
without tracking individual users. Again: you seem to be claiming that Google
is using some form of linguistic trickery here, but you're unwilling to
describe exactly what that trickery is. I content this is because it'll sound
ridiculous when you actually say it, so you resort to dancing around it
instead.

This isn't good for _anyone_ by the way, it is a disincentive for companies to
use clear language to communicate with consumers (which is a pet peeve of
mine). Assuming Google isn't actively trying to mislead, which is more useful
to the average consumer, the statement they made, or the legalese they'd need
to assuage your concerns?

> Even worse. Google had 8 years to adequately disclose to users the
> DoubleClick tracking or allow them to disable it.

Sort of. No one cared until March of 2020. Not like only the privacy wonks, I
mean like literally no one, I can't find reference to the x-client-data string
on the internet prior to 2020 except in [https://unsearcher.org/more-on-
chrome-updates-and-headers](https://unsearcher.org/more-on-chrome-updates-and-
headers), which found it _in the Chrome whitepaper_. So is your contention
that explicitly describing a header and how it is used in the whitepaper on
privacy is not adequate disclosure? Or even that including it in the
whitepaper is somehow "the deliberate decision to not disclose this tracking"?

That seems pretty far a reach to me.

> Yes, this is why ad networks tend to run fingerprinting scripts.

But does Google? Did Google ever? As far as I know the answer is no, Google
doesn't claim to use any advanced fingerprinting techniques, which means your
accusation, when fully fleshed out is

"In the case of multiple logged-out but non-incognito chrome users in the same
household, x-client-data could be used to better target ads to specific
devices in the household, instead of the household as a whole, to better
fingerprint devices in a a way that Google has never attempted to do before,
and this was intentionally never disclosed."

Because if you're logged in, the x-client data doesn't matter, you have the
user id. And if you're one person per household, it doesn't matter. So the
only groups this matters for are the people who don't use any Google products
but who use chrome but also aren't privacy conscious enough to use an ad-
blocker. I can't imagine that group is very big.

And the only way to reach this conclusion is to

1\. Assume that this was _intentionally_ not disclosed, as opposed to
accidentally not disclosed. There's evidence that it was and is disclosed,
just not in ways you personally feel are enough. There's evidence that it was
not intentionally hidden.

2\. Assume that Google is intentionally misleading you with sneaky wording, in
ways that are more reminiscent of freeman-of-the-land style legal tomfoolery
than actual things that businesses, even unethical ones, do.

3\. Assume that all of this was done to continue to do a thing that there's no
evidence that Google has ever done.

The amount of bad faith you have to assume is staggering.

> Additionally, Google could be compelled to use this data to track users and
> lie about it publicly through the use of National Security Letters or other
> nation state mechanisms.

Which leaves us with this, which I'd consider perhaps plausible, but unlikely.
My understanding is that NSL-style mechanisms can compel companies to provide
data, but not to build infrastructure. So if the data isn't joinable, an NSL
couldn't compel a company to modify things so that it _is_ joinable.

There are fair concerns about why this isn't opt-out. But your concerns go so
far beyond anything reasonable that they deserve pushback.

~~~
jsnell
You're not finding earlier discussions since the header was renamed at some
point. It was originally X-Chrome-Variations.

~~~
joshuamorton
Which provides one additional hit: this stackoverflow question, which also
references the whitepaper[0].

[0]: [https://stackoverflow.com/questions/12183575/what-is-
followi...](https://stackoverflow.com/questions/12183575/what-is-following-
header-for-x-chrome-variations)

------
itissid
Is there a good article/video explaining how third party cookies work and then
how the ad fraud itself works in this context?

I would like to send it to someone with very little knowledge of this world
and what problem this feature intends to solve.

------
sunsetSamurai
will I be forced into this even if I use firefox?

~~~
pm90
Probably not since this is chrome specific. If it becomes a standard and
publishers start blocking/restricting browsers that don’t support it well,
that would be a different story.

~~~
SheinhardtWigCo
That is the only logical endgame, otherwise why bother pushing this?

------
8organicbits
> the company hoped to phase out third-party cookies in Chrome once it could
> meet the needs of both users and advertisers.

Chrome, the browser, can't change how web servers are implemented. Users needs
are met as long as web servers behave as they should. I've disabled 3rd party
cookies and haven't seen any issues (I'd suggest others try it as well).

I suspect mostly advertisers are affected at this point.

If this becomes a thing, I'll block it in my browser.

~~~
michaelt
I do the same - there are a number of Google properties that get broken.

Usually because they try to provide named-users-only access to user-generated
content, then exile user-generated content to other domains (like
googleusercontent.com ) and one can't be logged in on the other domain without
cookies.

I've filed bugs with Google about this behaviour, and had them accepted as
valid, but they don't seem in a hurry to fix them - I assume because third-
party tracking is google's core business.

------
sveme
They must have the most atrocious, darkest, GDPR confirmation dialog. It's
absolutely impossible to understand what you opt-in to.

------
jwilk
Archived copy without GDPR nag screen:

[https://archive.md/U4axx](https://archive.md/U4axx)

~~~
sveme
Thanks, doing the gods' work here.

------
Markoff
So how do I block this in uBlock?

------
zozin
This, like AMP, looks like a blatant attempt by Google to lock in
users/advertisers into the Google ecosystem. If you're going to leverage your
monopoly to harm end users, then the time for lax government regulations is
over.

~~~
echelon
Google needs to be stripped of its ad business. They need to lose Chrome and
Android. They can't embrace, extend, extinguish the Internet. They're
seriously harming the web with Chrome, AMP, and other initiatives.

Apple needs to be strictly hardware or software. They can't continue to run an
exclusive app store and tax 30%. When you buy the device, it's yours. You
should be able to upgrade and change the software.

Facebook can't be allowed to acquire any more social media companies. They
need to be mandated to provide account data export, and they can't create
shadow profiles without consent.

Amazon can't be allowed to compete with its sellers. Every act of espionage
needs to be confirmed and awarded $100M or more. Out of all the companies,
their behavior is the most gut-wrenchingly evil and steps on the upstarts.

Call your representatives and demand this.

Microsoft, surprisingly, is acting like a trillion dollar company that isn't
run like a monopoly. Their tools and ecosystem play nice with others.

~~~
joedevon
Let's dive into this. But first, we need to update the anti-competitive rules
so we have a general theory that makes sense. The current rules allow for non-
competitive behavior as long as you have low prices which are good for
consumers. That's why Amazon is safe. The hole is that this doesn't protect
against predatory pricing where you kill all competitors and then can charge
anything.

Google is certainly a problem. I'm not personally against divesting chrome and
amp and some others. But I can see people disagreeing.

Apple's DNA is that by combining hardware and software, they make high quality
products. Don't kill the magic. The tax on the ecosystem seems usurious. The
app store could be a target for some action imo.

I probably disagree the least with your ideas on FB.

I doubt strongly that Amazon systematically uses espionage to steal good
ideas. It's such a monster that it's bound to start a product similar to what
they were informed about. And maybe a rogue employee here and there, but I
doubt this is a big problem. They have a million other issues, but I don't
think you hit the nail on the head.

These are just my personal take. Strong opinion, weakly held.

~~~
TheMblabla
Just out of curiosity, what's wrong with Chrome and Amp?

~~~
echelon
Chrome and Amp are Google lock-in web killers.

Google is pushing ahead in the browser space, ignoring standards committees.
They're doing things that deepen their moat.

Google made choices in HTML5 to make it less semantic, ensuring their search
engine wins.

Google is trying to remove the URL bar, which makes Google homepage and AOL-
like keywords the dominant way to access information. It lowers awareness of
brands and websites as 3rd party entities.

AMP hosts content on Google's servers. You never actually access the original
publisher's website. Guess how you get higher search rankings?

I should compile a list sometime. It's actually quite astonishing how much
they're eroding the commons to entrench themselves.

