Hacker News Reader

Comment by janpot | Hacker News Reader

Not endorsing this, but according to https://www.google.com/chrome/privacy/whitepaper.html#variat...

> We want to build features that users want, so a subset of users may get a sneak peek at new functionality being tested before it’s launched to the world at large. A list of field trials that are currently active on your installation of Chrome will be included in all requests sent to Google. This Chrome-Variations header (X-Client-Data) will not contain any personally identifiable information, and will only describe the state of the installation of Chrome itself, including active variations, as well as server-side experiments that may affect the installation.

> The variations active for a given installation are determined by a seed number which is randomly selected on first run. If usage statistics and crash reports are disabled, this number is chosen between 0 and 7999 (13 bits of entropy). If you would like to reset your variations seed, run Chrome with the command line flag “--reset-variation-state”. Experiments may be further limited by country (determined by your IP address), operating system, Chrome version and other parameters.

View on HN

This is impressive doublespeak.

> This ... header ... will not contain any personally identifiable information

> a seed number which is randomly selected on first run ... chosen between 0 and 7999 (13 bits of entropy)

They are not including any PII... while creating a new identifier for each installation. 13 bits of entropy probably isn't a unique identifier iff you only look at that header in isolation. Combined with at least 24 additional bits[1] of entropy from the IPv4 Source Address field Google receives >=37 bits of entropy, which is almost certainly a unique ID for the browser. Linking that browser ID to a personal account is trivial as soon as someone logs in to any Google service.

> Experiments may be further limited by country (determined by your IP address)

They even admit to inspecting the IP address...

> operating system, Chrome version and other parameters.

...and many additional sources of entropy.

