Google starts testing its replacement for third-party cookies
engadget.com
engadget.com
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.
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.
Not everything is a pure engineering problem.
But at the end of the day, with most people still using Chrome and giving away their browsing history to Google without a second thought, I don't think Google is too worried at this point.
Google - all the data
That's what this is
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.
Additionally, a subset of low entropy variations are included in network requests sent to Google. The combined state of these variations is non-identifying, since it is based on a 13-bit low entropy value (see above). These are transmitted using the "X-Client-Data" HTTP header, which contains a list of active variations. On Android, this header may include a limited set of external server-side experiments, which may affect the Chrome installation. This header is used to evaluate the effect on Google servers - for example, a networking change may affect YouTube video load speed or an Omnibox ranking update may result in more helpful Google Search results.
https://www.google.com/chrome/privacy/whitepaper.html#variat...
(Disclosure: I work for Google, speaking only for myself)
I'm not a lawyer, but I would expect if Google were not telling the truth here it would go very poorly for them.
To ask us to "trust your word" while you're actually actively being accused of a lot of misconduct by a lot of very reputable sources is... kinda hard to buy into? We gave Google the benefit of the doubt for far, far too long, and it screwed us. We're done trusting you.
You're referencing anti-trust and privacy investigations, but those don't seem to be about lies?
You perhaps forget that whistleblowers have quit Google and revealed truths Google didn't want people to know. People with the same inside knowledge you have realized they could no longer square where they worked with their personal ethical standards.
We're here, today. "Just trust us, and obviously it'd go badly for us if we're lying" isn't a line that's going to work anymore, because your CEO might be in jail by the end of the year.
I'm reasonably confident all four CEOs made statements that could be viewed as perjury last week. Some of them have already been news stories since the hearing. Statements they made directly contradict factual information in a few cases.
Link?
If you can't prove X-Client-Data isn't able to be used for fingerprinting, we should assume that it is. And just like DoubleClick data, even if it isn't used now, we should assume Google may alter the deal later, as it has done many times before.
[0]Literally the words Australia used a few days ago is "deception by design": https://www.afr.com/technology/deception-by-design-accc-laun...
https://www.chromium.org/Home/chromium-privacy/privacy-sandb...
nope...
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!
Trust Token Github page: https://github.com/WICG/trust-token-api
I'm glad to see it uses Privacy Pass as a basic mechanism.
> 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
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.
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.
prepared to get penalized by recaptcha for not having it enabled.
Link for the lazy / curious: https://www.hcaptcha.com/
(I am completely unaffiliated with them, and I can't really even verify whether or not hCaptcha is any good, although it did seem like it was rather decent to me and no more difficult not easier than the average reCAPTCHA)
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.
I do get recaptcha all the time in Safari on iOS despite being logged into Google there too, not sure what that’s about.
On mobile: * NextDNS (same app vpn setup on iOS) with aggressive blocks enabled * Safari content blocker for anything that gets missed.
Every time I get a recaptcha, it invariably turns into a multi-round affair.
OTOH when I see reCaptcha-wanted websites I'm mostly inclined to just bounce. There has to be a really compelling use-case to propel me to go to all the bother.
https://wiki.mozilla.org/Privacy/Privacy_Task_Force/firefox_...
Privacy comes with a price.
Often site-specific form validation is more than adequate to prevent bot registrations. Until you hit the level of "people are scripting for your site specifically" level, rudimentary data validation will catch almost every bot.
Well honestly, "1-person hobby project" doesn't really have "customer service". Though I work hard to help anyone with honest feature requests and issues, there's still no SLO on any of this.
I have unfortunately hit people scripting for my site directly, which is where I had to rely on Captcha. It's unfortunate but bad actors have honestly ruined so much of the internet...
how is this useful when it comes advertising, and how does it relate to third party cookies? Isn't third party cookies used for cross-site tracking? Apparently advertising networks use it to authenticate users as well?
Trust tokens are a way to do that verification in a way that doesn't also enable cross site tracking for the advertising purposes. They aren't supposed to help advertisers track you
> Process for registering as an issuer: https://docs.google.com/document/d/1cvUdAmcstH6khLL7OrLde4Tn...
which says:
To apply for an Issuer (and its key commitments) to be included within Chrome, the Issuer’s operator must file a new bug on the Chromium Issue Tracker, and provide:
* Issuer Name - Human readable name representing the Issuer.
* The origin that is used for the issuing service (scheme, host, port). The scheme must be HTTPS.
* An email or email alias that is monitored by the Issuer’s operator for issues regarding the Issuer.
* A public HTTPS endpoint that responds to key commitment requests.
* A description of the Issuer, describing its intended purpose.If that provider is likely to be Google (as I'm sure they plan), then there's no trust there to begin with.
(Apologies if I should go and read the fine docs -- and in truth I probably should -- but I lack enough hours in the day for something that is a bit peripheral to my interests, so must rely on my co-HNers to condense/explain these things. Upvoted with gratitude.)
You go through a process to get either one token or a 'batch' of tokens issued, then they are one-time-use redeemed to indicate authorization. Because they use a blind signature method, the server which issued them can't recognize them when they are redeemed. There is also a zero-knowledge proof used to make sure the server isn't trying to get additional bits of state by using different public keys per user.
So they are not meant to track a user, but rather indicate that some process happened - that you previously solved a captcha, that you saw an ad, etc. 64 bits is way too much information IMHO, but the implementations are still very early.
I think maybe you're confusing this some other API? Here are the trust token docs: https://github.com/WICG/trust-token-api#overview
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.
https://vpnoverview.com/news/google-backpedals-on-claim-that...
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?
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.
> 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.
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.
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...
[1]: https://chromium.googlesource.com/chromium/src.git/+/64d617e...
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=379341
Google made the deliberate decision to not disclose this tracking, right? That's the definition of secret.
I won't speak to legality since I'm not a lawyer, and I never claimed it was illegal for that reason.
If this feature was disclosed to users with an opt-out, it'd be significantly less suspicious. Instead you've got a secret hard-coded mechanism for tracking users that is impossible to disable. Maybe the reason people are suspicious is because it's a little hard to trust "we don't use this for tracking! trust us!" from a company that makes their money from advertising and tracking (including shadow profiles).
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.
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.
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, 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.
[0]: https://stackoverflow.com/questions/12183575/what-is-followi...
Why should I chose to pursue a different employer based on someone else's ill-founded concerns?
Elaborating a bit more, there's a motte and Bailey you're pulling here. I'd agree that Google doesn't have broadly "the best interests of us" at heart, but that's true for every corporation. If that's your bar for ethical action, you're asking me to not participate in capitalism as a whole. I look forward to that world too, but unfortunately we aren't there today.
Be the change you wish to see in the world. Waiting for others is the problem.
As a cynical person I agree, but Google is special in this case, because their core function is spying on people and selling their data to advertisers, and they are extremely successful.
It's a token for gauging trust. What else would you call it?
The way "gaslighting" is used today, it's lost all possible meaning.
I would like to send it to someone with very little knowledge of this world and what problem this feature intends to solve.
Firefox: No public signals
Edge: No public signals
Safari: Public support. General support for the idea during TPAC 2019 discussion.
https://mozilla.github.io/standards-positions/ says they're not sure yet: "This API depends on the Privacy Pass protocol, for which we have deferred our position statement."
[1] https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
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.
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.
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.
The status quo is you must raise prices for consumers to be antitrust. Can you think of a more socially positive alternative? The status quo is not to find economically positive outcomes because that is (1) incommensurable with policy enforced by law always and generally (2) likely unknowable.
Merging DoubleClick data with Google accounts was a huge price hike. Starting to store your web and app activity centrally, was a price hike. Mining your Gmail receipts to populate a "purchases" tab in your account? Price hike. Auto-logging your Chrome in when you logged into Gmail, holy price hikes, Batman. You get the idea.
Like obviously the price of doing Google searches and visiting YouTube is zero so I don’t know, even if I accept your premise at face value anything exchange for zero is possible interpreted as a zero or undefined exchange rate.
I don't agree with any of your capricious rules, so no, I don't think I will.
However, when the laws get revised and new precedent is set, many rule changes will blow back on Microsoft just as well as everyone else.
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.
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.
https://www.eff.org/deeplinks/2017/07/amid-unprecedented-con...
https://www.defectivebydesign.org/blog/w3c_sells_out_web_eme...
The burden of proof for not being corrupted lies with the people and organizations that wield tremendous power.
We can't just have blind faith and wait for proof of corruption first. Instead we should assume it, and look for proof that there isn't any and be thankful when that's the case.
Which is not to say I'm fond of advertising tracking like this by any means, I hate it, but if we're going to have it foisted on us by Google et. al. then it should at least be managed by a more competent group than the W3C.
The implementation within Chrome isn't a community thing that anyone can make use of. They are controlling who can use this feature. That is vendor lock in.