Ads are a business, and they are Google's business. They are how they make money. And like all businesses, they are competitive. Tracking is a way to make more money off online advertising. By removing tracking from their competitors while keeping it for themselves, Google stand to make a lot of money off this change.
Their motivations are not honest, but they're pushing them as if this is the high road. It isn't. It's the dirty low road of dominating the online ad business, made possible by their dominance in the browser market. And it's always been the end-goal of Chrome browser.
First, they do some dirty thing to gain a competitive edge when the industry is still new and unregulated. Later they develop an alternative way to achieve the same competitive edge, and then criticize other players for doing an old way, saying they should be "mature and responsible".
India and China are suffering from their own pollution and have incentives to "go green" all by themselves, not because the West demands it.
Green technology is often high tech and tech that is accepted in Western markets and is helping to lift people out of poverty through market mechanism, not finger pointing.
Finally the first world got rich several generations ago. We are not related in any way, shape or form to any real or perceived sins of our grandfathers. Any such idea is old testament biblical theology.
It's not really about pulling up the ladder, but a recognizing that growth doesn't have to mean completely destroying the planet. It's more about where the standards are set and what is socially acceptable or understood.
It's not recognizing anything, because it hasn't been demonstrated that growth is still compatible with not completely destroying the planet. It's deciding to not destroy the planet, and if that means pulling up the latter then golly gee sucks to be anyone who isn't up yet. We sure hope there are other ways up, but that's not much consolation.
We both are probably distant cousins due to our relation through Ghengis Khan, but that doesn't mean I should be bitter that I can't make my fortune by pillaging half the world like my distant ancestor did to great effect. It might be easy to make a fortune pillaging, but that doesn't mean I deserve to pillage because someone else did (or does), and I think I am in the right in detesting the scattered bands of warlords left in this world who do make their living by pillaging.
So, this is a round about way of agreeing with the hidden dark patterns that Google are bringing to the web. It must stop.
Doing unethical things because "We had to so the shareholders would make money" is such a cop-out. I see it just the opposite way. You have a duty to do things ethically so that in the long run customers continue to want to use your product. So that governments don't start going after you for the unethical things you do. So that other businesses will trust you and continue to work with you.
Here's an example: Huawei. They've reached out to me saying they'll pay me more than my employer and my commute will be shorter. No effing way. I'm sure I could make them a lot of money, but they're history of unethical behaviour is an instant deal-breaker for me. Others will, sure, but in the market of labor they're going to have a reduced supply because I'm surely not alone in this attitude.
It's unfortunate. Profit of their shares is the only thing a lot of people look at (and willfully ignore anything else unless it slaps them in the face/becomes a major mainstream media event).
Pretty sure that was their main reason for helping push https-everywhere. A good idea generally, but hurt every other entity trying to do tracking more than it hurt Google.
That's sort of a fragile assumption though. I mean, yes, there's enough specificity in this number that it could be used (in combination with other fingerprinting techniques) to disambiguate a user. And yes, only Google would be capable of doing this. So it's abusable, in the same way that lots of software like this is abusable by the disributor. And that's worth pointing out and complaing about, sure.
But it's not tracking. It's not. It's a cookie that identifies the gross configuration of the browser. And Google claims that it's not being used for tracking.
So all the folks with the hyperbole about user tracking for advertising purposes need to come out with their evidence that Google is lying about this. Occam says that, no, it's probably just a misdesigned feature.
> Occam says that, no, it's probably just a misdesigned feature.
Allow me to introduce to you "mabbo's razor": If someone can make money by doing X and it's impossible for anyone to tell whether or not they are doing X, then they are probably doing X or else will as soon as you believe they won't.
EDIT I just wanted to point out that a load of people have poured their lives into making Google Chrome the amazing bit of software that it is and suggesting that the end-goal has been entirely about supplying ads does a great disservice to their personal contributions.
But by this point, Google has dropped billions of dollars on salaries for those developers to build Chrome (call it >500 devs, >$200k salaries, >10 years). Google is not a charity. They didn't build Chrome with the intent to lose money on it. Everything else Google made that wasn't profitable is gone now, and yet here Chrome stands. Because it is an indirect profit center.
And you've pointed out the real issue: Chrome was about freeing the world of a truly terrible web browser. 'Was'. But it did that! So what is it about now? Why would Google continue to pour money into it if they didn't expect to extract more money out of it in the future?
You can make the world better and make money while doing it. Ideally, that's what we all are doing.
Chrome is about establishing more control over the web to further the business objectives of Google and Alphabet.
The problem with this belief of Google as some kind of 'benevolent actor' is a function of the new kind of branding they helped introduce, something that an entire generation of particularly young people are being duped by.
'Brand' used to be the image that companies presented - it was a decision, a marketing tactic, usually invented by agencies. Google was one of the first to change that, to effectively 'internalize' the brand so that they (staff, even leaders) really kind of believed their own kool-aid. There's an incredible aura of 'authenticity' to this; when leaders really believe their own schtick, it rings more powerfully. (This is an issue for another thread.)
But Google has proven that in the long run, they're just a regular company. I don't think they are bad actors, and in the big picture, they're better than most. But, they're just a self-interested entity: they will do whatever is in their power and which is also legal, to leverage their incumbency and stymie competition.
You put 'benevolent actor' in quotes as if the comment you are replying to contained that. It didn't.
I see a lot of that here, people misunderstanding basic speech/writing conventions. Maybe giving the op the benefit of doubt, assuming s/he knows what s/he is doing, can help avoid some of those.
Except it does not affect Google, because Google has this install ID to use both for tracking and preventing ad-fraud.
Which means Google competitors are terribly disadvantaged, as they cannot use that.
Which not only reduces market diversity (contrary to TAG philosophy) but represents a significant conflict of interest for an organization proposing a major web standard change.
These issues are very relevant to the original proposal, especially in light of the fact that Noone outside of Google is terribly interested in this change. Any time a dominant player is the strongest (or only) advocate for a change that would coincidentally and disproportionately benefit its corporate interests, the proposal should be viewed very skeptically.
So when Apple releases a privacy feature, that doesn't affect them as a business, we praise the feature or we say "except it doesn't affect Apple" and somehow try to argue how the feature is less valuable because of that?
If there's a privacy gap, (and Apple is actively exploiting that gap)
When Apple patches it, (while leaving it open for themselves)
They'll get called out.
Anything that is associated with personal data also becomes personal information, therefore Google is transmitting personal data without user consent, which is illegal.
Asking for consent is not required under GDPR when the data collection is needed for a service to function. This is not the case here, Google services function without receiving that header, the data is used by Google to gain a technical advantage over other web services.
No it doesn't. GDPR only treats IP address as personal data if it is associated with actual identifying information (like name or address). Collecting IP address alone, and not associating it with anything else, is completely fine (otherwise nginx and apache's default configs would violate GDPR), and through them basically every website would violate GDPR.
Edit: and furthermore, even if it did (I see conflicting reports), if you collect IP Address and another pseudonymous ID and don't join them, the ID isn't personal data.
IOW, the theoretical capability to make changes to a system to use info in a non-GDPR compliant way doesn't make the information or system noncompliant. You actually have to do the noncompliant things.
https://ec.europa.eu/info/law/law-topic/data-protection/refo...
> Collecting IP address alone, and not associating it with anything else, is completely fine (otherwise nginx and apache's default configs would violate GDPR), and through them basically every website would violate GDPR.
See my comment about consent not being required when the data is needed to provide a service. Logging is reasonably required to provide a service.
> and furthermore, even if it did (I see conflicting reports), if you collect IP Address and another pseudonymous ID and don't join them, the ID isn't personal data.
The transmission of data is already covered by GDPR, you don't have to store the data to be bound by the law.
But even if that's the case, if you don't tie the pseudonymous ID to the IP, it isn't personal data. As far as I can tell, the transfer rules you reference are about transferring data out of the EU, and can be summarized as "you can't transfer data to a non-EU country and then process it in a way that violates the GDPR". Article 46 notes that transferring data is fine as long as appropriate safeguards are in place[1], and article 47[2] defines what constitutes those safeguards (in general, contractually/legally binding agreements with appropriate enforcement policies).
This goes back to what I said before: The theoretical capability to do noncompliant things doesn't make a system GDPR-noncompliant. You have to actually do noncompliant things to not comply.
> The transmission of data is already covered by GDPR, you don't have to store the data to be bound by the law.
This cannot be the actual correct interpretation of the GDPR, because under this logic _all_ IP packets on the public internet (made by/to EU citizens) are covered by the GDPR because you are transmitting data alongside an IP address.
"The European Commission maintains this website to enhance public access to information about its initiatives and European Union policies in general."
https://ec.europa.eu/info/law/law-topic/data-protection/refo...
"Home > Law > Law by topic > Data protection > Reform > What is personal data?"
"Examples of personal data
...
- an Internet Protocol (IP) address;"
Furthermore, GDPR itself specifically refers to online identifiers in Article 4 as falling under the definition of personal data[2] and then clarifies in Recital 30[3] that IP addresses count as online identifiers in this context. There seems to be no legal ambiguity in the EU on this topic at this point, but I would be not surprised to see parties who are not GDPR compliant pretend otherwise indefinitely.
[1] https://curia.europa.eu/jcms/upload/docs/application/pdf/201...
This data collection would only be exempt from GDPR if the data would be required for the service to function, but that is not the case with x-client-data.
This is not correct. The x-client-data is not personal data. x-client-data associated with an IP address is personal data. As soon as you separate the client-data from the IP, the client data stops being personal data. IOW, the tuple (x-client-data, IP) is personal data. But x-client-data on its own isn't personal data, because it cannot be used to infer the IP on its own.
I don't know where you're getting this "if two pieces of data ever touch and one of them is personal data the other one is now also contaminated as personal data". It's not true. That would make the existence of anonymous data (which the GDPR specifies as a thing) practically speaking impossible to have on the web, since all requests are associated with the IP on receipt. (or actually even worse, it would make the process of anonymizing data impossible in general, since the anonymization process associates the anonymized data with the original personal data).
To be precise, the GDPR defines anonymized data as "data rendered anonymous in such a way that the data subject is not or no longer identifiable.". The x-client-data header is exactly that. The subject of the header is not identifiable by the x-client-data header alone. Therefore the header is anonymous and not subject to strong GDPR reqs.
For the client data header to be personal data, you'd need to describe a scheme such that, given an x-client-data header, and only an x-client-data header, you could identify one (and only one) unique person to whom that header corresponds. You're welcome to come up with such a scheme, but my intro CS classes taught me that bucketed hashing is irreversible, and with 8192 buckets, you're not going to be able to uniquely identify anyone specific.
But read carefully what they say; they say there is only 8000 possibilities if the crash reporting functionality is disabled (not by default).
Otherwise the marker is a huge differentiator (I haven't seen any duplicates personally)
For almost every type of data that is true. Transforming or substituting data doesn't make it anonymous; the patters in the data are still present. To produce actually anonymous data you have to do what the GDPR instructed: corrupt the data ("rendered anonymous") severely enough that the "data subject is ... no longer identifiable". You need to do something like aggregate the data into a small number of groups such that individual records no longer exist. Techniques like "differential privacy" let you control precisely how "anonymous" your data is by e.g. mixing in carefully crafted noise.
> 8192 bucket
While others have pointed out that this isn't actually limited to 13 bits of entropy for most people, there are at least two reasons that field is still very personally identifying. First, "x-client-data on its own" never happens. Google isn't wasting time and money implementing this feature to make an isolated database with a single column. At no point will the x-client-data value (or any other type of data they capture) ever sit in isolation. I used the IPv4 Source Address as an example because it will necessarily be present in the header of the packets that transport the x-client-data header over the internet. Suggesting that Google would ever use this value in isolation is almost insulting to Google; why would they waste their expensive developer time to create, capture, and manage data that is obviously useless?
However, lets say they did make and isolated system that only ever received 13 bit integers stripped of all other data. Surely that wouldn't be personally identifiable? If they store it with a locally generated high resolution timestamp they can re-associate the data with personal accounts by correlating the timestamps with their other timestamped databases (web server access logs, GA, recaptcha, etc).
> you'd need to describe a scheme such that, given an x-client-data header, and only an x-client-data header, you could identify one (and only one) unique person to whom that header corresponds
You should first describe why google would ever use that header and only that header. Even if they aren't currently using x-client-data as an identifier or as additional fingerprintable entropy, simply saving the data gives Google the option to use it as an identifier in the future.
[1] https://www.youtube.com/watch?v=pT19VwBAqKA https://en.wikipedia.org/wiki/Differential_privacy
Correct, and another anonymization technique (in place of differential privacy) is k-anonymity. In k-anonymity schemes, you ensure that in any given table no row corresponds to any fewer than k individuals. Why is this useful? Well let's say you have some, say, 10-15 bit identifier. You can take a request from a user that contains information that might when combined, be identifying. Say: coarseish location (state/country), device metadata (browser version, OS version), and coarse access time (the hour and day of week). Combining all 3 (or 4 if you include the psuedonymous ID) is enough to uniquely identify at least some users. Then let's say you also track some performance statistics about the browser itself.
But any single piece of data (plus the pseudonymous ID) is not enough to identify any specific user. So if you use the psuedonymous ID as a shared foreign key, you can join across the tables and get approximate crosstabs without uniquely identifying any specific user. Essentially, if you want to ask if there are performance differences between version N and version N+1, you can check the aggregate performance vs. the aggregate count of new vs. old browser version, and with 8K samples, you're able to draw reasonable conclusions. And in general you can do this across dimensions or combinations of dimensions that might normally contain enough pieces of info to identify a single user.
This is essentially the same idea as differential privacy, although without the same mathematical precision that differential privacy can provide. (By this I don't mean that the data can be re-identified, just that differential privacy can be used to provide tighter bounds on the anonymization, such that the statistical inferences you can gather are more precise. k-anonymity is, perhaps, a less mathematically elegant tool).
Specifically, I'm describing k-anonymity using x-client-data as a Quasi-identifier in place of something like IP or MAC address. You can find those terms in the "See Also" section of the differential privacy wiki page you linked. Google is mentioned in those pages as a known user of both differential privacy and k-anonymization in other tools.
Hopefully that answers your question of why Google would want such a thing.
> simply saving the data gives Google the option to use it as an identifier in the future.
Yes, but that doesn't mean that they're currently in violation of the GDPR, which is what a number of people keep insisting. I'm not claiming that it's impossible for Google to be doing something nefarious with data (although I will say that in general I think that's an unreasonably high bar). Just that the collection of something like this isn't an indication of nefarious actions, and is in fact likely the opposite.
Google's reasoning that this is not personal data is meaningless in the face of GDPR, which considers an IP address personal data. Google has access to the IP address when they receive the data, therefore they are transmitting personal information without user consent and control, which is illegal.
Basically all users opening the browser will contact www.googleapis.com to get a unique "Protected Media Identifier", without opening any web page and even before any ToS/EULA is accepted (and there is no user consent either).
The personal data collected with the x-client-data header is not required for Google sites to function. Google uses the data to gain a technical advantage over other sites on the web, this is why the data collection in this case requires consent.
Lets not guess it, lets file a complaint, and see if we can get Google sued for n billions of euros.
[0]: https://github.com/kiwibrowser/android/issues/12#issuecommen...
After many years of testing HTTP headers, IMO this really is a non-issue. Most websites return text/html just fine without sending any UA header at all.
What is an issue are the various ways websites try to coax users to download, install and use a certain browser.
Another related issue with Google Chrome is users getting better integration and performance when using Chrome with Google websites than they would if they used other clients. ^1 Some make the analogy to Microsoft where it was common for Microsoft software to integrate and perform better on Microsoft Windows whereas third party software was noticably worse to integrate and perform on that OS.
This leads to less user agent diversity. Users will choose what works best.
UA diversity is really a more important goal than privacy, or privacy in Chrome. The biggest privacy gains are not going to come from begging Google to make changes to Chrome. They could however come from making it easier for users to switch away from using Chrome and to use other clients. That requires some cooperation from websites as well as Google.
Those other clients could theoretically be written by anyone, not just large companies and organisations that are dependent on the online ad sales business. It would be relatively easy to achieve "privacy-by-design" in such clients. There is no rule that says users have to use a single UA to access every website. There needs to be choice.
For example, HN is a relatively simple website that does not require a large, complex browser like Chrome, Safari, Firefox, etc. to read. It generates a considerable amount of traffic and stands as proof that simpler websites can be popular. Varying the UA header does not result in drastic differences in the text/html returned by the server.
1. Recently we saw Google exclude use of certain clients to access Gmail.
Just thinking out loud.
What happens, let's say, if someone malicious buys youtube.vg and puts a SSL certificate on it ? Will they be able to collect the ID ?
I guess so ?
A country's government could also take over the TLD and grab its traffic overnight.
If that's true then Google should be called out for their poor behaviour.
What I'm seeing is an RFC for anonymizing parts of User-Agent in order to reduce UA based fingerprinting, which improves everyone's privacy, that's a good thing!
Then I see someone comments how that could negatively impact existing websites or Chromium-derived browsers, comments which are totally fair and make an argument that may not be a good idea doing this change because of that.
Then someone mentions the _existing_ x-client-data headers attached to requests that uniquely identify a Chrome installation. Then a lot of comments on that, including here on HN.
To me that's derailing the original issue. If we want to propose that Chrome remove those headers we should do so as a separate issue and have people comment/vote on that. By talking about it on the UA anonymizing proposal we are polluting that discussion and effectively stalling that proposal which, if approved, could improve privacy (especially since it will go into Chromium so then any non-Chrome builds can get the feature without having to worry about x-client-data that Chrome does).