[1] why 24 bits instead of 32? The LSB of the address might be zeroed if the packet is affected by Googles faux-"anonymization" feature ( https://news.ycombinator.com/item?id=15167059 )

Don't forget that just about any registration requires recaptcha these days

>Linking that browser ID to a personal account is trivial as soon as someone logs in to any Google service.

Wat? You mean to tell me they can identify you if you log into their service?

Am I missing something here? Who cares?

I care. I care that I even if I log off, even if I use a vpn, even if I go into incognito mode, they still can associate my requests with the account I initially logged in.

I mean, if you don't want Google to track you, then you probably shouldn't use their browser...

The problem is any website can do that. Incognito-bypassing fingerprinting is difficult to prevent, unless you use something like uMatrix to disallow JavaScript from everything but a few select domains.

This is a collection of random-ish unique-ish attributes. Any collection of such things can be used to track you, like installed fonts, installed extensions, etc. If this were just a set of meaningless encoded random numbers, then it's essentially a kind of cookie, but that's not what it is. This is (claimed to be) a collection of information that's useful and possibly needed by some backends when testing new Chrome features. It tells servers what your Chrome browser supports. The information is probably similar to "optimizeytvids=1,betajsparser=1".

So, the only question is if Google is actually using this to help fingerprint users in addition to the pragmatic use case. It certainly could be used that way, and it's possible they are, but they have so many other ways of doing that with much higher fidelity / entropy if they want to. If this were intended as a sneaky undisclosed fingerprinting technique, I think they would've ensured it was actually 100% unique per installation, with a state space in the trillions, rather than 8000.

Yes, this could be so sneaky that they took this into consideration and made it low-entropy to create plausible deniability while still being able to increase entropy when doing composite fingerprinting, but I think it's pretty unlikely. Also, 99% of the time they could probably just use use Google Analytics and Google login cookies to do this anyway.

Maybe one actually useful non-advertising usage could be reCAPTCHA ? If you read carefully, it says nowhere than there is the limit to 8000. There is this limit of 8000 only if you disable usage statistics / crash reports.

Sorry about that, too late to edit it now. That is an important detail. If there are 32 or more different feature flags, then that's 4 billion unique states, which would be an effective fingerprint.

I still think it's pretty unlikely they're using it in that way or would in the future, and I think Google fuzzing this for those who opt out of telemetry is probably a signal of good faith in this instance. They realize the privacy implications and provide a way to disengage, even if they don't intend to abuse the information.

But of course the potential for abuse always remains. And the potential for (arguably) non-abusive tracking, like the possibility of it being used for bot detection by reCAPTCHA, as you say.

reCAPTCHA is the most abusive type of tracking. Google simply denys you usage of captcha if you do not give them enough personal information. It doesn't matter if you enter the captcha correctly 20 times. It won't let you in.

reCAPTCHA increasingly doesn't even give me a captcha. Instead, they simply deny me from even trying; They send this instead of the challenge:

  <div>
    <noscript>
      Please enable JavaScript to
      get a reCAPTCHA challenge.<br>
    </noscript>
    <div class="if-js-enabled">
      Please upgrade to a
      <a href="[1]">supported browser</a>
      to get a reCAPTCHA challenge.
    </div>
    <br><br>
    <a href="[2]" target="_blank">
    Why is this happening to me?</a>
  </div>

They probably don't like my non-standard user agent string and they definitely don't like that I block a lot of their spyware, but reCAPTCHA used to work properly for many years with the same/similar browser configuration.

[1] https://support.google.com/recaptcha/?hl=en#6223828

[2] https://support.google.com/recaptcha#6262736

This is part of the bot detection, though. It's probably not "not enough personal information", it's "this truly seems like it is unlikely to be a legitimate device/person", due to the huge datasets they're working with. Same with Cloudflare and Tor. Once you operate a security service anywhere near that scale, you start to understand there are inherent challenges and tradeoffs like these,

I believe someone else in the thread stated it's cleared for incognito, don't remember if they meant it's not sent or that it's a new value.

he means they can continue to identify you after you log off

I think the argument is they have other methods like cookies they could also use. The fact you trust them not to use those methods extends to this form of tracking.

If you browse the internet, they could know what websites are visited by the same person, but not who they are exactly.

If you visit a load of websites, then also log into google, they connect the two and they know what websites were visited by you specifically.

Normally you would only expect to be identified and tracked when using Google services when logged in. The significance of this post is that they would be able to identify and track you across all your usage of that browser installation regardless of if you've logged out, or say in an incognito window.

Ah. So I was missing something. Thanks for clarifying. That is alarming.

Yes you are missing something important. Once they've tied the browser ID to your personal account they can track you across all google properties, even the ones that you didn't log into.

I still don't understand. When I log into gmail, it logs me into all Google services. If I am worried about being tracked, surely my first mistake is logging in in the first place? Or visiting in the first place? After all, even if I click "log out," I'm only trusting Google that they unlinked the browser state from the account. If I trust them to do that, I don't see why I shouldn't trust them to ignore this experiment flag from Chrome, or at least not use it for tracking. If I don't trust them to avoid using the experiment state, I don't really see how you can trust them for anything.

Anyway, if you're not building Chrome from source, then you have to trust that they aren't putting anything bad in it. And if you are building chrome from source, you can observe that they only send this experiment ID to certain domains, and they already know who you are on those domains anyway.

>If I am worried about being tracked, surely my first mistake is logging in in the first place?

Good luck completing a google captcha without a Google account or using Chrome.

Unless you're running some extension that emulates FF's container tabs or something, it logs you into all G services. It would matter, though, if this header is still sent in incognito sessions.

> > Experiments may be further limited by country (determined by your IP address)

> They even admit to inspecting the IP address...

I don't think that sentence admits what you say? Chrome could be determining which experiments to run client-side.

Of course, when you visit a Google property, they needs must inspect your IP address to send a response to you, at a minimum. That goes for any site you might choose to visit. The existence of sufficient entropy to personally identify a site visitor is not a state secret. They do not need this chrome experiment seed to identify you, if that's a goal.

Yeah, it's not a "state secret" but it's not common knowledge either. Their privacy policy says that specific header can't be used to identify you, but fails to mention it can be combined with other information to make browser fingerprinting trivial.

If you don't know how all this works, which is true for most human beings, their privacy policy might give you the wrong impression.

> says that specific header can't be used to identify you

That's not what it says. It says the header won't contain PII, which is true. It can be linked to PII, but so can literally every bit of information you send to Google while logged into or otherwise using their services. A disclaimer to this effect would not have any purpose.

If I log in to my Google account once, they can associate that browser id with my account. Even if I log out, clear my cookies (and probably use the incognito mode), Google will be able to identify and follow me all over the Web.

I don't know about your PII thing, but it's personal data under the GDPR.

AIUI GDPR restricts the handling and use of PII, not its existence. So it's PII under GDPR. Is Google misusing it? If so, that's an issue. If not, then it's kinda pointless to observe that it's PII under some possibly distinct legal definition than the one Google is using in its privacy policy.

You can't even login into gmail, at least from firefox in incognito mode.

It works for me, at least with 2FA enabled.

That's the whole point. Using any Google service means they can easily personally identify you, that's what the privacy policy should explain.

That's their policy towards privacy, you don't have any. For some reason I can't fathom, you claim mentioning this in their privacy policy "would not have any purpose". Instead of honesty, their privacy policy is a wonder of public relations where it seems like they care deeply about protecting your privacy.

We disagree about the purpose of privacy policies. I believe that privacy policies should describe how data will be used, not how it could be used. I just don't think a policy describing how data could be used is very useful, because it's going to be the same for all services.

Under this formulation, Google's policy is (presumably, lacking any data to the contrary) honest with respect to this value.

> I believe that privacy policies should describe how data will be used, not how it could be used.

This is key. If you subscribe to the "how it could be used" version, then even say possessing an android phone would be a violation of the privacy policy. Which is absurd.

This is a fair distinction, though it does not include the option of discussing how the data _won’t_ be used.

Per your observation, I would argue that the intent of the privacy policy as quoted above is pretty clear. When the policy says that the identifier doesn't contain PII, I believe that is meant to convey that it will not be used to identify you. But it's true that that use is not explicitly excluded. I'm not a lawyer so I couldn't tell you if being weasely in this way would count as fraud or not. Otoh, I suspect that Google is actually abiding by the spirit of the policy they wrote because honestly they have little to gain and much to lose by violating it.

"I believe that privacy policies should describe how the data will be used, not how it could be used."

Google's policy does not tell the user how her data will be used by Google's customers. The policy states Google will use the data to "provide better services". That is deliberately vague. That is the "purpose", but how exactly is the data used to achieve that purpose. There are no specifics with which a user could object.

Google does not only serve the search engine user, the email user, the YouTube user, etc. Its business is not free services. As such the policy is misleading as to what are the "Services" it may use the data to improve. Google's business is providing online ad services.

The truth is that Google collects data to provide better services to advertisers. The policy reads as if it only collects data to provide better services to users. The "free" services are just bait to draw users in. The data is collected to improve online ad services.

> The truth is that Google collects data to provide better services to advertisers.

I understand that that is what you believe, but I do not think this is factually true about the data collected from this Chrome header. I believe that Chrome team collects it in order to understand the impact of Chrome experiments on performance.

So if you use a VPN service for example, they still know who you are because of this. I would say even if you’re visiting in private mode.

I see your point, but I also see how this will keep you identifiable.

I don't math very much, but I would guess the intersection of these sets of people is nil: people who 1) use VPN to avoid tracking by Google 2) still log in to Google services from one of their networks and not the other 3) use the same Chrome profile on both. But suppose some small number exist who adopt this illogical and contradictory pattern of behavior. If Google is using this token for the purpose of tracking this tiny set of people when the vast majority could be tracked more easily via conventional means, it would imply that they are far more competent than I give them credit for.

So, someone starting up a vpn and opening incognito mode?

> This ... header ... will not contain any personally identifiable information

Except for everything you do on your browser. I'm so glad I haven't used Chrome for almost three years.

Yes, if you have enough bits you can come up with a fingerprint, but that's not what PII means.

It becomes PII the instant you can correlate that fingerprint with any PII.

This.

A bank account number is consider PII. Knowing the bank name & account number will uniquely identify the account holder's name, which is PII.

IP addresses are considered PII under both GDPR and CCPA.

... which is crazy unrealistic, since it's "PII" that can only stay "private" by collective agreement of every node in the network, but no accounting for the reality of network architecture in passing law, I guess.

Maybe a deep expectation of anonymity while accessing a worldwide network of cooperative machines is something people should stop telling the public they should expect?

Under GDPR you can use all the PII you reasonably need to provide expected services, you don't even need separate consent. But, if you have PII, the moment you use it for other purposes, or obtain/retain/share without proper cause, you are breaking the law.

IMHO, that is very reasonable.

Real world example - giving your phone number and information to your car mechanic / doctor / bank teller / plumber is reasonable. Using that information to score girls or ask donation for a puppy shelter would be considered improper.

I totally agree, and I think the GDPR is also reasonable in that it allows you to use the IP address for essential security reasons, such as blocking bad actors based on IP address - it doesn't say "thou shalt not track IP addresses", it says you need consent if you're going to use it for anything that isn't essential for security or in your end user's best interest.

Or they can stay 'private' by not being stored or correlated with other user data. GDPR doesn't apply to the network itself, it applies to whoever is using it.

"Stored" is definitely the purpose of a router. "Correlated" can be necessary for debugging routing issues (or client-server connection issues that are tied to the intermediary fabric near the client doing something weird; hard to determine if an entire subnet is acting up if you aren't allowed to maintain state on errors correlated to IP address).

Where do you get the idea that GDPR doesn't allow you to process PII for the purpose of routing packets?

> They are not including any PII... while creating a new identifier for each installation. 13 bits of entropy probably isn't a unique identifier iff you only look at that header in isolation. Combined with at least 24 additional bits[1] of entropy from the IPv4 Source Address field Google receives >=37 bits of entropy, which is almost certainly a unique ID for the browser. Linking that browser ID to a personal account is trivial as soon as someone logs in to any Google service.

Now this is interesting. If without that 13 bits of entropy, what will Google lost? Is it because of this 13 bits then Google suddenly able to track what they were not? If the IPv4 address, user-agent string, or some other behavior is sufficient to reveal a great deal of stuff, we have a more serious problem than that 13 bits. I agree that 13-bit seed is a concern. But I am wondering if it is a concern per se, or its orchestration with something else. Of course, how/whether Google keeps those data also matters.

One clarification:

- By default it's much more than 13 bits of entropy

- If you disable usage statistics then you are limited to 13 bits of entropy

Actually, the low entropy provider is used for any field trials that get included in the header.

See: https://cs.chromium.org/chromium/src/components/variations/v...

>Now this is interesting. If without that 13 bits of entropy, what will Google lost? Is it because of this 13 bits then Google suddenly able to track what they were not?

At the very least, having those 13 bits of entropy along with a /24 subnet allows you to have device-level granularity, whereas a /24 subnet may be shared by hundreds of households.

They have more than 13 bits of entropy

https://cs.chromium.org/chromium/src/components/metrics/entr...

Look how the function is called, high-entropy source :)

But if you disable telemetry, they'll only have 13?

+ip +browser version +some os info +fonts info +screen resolution (well.. viewport size) + + +

They key in the wording is: "If usage statistics and crash reports are disabled, this number is chosen between 0 and 7999 (13 bits of entropy)."

"If, statistics are disabled."

In chrome://version you can see the active variations. It seems to be pretty big numbers to be significant, and so far haven't observed duplicates.

Since this header is generated server-side, you have only to believe I guess ? Plus why Doubleclick would need it :)

