4 ms·

[I work at Google, not on chrome] The current text of the whitepaper is "The combined state of these variations is non-identifying, since it is based on a 13-

[I work at Google, not on chrome] The current text of the whitepaper is "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"[0]. The X-Client-Data header is still described as non-identifying. You're reaching for controversy where there is none. I've had this conversation with GP before[1], and it's always unenjoyable, because it's like talking to a conspiracy theorist. There's no rational basis for Google doing what you and they suggest that Google is doing. And you're willing to take events that aren't actually evidence of any kind of malaction (like rewording a document to mean essentially the same thing) and try and draw nefarious conclusions out of those things. Like, why? If you start from the assumption that Google is acting unethically and is entirely untrustworthy, there are tons of other approaches they can take to do fingerprinting that wouldn't be detectable at all. If you're logged in, the entire conversation is moot. If they wanted to track you, they have your google account. So this only matters for logged out users, and even then, the value is marginal even if you assume Google isn't using any other form of nefarious tracking. And again that all assumes Google is openly lying. If you don't include that in your threat model, well, then, Google probably isn't lying. [0]: https://www.google.com/chrome/privacy/whitepaper.html#mediadrm https://www.google.com/chrome/privacy/whitepaper.html#mediad... [1]: https://news.ycombinator.com/item?id=24040675 https://news.ycombinator.com/item?id=24040675

SheinhardtWigCo 6y ago
> The X-Client-Data header is still described as non-identifying. That's a false description. 13 bits of entropy is more than most existing fingerprinting vectors. This header allows clients behind NAT to be identified with significantly greater precision. > There's no rational basis for Google doing what people suggest it's doing. There is. Their business lives and dies on their ability to track web users, and tracking methods are gradually being eliminated from web standards, therefore Google has a rational basis for adding new tracking methods that it can leverage - especially ones that only it can leverage. > If you start from the assumption that Google is acting unethically and is entirely untrustworthy I think the base assumption is less dramatic: that Google is simply acting in its own best interests by prioritizing growth over user privacy. > If you're logged in, the entire conversation is moot. If they wanted to track you, they have your google account. So this only matters for logged out users, and even then, the value is marginal even if you assume Google isn't using any other form of nefarious tracking. This is (obviously) about the hundreds of millions of Chrome users who are not logged in, and as I said above, 13 bits of entropy isn't marginal. > And again that all assumes Google is openly lying. If you don't include that in your threat model, well, then, Google probably isn't lying. Not necessarily. All it takes is a policy change. It looks like this: 1. Privacy regression is introduced and a restrictive policy is established, e.g. "we won't use that to track people". 2. 6-12 months go by; maybe a new VP gets hired, or a bizdev team discovers that this data could be leveraged for a significant bump in revenue. 3. The policy is relaxed to allow existing & future data to be used for fingerprinting. Nobody "lied" per se, but the end result is the same.
- joshuamorton 6y ago
  > That's a false description. 13 bits of entropy is more than most existing fingerprinting vectors. This header allows clients behind NAT to be identified with significantly greater precision. That doesn't make the X-Client-Data header identifying. Or, if it does, then your definition of "identifying information" is exactly equivalent to your definition of "information", because it is true that any particular axis or piece of data can be used to identify clients with greater precision. The rest is just how identifying the information is. Country is identifying, as is first digit of IP address, but both are less identifying than MAC address or first name. You're welcome to subscribe to such a definition, but it's not the normal one (which is usually that said piece of data can be tied to a specific individual, although you may not be able to correlate that particular individual with a name or similar). Under this definition, I'd probably agree that the combination of IP address and X-client-data header is identifying, but that's also not a thing anyone is going to be using, because it's not particularly useful. > There is. Their business lives and dies on their ability to track web users Sort of. The value of tracking individual users at the granularity you suggest is, as far as I know, dubiously valuable, and importantly, there's no reason to believe it's done. Like there's no evidence to support this beyond the conjecture. > This is (obviously) about the hundreds of millions of Chrome users who are not logged in, and as I said above, 13 bits of entropy isn't marginal. But if you're in this situation, and again, Google is being unethical, there are a host of other tracking tools that provide 13 or more bits of entropy that they can use. > Nobody "lied" per se, but the end result is the same. I'd classify that as lying (for actually more than one reason). But I'll just leave you with the same point I made to 0xy the last time this was brought up: this X-client-Data header is nearly 9 years old. When it was introduced it was considered nonidentifying and was used for chrome experiments. It is still considered nonidentifying and used for chrome experiments. And this is why the whole idea doesn't make sense: if the header was introduced now, I could see this train of thought making sense. But it wasn't recently introduced. They've had more than 8 years to use it while there have been all kinds of other ways to get additional bits. So now your chain of reasoning is more like 1. Telemetry is introduced and a restrictive policy is established, e.g. "we won't use this to track people. 2. 6-12 years pass, multiple executives pass through the area. The CEO of the company changes twice. The entire org chart shifts and metamorphizes more than once. The policies are maintained. 3 [concurrently with 2]. A number of nations pass new privacy laws. Previously, using this particular set of data to track individuals would have been unethical, but legal. It is now both unethical and illegal in many places. 4. Google invests significantly in a different, somewhat privacy preserving alternative to individually identifying tracking technology which is openly criticized because it is mediocre in terms of privacy preservingness. 5. At some point between 2 and 4, they started actively breaking the law by using this can't-be-used-to-identify telemetry to identify unique users. And instead of completely hiding this fact, using it as a competitive advantage, and openly being a leader in privacy (for example by being an early proponent and supporter of things like 3rd party cookie restrictions), they don't do that, and instead suffer reputational harm due to the existing tracking, the telemetry illegally used for tracking, and the proposed new scheme for privacy preserving tracking that is inferior to the illegal telemetry-based approach. It's a line of reasoning that requires that Google be simultaneously incredibly unethical and incredibly inept. It doesn't make sense.
