"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.
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.
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".
Choosing to be militantly ignorant in service of dogma over math has consequences all the time, not just when you're the Feds trying to get 'child porn' laws passed to make Apple break encryption.
Yeah, I strongly suspect this will be the result on a much scale than the edge cases we see today. We need to start punishing companies using reCaptcha. Stop doing business with them.
hCaptcha is an alternative I have seen popping up as of late.
(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.
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?
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.
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.
uBlock with all third party requests blocked. That means I don't even see recaptcha, but when I explicitly enable it for a site, it takes 3-4 rounds to pass. Logged on to gmail and youtube.
My strategy for this has been to switch to a different browser (Brave, simply because it's Chrome-ish and runs on Linux). Since the reCaptcha network has seen this browser before I'm seldom abused with more than one or two rounds of image guessing.
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.
I guess I'm lucky I'm in Europe, where the majority of sites do not use recaptcha (I think it's illegal under GDPR). A minority of sites I use try to load it, but don't care if it fails, and only a few irritating sites I would use actually require it.
How else do you propose sites combat spam and bots? As someone who has had many of my free services completely ruined by spammers, Captcha was the only way I could save them.
I've found Captcha is an overkill strategy that also demonstrates poor customer service as you are both annoying your user and selling their data to Google.
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...
>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.
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?
Cross-site tracking is used to build a profile on you to determine that you're a "real" user and your browsing habits don't match the browsing habits of a bot. With this profile built, recaptcha and others can avoid showing you an actual caaptcha. Without it, they need to show you a captcha every time they need to verify you're human.
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
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.
But it also means that if someone challenges the token, the token creator responsible for answering said challenge gets information about services used by the user. So it isn't really a privacy preserving solution.
It sounds like the provider knows everything, though... knows who it provided the tokens to, knows who consumed them. So where's the privacy shielding between me and the token provider?
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 can tell from the name: it represents that you trust google with your identity, trust they will immediately betray by passing on to third parties. But the cool thing is your cookie restrictions won’t affect it!
I believe that the idea is that you have a bunch of tokens that can be verified that were signed by a provider but cannot be associated to the owner of the tokens.
It is a one-time-use token with a limited amount of data (somewhere between 0 and 64 bits from the implementations I've heard about).
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.
> 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.
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.
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.
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?
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.
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.
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.
> 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).
You're correct, I think that's a fair criticism. But "hey your should add an opt-out" is a far cry from "you're secretly and illegally using this to track people in a way you've explicitly denied", which is where the conversation started.
I mean, it is secret. Hardly anyone on HN knows about this let alone the average Chrome user.
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.
>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.
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.
You seem like a nice fellow. And smart! How about somehow aligning your life's work to not further the goals of enormous corporations that do not seem to have the best interests of us at heart.
From my (insider, biased, more informed, however you want to describe it) point of view, the fears you have are unfounded.
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.
There's, broadly speaking, a difference between telling me to find a different employer based on an unfounded concern (what you did) and asking me to work to enact a more socialist future. It's not even clear that the two are aligned in all cases.
I'm not sure who you are reading, but I never suggested that you find another employer. I suggested you figure out a way to use your limited time here on Mother Earth to not further the giant machine that is seemingly destroying everything of true value on this planet. Big order, yes, but you are young and it's not too late to make a change for the better (for us all). It's a high bar, but I have faith in you.
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.
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.
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.
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.
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.
Google raised its prices multiple times, you just have to stop evaluating prices in fiat currency. Google provides services in exchange for your personal data. So each time they take more data, they raised the price.
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.
You right away jump into something unknowable like the exchange rate of “data” and “fiat currency,” in exactly the kind of economic positivist framework (really crypto anarchist jargon) that is incommensurable with policy.
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 think cryptocurrency is stupid but I thought "fiat" was still a good term to use here. Data absolutely has value, and both Congress and these companies know that and consider it uncontroversially true.
I wonder if you got downvoted mainly for not thinking Microsoft deserves scrutiny. Honestly every giant corporation should be under intense anti-trust scrutiny at all ties. We should have a "default anti-trust" state that kicks in when corporations reach a sufficient size perhaps. (such as being large enough to influence the government)
I think Microsoft is evading scrutiny right now because while they do everything the others do, they are the less big player in every market. And often easier to get around. Nobody's worried about Edge's dominance with Chrome around, who even cares about the 30% cut the Windows Store can take?
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.
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.
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.
If you look at something like an AmazonBasics wall mount monitor arm, and compare it to an Ergotron, you'll notice every single part is the exact same shape. AmazonBasics products often seem like someone ran the well-known product through a 3D scanner and then started printing replicas with the Amazon logo on them.
It is proposed via the web infrastructure community group in the W3c, and I've seen interest from the big four browsers. I don't believe it is anything like AMP.
I would prefer to err on the side of caution when looking at the actions of key strategic pieces of large corporations.
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.
Normal folks: Keep the above post in mind next time you see an post thats overly cynical. This is the logic that the top minds of HN use to come to their viewpoints.
Between the whole HTML5 / XHTML2 thing (which they lost to WHATWG) and the fact that they're a pack of sellouts (the Encrypted Media Extensions debacle), I would not trust a single thing coming out of the W3C. If Trust Tokens are of any use then it should be handed over to WHATWG (which is where I understand it should be anyway given it's an API thing).
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.
In what way are the browser vendors that would participate in this in the W3C different than the browser vendors that would participate in this at WHATWG?
I don't see how that will be better. WHATWG are basically Google and Apple as it stands. Used to be them plus Mozilla and Microsoft but Firefox is at ~5% market share while MS have forked Chromium. So it won't make any difference whether it is WHATWG or W3C except with the latter the companies can at least claim they're promoting an established standards body, so it's better optics.
> 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...
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.
> 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
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.
I don’t even think this is for Google’s benefit. They don’t need these tokens, since the vast majority of their ad revenue is first party. But do you know what happens the moment Chrome disables third party cookie support? People will start complaining that it’s an anti competitive move against businesses with a stronger need third party cookies.
The x-clint-data header is for experiments, not personalization:
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.
However Google claims it is used, it's a fingerprinting strategy that only a company with Google's level of monopoly in controlling both the biggest browser and the biggest several websites can employ.
But Google has been not telling the truth on all sorts of things, and Google is under investigation by the federal government, 49 US states, the European Union, and several other entities for misconduct and illegal activity with regards to both monopolization and privacy violations. The idea that it'd go very badly if Google were to lie may be true: And Google is currently going through exactly that.
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.
What I'm claiming is not specific to Google. In general, large companies very rarely take a strategy of publicly saying "we don't do X" and then trying to secretly do X. It doesn't work out well for them, because they aren't the kind of entity that can pull off that kind of deception. Documents get subpoenaed, auditors look at things, whistleblowers release things, things get leaked.
You're referencing anti-trust and privacy investigations, but those don't seem to be about lies?
But that's exactly what's happening to your employer right now. Millions of emails are being reviewed, misconduct has been found, and yes, lies to the public have been told.
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.
This is getting into sea lioning territory here. And it misses the point: This isn't about lawyering out of one specific claim. It's that when you are being investigated for misconduct and deception[0], your word something is true is no longer a viable discussion point.
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.
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.
> 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!
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.
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.)
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.
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.
One could also say that Google has proportionally more to loose from the advent of privacy consciousness in people and companies - namely the latest moves by Apple.
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.
130 comments
[ 5.4 ms ] story [ 204 ms ] threadCan 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:
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
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.
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
[3]: https://news.ycombinator.com/item?id=22244282
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.
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...
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.
> 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
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
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.
I would like to send it to someone with very little knowledge of this world and what problem this feature intends to solve.
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
https://archive.md/U4axx