That's basically saying "even if you opt out, we'll still try to track you, just not as much." Very unpleasant, but then again I'm not surprised to see this attitude from Google.

Combine a few pieces of information like this and you get a decisively unique fingerprint.

For example identifying individuals at work behind the same ip address.

How many people will actually run chrome with a cli flag? It would be pretty impressive if every single person reading this thread did, but it probably won't even be that. Most people don't even touch their settings.

13 bits of entropy is far from a uuid (but to get it to that you need to disable some more settings, which again very few people do), but it's still plenty good enough to disambiguate individuals over time.

And Google is certainly in a position to disambiguate that uuid to an individual as soon as they login to gmail or any other Google property!

Is there a reason for only sending this header to Google web properties and not all domains?

It is an abuse of Chrome's position in the marketplace. Google is using their powerful position to give themselves tracking capabilities that other online players can't access. It is a major competitive advantage for Google.

can't alternate browser makers who base on chromium simply disable that portion? like, I expect identifying users was a key business concern in moving Edge to Chromium. Is there something (other than work) preventing them from making it so it'll report back to microsoft-owned domains instead?

I'm using Vivaldi on MacOS and it doesn't send this header. I'm sure others like Brave don't send it either.

Err yeah, because it adds loads of data that can be used to track you.

Is it because Google's webapps will have their own a/b tests which use experimental features only available in Chrome perhaps?