underslung 6y ago
It's about consistency and intent -- these observations do not extend to conspiracy tier thinking. What is the primary purpose of the X-Client-Data header if not for some unplanned future-proofing? Masquerading about it does not add to credibility
- joshuamorton 6y ago
  It's for tracking which chrome experiments are enabled, allowing chrome to check the impact of new chrome features by enabling them for only some populations and comparing the results. As it says in the white paper: "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."
  - WesolyKubeczek 6y ago
    That's describing it short-term at best, as some have pointed to you already. Also, I don't see the important word "only" in the passage you're quoting, so given the usual MO of profit-driven corporations I'm just going to assume they omit other purposes of which there's at least a ton.
0xy 6y ago
The fact it is undisclosed to users, unjustified (they could get the same result by sending the header to GTM) and impossible to disable make it nefarious. Google have a header being sent to advertising domains that can be used for tracking purposes, Google didn't ever disclose this fact, and Google made it impossible to disable. Already that's nefarious. "Just trust us, we won't abuse this!" is not good enough, considering the way it was implemented is already cloak-and-dagger suspicious. If this were innocent, it'd be disclosed and you could opt-out. Google made a deliberate choice to not disclose this tracking to users, and made another deliberate choice to have it to be impossible to disable. Coupled with the other highly questionable choices Google has made with Chrome, such as the giant amount of telemetry available through JavaScript that ad networks are actively abusing and it's hard not to think of Google as nefarious. For ad networks, including Google's own ad department, Chrome is like a candy store. Firefox and Safari have tracking prevention and cookie mitigations. Chrome on the other hand has undisclosed, impossible to disable ad network tracking headers being sent to DoubleClick explicitly. Chrome's cookie security is similarly a joke, designed for the benefit of ad networks. Chrome puts ease of tracking above security, time and time again. Not only is this choice made repeatedly, but billions of dollars are made in the process.
- joshuamorton 6y ago
  > they could get the same result by sending the header to GTM Do you mean Tag manager, or some other GTM? I also, and this'll be seriously counterintuitive, doubt that they could be quite as conscientious of user data if they were handled via GTM. To sketch out the concern here: Chrome telemetry that is not used to identify people and personal ad preferences/data tied to an individual user probably shouldn't be sent via the same channel or logged in the same place. They're used for different purposes, by different people, and likely have different infrastructural concerns related to storage and querying. In fact, it would be rather suspicious if chrome telemetry data was sent via Google's ads logging infrastructure. That would imply an odd level of co-design and coupling. > sent to DoubleClick explicitly And everything else owned by Google. It's not sent to Doubleclick specifically, which you never seem to acknowledge. It's sent to stuff that Google owns (and presumably, really just a large selection of things sitting behind the GFE[0]). > For ad networks, including Google's own ad department, Chrome is like a candy store. Firefox and Safari have tracking prevention and cookie mitigations. Chrome on the other hand has undisclosed, impossible to disable ad network tracking headers being sent to DoubleClick explicitly. Chrome's cookie security is similarly a joke, designed for the benefit of ad networks. Firefox does the same thing as chrome (via Firefox Telemetry). There's privacy tradeoffs between the two approaches, Firefox's allows the telemetry holder to reconstruct browsing data for a particular user (assuming the browser sends the data out of band to some central server). Google's approach doesn't allow that. There's also some technical advantages to Google's approach in terms of telemetry (both for Chrome and for Google sites), but those don't affect the privacy tradeoffs of how the telemetry is ultimately reported. > Google didn't ever disclose this fact You mean except in the Chrome whitepaper. > "Just trust us, we won't abuse this!" is not good enough, considering the way it was implemented is already cloak-and-dagger suspicious. But, like, it's not. The lengths you have to go to to make it appear suspicious (including lying repeatedly about how Google didn't disclose the feature) demonstrate how it's not in fact that suspicious. Yes, when you misrepresent the facts, it begins to sound suspicious. But that's because you're misrepresenting what was actually done. [0]: https://sre.google/sre-book/production-environment/ https://sre.google/sre-book/production-environment/