I mean personally I think they should do client-side feature detection and be back to being standards compliant and not creepy. The only reason why I'd consider such a flag is because they optimize the payload server-side to return a certain a/b test, but even with that they could do the default version first, do feature detection, and then set a session cookie for that domain only that loads the a/b test.

My other Thought was that they test a feature that is implemented across Google's properties, e.g. something having to do with their account management.

Isn't this what cookies are for?

Cross-site cookies are soon getting blocked by Chrome starting Chrome 80 if I'm right (whereas this header isn't)

So they build a personal back door to a feature that they've chosen to remove for everyone else? Because of it's potential for abuse, yet the very same company is somehow abusing it in a way more sinister way. Antitrust can't come soon enough.

Chrome will only block cross-site cookies that don't use HTTPS and the SameSite=Lax flag. It's easy for trackers to user HTTPS and SameSite=Lax. This Chrome change is mostly intended to protect against Cross Site Request Forgery (CSRF) attacks, not to block trackers.

I can think of a hundreds reasons why they do this. It doesn't make it right in any of those.

Couldn't the Chrome installations receive a request from Google that says "Do you want to try out a new thing?", and couldn't the Chrome installations say yes with a certain probability? The only difference I can see is that the subset of users that are guinea pigs couldn't be the same in each test (if Google wanted that the subset is always the same).

So they're tracking people and using them as guinea pigs, the lack of respect for users is astounding.

How does one apply the “--reset-variation-state” flag on a chromebook?

So it’s just a poor excuse to send an evercookie.

Reply on news.ycombinator.com