SheinhardtWigCo 6y ago

> The X-Client-Data header is still described as non-identifying. That's a false description. 13 bits of entropy is more than most existing fingerprinting vectors. This header allows clients behind NAT to be identified with significantly greater precision. > There's no rational basis for Google doing what people suggest it's doing. There is. Their business lives and dies on their ability to track web users, and tracking methods are gradually being eliminated from web standards, therefore Google has a rational basis for adding new tracking methods that it can leverage - especially ones that only it can leverage. > If you start from the assumption that Google is acting unethically and is entirely untrustworthy I think the base assumption is less dramatic: that Google is simply acting in its own best interests by prioritizing growth over user privacy. > If you're logged in, the entire conversation is moot. If they wanted to track you, they have your google account. So this only matters for logged out users, and even then, the value is marginal even if you assume Google isn't using any other form of nefarious tracking. This is (obviously) about the hundreds of millions of Chrome users who are not logged in, and as I said above, 13 bits of entropy isn't marginal. > And again that all assumes Google is openly lying. If you don't include that in your threat model, well, then, Google probably isn't lying. Not necessarily. All it takes is a policy change. It looks like this: 1. Privacy regression is introduced and a restrictive policy is established, e.g. "we won't use that to track people". 2. 6-12 months go by; maybe a new VP gets hired, or a bizdev team discovers that this data could be leveraged for a significant bump in revenue. 3. The policy is relaxed to allow existing & future data to be used for fingerprinting. Nobody "lied" per se, but the end result is the same.

joshuamorton 6y ago
> That's a false description. 13 bits of entropy is more than most existing fingerprinting vectors. This header allows clients behind NAT to be identified with significantly greater precision. That doesn't make the X-Client-Data header identifying. Or, if it does, then your definition of "identifying information" is exactly equivalent to your definition of "information", because it is true that any particular axis or piece of data can be used to identify clients with greater precision. The rest is just how identifying the information is. Country is identifying, as is first digit of IP address, but both are less identifying than MAC address or first name. You're welcome to subscribe to such a definition, but it's not the normal one (which is usually that said piece of data can be tied to a specific individual, although you may not be able to correlate that particular individual with a name or similar). Under this definition, I'd probably agree that the combination of IP address and X-client-data header is identifying, but that's also not a thing anyone is going to be using, because it's not particularly useful. > There is. Their business lives and dies on their ability to track web users Sort of. The value of tracking individual users at the granularity you suggest is, as far as I know, dubiously valuable, and importantly, there's no reason to believe it's done. Like there's no evidence to support this beyond the conjecture. > This is (obviously) about the hundreds of millions of Chrome users who are not logged in, and as I said above, 13 bits of entropy isn't marginal. But if you're in this situation, and again, Google is being unethical, there are a host of other tracking tools that provide 13 or more bits of entropy that they can use. > Nobody "lied" per se, but the end result is the same. I'd classify that as lying (for actually more than one reason). But I'll just leave you with the same point I made to 0xy the last time this was brought up: this X-client-Data header is nearly 9 years old. When it was introduced it was considered nonidentifying and was used for chrome experiments. It is still considered nonidentifying and used for chrome experiments. And this is why the whole idea doesn't make sense: if the header was introduced now, I could see this train of thought making sense. But it wasn't recently introduced. They've had more than 8 years to use it while there have been all kinds of other ways to get additional bits. So now your chain of reasoning is more like 1. Telemetry is introduced and a restrictive policy is established, e.g. "we won't use this to track people. 2. 6-12 years pass, multiple executives pass through the area. The CEO of the company changes twice. The entire org chart shifts and metamorphizes more than once. The policies are maintained. 3 [concurrently with 2]. A number of nations pass new privacy laws. Previously, using this particular set of data to track individuals would have been unethical, but legal. It is now both unethical and illegal in many places. 4. Google invests significantly in a different, somewhat privacy preserving alternative to individually identifying tracking technology which is openly criticized because it is mediocre in terms of privacy preservingness. 5. At some point between 2 and 4, they started actively breaking the law by using this can't-be-used-to-identify telemetry to identify unique users. And instead of completely hiding this fact, using it as a competitive advantage, and openly being a leader in privacy (for example by being an early proponent and supporter of things like 3rd party cookie restrictions), they don't do that, and instead suffer reputational harm due to the existing tracking, the telemetry illegally used for tracking, and the proposed new scheme for privacy preserving tracking that is inferior to the illegal telemetry-based approach. It's a line of reasoning that requires that Google be simultaneously incredibly unethical and incredibly inept. It doesn't make sense.

underslung 6y ago

It's about consistency and intent -- these observations do not extend to conspiracy tier thinking. What is the primary purpose of the X-Client-Data header if not for some unplanned future-proofing? Masquerading about it does not add to credibility

joshuamorton 6y ago
It's for tracking which chrome experiments are enabled, allowing chrome to check the impact of new chrome features by enabling them for only some populations and comparing the results. As it says in the white paper: "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."
- WesolyKubeczek 6y ago
  That's describing it short-term at best, as some have pointed to you already. Also, I don't see the important word "only" in the passage you're quoting, so given the usual MO of profit-driven corporations I'm just going to assume they omit other purposes of which there's at least a ton.

0xy 6y ago

The fact it is undisclosed to users, unjustified (they could get the same result by sending the header to GTM) and impossible to disable make it nefarious. Google have a header being sent to advertising domains that can be used for tracking purposes, Google didn't ever disclose this fact, and Google made it impossible to disable. Already that's nefarious. "Just trust us, we won't abuse this!" is not good enough, considering the way it was implemented is already cloak-and-dagger suspicious. If this were innocent, it'd be disclosed and you could opt-out. Google made a deliberate choice to not disclose this tracking to users, and made another deliberate choice to have it to be impossible to disable. Coupled with the other highly questionable choices Google has made with Chrome, such as the giant amount of telemetry available through JavaScript that ad networks are actively abusing and it's hard not to think of Google as nefarious. For ad networks, including Google's own ad department, Chrome is like a candy store. Firefox and Safari have tracking prevention and cookie mitigations. Chrome on the other hand has undisclosed, impossible to disable ad network tracking headers being sent to DoubleClick explicitly. Chrome's cookie security is similarly a joke, designed for the benefit of ad networks. Chrome puts ease of tracking above security, time and time again. Not only is this choice made repeatedly, but billions of dollars are made in the process.

joshuamorton 6y ago
> they could get the same result by sending the header to GTM Do you mean Tag manager, or some other GTM? I also, and this'll be seriously counterintuitive, doubt that they could be quite as conscientious of user data if they were handled via GTM. To sketch out the concern here: Chrome telemetry that is not used to identify people and personal ad preferences/data tied to an individual user probably shouldn't be sent via the same channel or logged in the same place. They're used for different purposes, by different people, and likely have different infrastructural concerns related to storage and querying. In fact, it would be rather suspicious if chrome telemetry data was sent via Google's ads logging infrastructure. That would imply an odd level of co-design and coupling. > sent to DoubleClick explicitly And everything else owned by Google. It's not sent to Doubleclick specifically, which you never seem to acknowledge. It's sent to stuff that Google owns (and presumably, really just a large selection of things sitting behind the GFE[0]). > For ad networks, including Google's own ad department, Chrome is like a candy store. Firefox and Safari have tracking prevention and cookie mitigations. Chrome on the other hand has undisclosed, impossible to disable ad network tracking headers being sent to DoubleClick explicitly. Chrome's cookie security is similarly a joke, designed for the benefit of ad networks. Firefox does the same thing as chrome (via Firefox Telemetry). There's privacy tradeoffs between the two approaches, Firefox's allows the telemetry holder to reconstruct browsing data for a particular user (assuming the browser sends the data out of band to some central server). Google's approach doesn't allow that. There's also some technical advantages to Google's approach in terms of telemetry (both for Chrome and for Google sites), but those don't affect the privacy tradeoffs of how the telemetry is ultimately reported. > Google didn't ever disclose this fact You mean except in the Chrome whitepaper. > "Just trust us, we won't abuse this!" is not good enough, considering the way it was implemented is already cloak-and-dagger suspicious. But, like, it's not. The lengths you have to go to to make it appear suspicious (including lying repeatedly about how Google didn't disclose the feature) demonstrate how it's not in fact that suspicious. Yes, when you misrepresent the facts, it begins to sound suspicious. But that's because you're misrepresenting what was actually done. [0]: https://sre.google/sre-book/production-environment/ https://sre.google/sre-book/production-environment/