TL;DR I think whoever posted that is trying to bury the UA anonymizing feature by derailing the discussion.
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).
I think the concern is that this disarms Google's competitors while keeping them fully-armed.
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.
While I agree with some of your comment, I feel like it’s harsh to paint the whole chrome enterprise with that brush. Chrome was about freeing the world of a truly terrible web browser and a lot of devoted devs have spent a lot of time working on it. There’s an advertising aspect that it’s right to call out, but I think on the whole it was done to make the internet better, because the internet is google’s business too.
The way I see it, both of these can be (and most likely are) true. Intentions of the company aren't usually the same as intentions of individual contributors (or even whole teams). The Web is Google's business - the more stuff happens on the Web, the more money they can eventually make of it. Advertising is how they make most of that money, so this is what they're protecting. But beyond that, Chrome answered a real need and a lot of hard-working people made it into a best-in-class browser.
>which improves everyone's privacy, that's a good thing!
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.
> Except it does not affect Google, because Google has this install ID to use both for tracking and preventing ad-fraud.
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?
Apple is not engaged in illegal data harvesting to gain a competitive advantage over other services in the same space. Google's collection of personal data with the x-client-data header without user consent is illegal under GDPR.
No, it doesn't. GDPR treats an IP address as personal data. The data is not transmitted through an anonymizing network, so Google has access to the user's IP address when they receive the data.
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.
> 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.
See my edit. There's conflicting information on this. A dynamic IP, for example, isn't directly related to or relatable to a specific natural person without other context.
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.
This is the equivalent of a protest, people are objecting to Google's illegal data harvesting practices in places that receive engagement, since that's the most effective way to get the word out and warn others.
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).
I think the Widevine CDM request is needed for the service to function, though they could certainly delay it until a website requires DRM. GDPR allows the use of personal data without consent when it is required to provide a service for the user.
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.
Whether consent is legally required or not, as a user I want that service, whatever it is, to not work until I consent to the exposure of my personal data. Given that it apparently has something to do with DRM, I would be disabling the service anyway.
The Google employee argues that through UA-CH Google wants to disincetivise "allow" and "block" lists.
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.
The poster is the author of Kiwi browser, which unfortunately is closed source [0], but I have reason to believe he is familiar - as I am for the Bromite project - with all the (sometimes shady) internals of the Chromium codebase; it is indeed off-topic to discuss the header issue there but I would say that there is no explicit intention to derail it (and no advantage), just incorrect netiquette.
> 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.
> 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 )
> > 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.
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.
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.
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.
> 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.
>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.
... 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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Credits to the ungoogled-chromium project [0] for the patch [1] which is also used in Bromite since 15 February 2018 to prevent this type of leaks; see also my reply here: [2]
Everybody imagine going back 15 years and tell yourself that you're using a web browser made by the parent company of DoubleClick. Your 15 year ago self would think you're a moron (assuming that 15 years ago you were old enough to know what DoubleClick was).
I can only speak for myself, but myself from 15 years ago would not have cared so strongly about the choice of browser. I believe I was using the newly-ad-less Opera at the time, and new/cared little about the company making it.
I always believed that tech-savvy people using Google Chrome are morons. It's the perfect blend of Google being evil trying to force it to everyone, the browser being dumbed down to masses so much it's missing the most basic features, and I guess privacy concerns too when using browser from advertising company.
This seems like a cut-and-dry case of getting caught in monopolistic behavior. The code is right there. The Chrome codebase has special features for Google’s own web properties.
I hope all these AGs suing google have some good tech advisors. It’s hard to keep track of all the nefarious things google has been up to over the past decade.
Security flaw? Surely some entity is squatting youtube on some TLD?!
If there is a country TLD of X where Google owns google.X but entity Y owns youtube.X then entity Y gets the X-CLIENT-DATA header information. See usage of IsValidHostName() in code.
"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."
While this header may not contain personally identifiable information, its presence will make every request by this user far more unique and thus easier to track. I do not see Google saying they won't use it to improve their tracking of people.
One click while logged into any Google property will be enough for them to permanently associate this GUID with your (shadow) account, they know it, and they know you know it too
If you strace chrome on linux it also picks up /etc/machine-id (or it did back when I looked), which is a 32 byte randomly generated string which uniquely identifies you and on some systems is used as the DHCP ID across reboots.
First I thought reading /etc/machine-id would be expected if Chrome uses D-bus or pulseaudio libraries which depend on D-bus, and /etc/machine-id is part of D-bus. But no, they really use it for tracking purposes.
And in a sick twist they have this comment for it:
std::string BrowserDMTokenStorageLinux::InitClientId() {
// The client ID is derived from /etc/machine-id
// (https://www.freedesktop.org/software/systemd/man/machine-id.html). As per
// guidelines, this ID must not be transmitted outside of the machine, which
// is why we hash it first and then encode it in base64 before transmitting
// it.
In fairness, the guidelines they reference suggest you do exactly what the comment says they're doing (assuming they're keying the hash). The guidelines seem explicitly written with the idea that unique identifiers _derived from_ this value are not similarly quarantined, provided that you cannot take the derived value and "reverse" it back to the original identifier.
This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve the original machine ID from the application-specific one.
> which is why we hash it first and then encode it in base64 before transmitting it.
This made me chuckle. "As per the rules, we'll put on a boxing glove before we punch your lights out". You wont get privacy, but at least there is some security!
When puppeteer first came out I was nervous to use it for scraping because I could totally see Chrome pulling tricks like this to help recaptcha in identifying the bots. I’m still not convinced they aren’t.
FWIW, it looks like that's a test case -- it is not part of Chrome itself. They most likely just wanted an example of a third-party website, and could have used any non-Google site there.
Yes, But they tested Yahoo of all websites to make sure they don't send tracking data, and not an unrelated website like wikipedia or archive.org. The only non-google test case too I might add.
It's a test case I wouldn't read too much into it. Maybe it's evidence of a massive anti-trust conspiracy at google, but it could very well be because it's the first domain that came to the programmer's mind at the time.
I wasn't aware of this, but it still seems like a thread worth pulling on. You're assuming, right? The reason I ask is that using any third-party company seems inappropriate. Even more so when Google has plenty of domains of its own to test against. Even more so when it is against a media/advertising company. And again, even more so against a company that changed from Google to Bing to power their search function. It seems to be an inappropriate or poor choice, doesn't it?
There's no smoking gun here, but I don't think that concern might be dismissed out of hand. It might be good to see what Yahoo's take on this. This could even evolve into participation by the US Attorney General. I'd like to know more, either way. Like if Yahoo was independently added to the list at a later date, or if it was there from the start?
The functionality is the functionality: it targets the header to Google sites. If there's a legal issue it really stands or falls there, not on the presence of another company's domain in the tests. There's nothing Yahoo-specific about what Chrome is actually doing.
I've long seen it almost as a tradition to use yahoo for things like testing if the internet is working, e.g. "ping yahoo.com". I suspect this isn't much more than that.
It's an arbitrary test string, not evidence of evil intent. A sufficiently uncharitable interpretation can make anyone's writing look evil. It's not so.
So, an extremely unique identifier for tracking purposes, that effectively no one knows exists, and no one knows can be changed at all?
With an obscure white paper that allows Google to claim they comply with the law because "they totally offer a way to change that and they even published that information to the web for anyone to find"?
Until we are deployed enough that users don't have a choice...
Now that Google has cornered the market for Internet browsing, they're using that foothold to change how it works to suit their dominance. This is why they are not concerned about per-site tracking that Google Analytics does, as long as THEY as a company have direct browser-based tracking, they no longer need to provide tracking services to other private companies to know what is trending everywhere. This is also probably why they're trying to kill ad blockers and certain browser privacy extensions.... But they won't really matter to Google if everything is done at the browser level to begin with from now on. :/
If they make moves to scale back [free] Google Analytics, which they probably will at some point, it will only highlight this ideal... They may turn to selling their privately collected metrics and qualitative studies to companies after Google Analytics is rendered useless, and then that's unadulterated monopolistic profit for them and shareholders...
There's also the subset of all of us who must use Chrome because <solution X> needed for work requires said browser. Google's dominance through Chrome extends to the whole ecosystem. Same thing with Apple inside their own (which is nowhere near a monopoly at 10-15% market share worldwide, thus totally fair game by comparison).
They might and I used to be one of them, but now I use Google on Firefox isntead, because DuckDuckGo no longer yields useful results. The number of times I don't go "oh ffs, fine, !g" has been in steady decline over the last year, and at this point I've given up.
Why do people still dredge up Google's historical "don't be evil"? It's not been applicable for half a decade now, and even in 2015 when it was officially removed from the last company documents, it was already a dead phrase.
Google had already cornered the market back in 2012, when it surpassed every other browser, with an absolute majority dominance (>50% market share) achieved way back in 2015.
"There’s no point acting all surprised about it. All the planning charts and demolition orders have been on display in your local planning
department in Alpha Centauri for fifty of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start
making a fuss about it now"
13 bits of entropy is not an extremely unique identifier.
The first three letters of your first name have more bits of entropy than that. It would be quite a trick to uniquely identify you by the first three letters of your first name.
I fear the factual incorrectness isn't mine: the random string used is 13 bits of entropy only if usage statics is disabled, which isn't the case by default. By default, it uses an unspecified entropy (and you can bet real dollars that it'll be more then 13 bits worth).
Don’t forget that even if the number is varying only in an interval of 0 and 7999, this means without cookies a unique chrome installation can be identified if multiple users are using the same IP, like residential houses with families, etc. — that way it is possible to determine the unique amount of devices inside a house.
Right-click in the Name column, select "Save all as HAR with content". Then grep for the headers, e.g.,
sed -n '/headers\":/,/\]/p' example.com.har
While running Chrome, try
ps ax |grep -o field-trial-handle[^\ ]*[0-9]
Handle to the shared memory segment containing field trial state that is to be shared between processes. The argument to this switch is the handle id (pointer on Windows) as a string, followed by a comma, then the size of the shared memory segment as a string.
Also, can try typing "chrome://versions" in the address bar
I think extensions can filter out the x-client-data header, though Google should definitely make this data collection opt-in.
GDPR is very clear about this data being personal information [1], since Google has access to the IP address on the receiving end, which has been repeatedly tested in courts as being personal data.
Google is engaging in personal data harvesting without user consent and control, and no amount of mental gymnastics presented in their privacy whitepaper [2] will save them in courts.
That would mean they are actually not tracking you (via that method at least) in private mode. I was just about to investigate how or if they were tracking in porn mode.
But unless you changed IP, and other machine characteristics they'll be able to link the machine-id with an alternative fingerprint (cf amiunique/panopticlick).
It seems like a reasonable time to bring up the reformer project 'ungoogled-chrome' [1]. I have used it and new versions of Firefox for over 3 years and have seldom had to jump back to `Googlified Chrome.` Do know that installing via `brew` [2] means no - standard browser auto-update. Which in this case, makes sense to me.
Aside: It seems to me the realist punk / anti-the-man software one can work on is a user respecting browser. I don't work on these, but I am very grateful for those out there who do.
Is this at the "Chrome" level, or baked in at the "Chromuim" level? And therefore also an issue for Brave, Opera, Vivaldi, new-Edge, and anything else jumping on the browser engine monoculture?
PII concept is not the same for everyone/everywhere. For GDPR we have:
> Article 4(1): ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
If this chrome browser ID is matched against a (for example) google account, then they can track every single person. And that is just a couple of IDs, let alone all the quantity of data they have.
It's against GDPR to not be clear about this kind of ID. If my browser has an unique ID that is transmitted, then this ID can be coupled with other information to retrieve my identity and behavior, so it should be informed (in the EU).
EDIT: TD;LR, hiding behind "there is no PII in that ID" is not enough.
I'm sure there is someone out there who takes these kind of things seriously. Not me. I use firefox for that matter.
> And what if they put this in the browser's T&C?
Then the rest of GDPR applies: a clear message about the browser sending this info has to be shown, explaining why, with who they'll share it, the time they will keep this info, plus no auto opt-ins, the possibility of asking Google (or whatever) all the info relative to this ID and the option to cancel all the data, etc.
This is why I consider the GDPR to be unrealistically broad in its definition of PII; it denies even innocuous feature-mode-distinguishing headers intended to allow for bug-identification of massively-distributed software installs.
If I'm given a forced choice between "more privacy" and "better software quality" I'm going to lean towards "better software quality."
Me too. Then a breach happens and someone with a straight face tells you: "we take your privacy very seriously", asking apologies, because the breach used some of your data to push some political campaign or to bother you with spam/extortions because that night you were watching some porn.
Programmers should stop pushing buggy or incomplete software as is, and start releasing software that works. Otherwise upper levels have an excuse to do all this "experience" telemetry, and we all are smart enough to see the consequences of a data breach.
> Programmers should stop pushing buggy or incomplete software as is, and start releasing software that works
If you demand a perfection-of-function guarantee from something as complicated as a web browser, you'll never get a web browser with more features than the ones released in the '90s (and I'm not even sure we'd be that far along by now).
If I'm given a forced choice between "more privacy" and "the software ever having the features I want to use" I'm also going to lean towards "the software ever having the features I want to use." And we know this is true for users in general because of the number of users who had Flash installed back-in-the-day in spite of the fact that it allowed a total bypass of the browser security model, because it had features that the browser lacked otherwise.
Instead of giving my privacy away, I prefer software like anything that you have installed from a CD-ROM back in the 90's and didn't needed a weekly update. Games, 3D-Studio, Autocad (to name a few) were more complex than a web-browser (a today's web-browser) and didn't needed a weekly update or the hunger for user-requested features, let alone dialing home because. The world worked relatively fine without the up-to-date wankery we see today.
They were also buggy and could crash their resident OSs all the way to a stuck state, and if they did, the solution was "Try not to trigger that bug again."
Software quality has significantly improved in the era of easy patch access and auto-patching.
Holy Jesus. Those things were chock full of security holes. If you used a web browser that arrived on a CD ROM you'd be advertising massive pwnability.
In fact, you could easily simulate this by using last year's Firefox.
Hard to say, but not necessarily a great example; exploits on software are a function both of attack surface / complexity and installed userbase (i.e. nobody bothers to see if lynx is pwnable because a zero-day against that browser will be worth, what, twenty bucks to gain access to the five people who use it?).
That's understandable, but it isn't what most people want---developers or users alike.
Browsers aren't just thin-clients to support HTTP protocol and HTML rendering. They've grown to adopt a new distributed computing paradigm, not unlike UNIX and its descendants grew to support a new multi-user-cum-multi-process paradigm. The things web development offers---location agnosticism, platform agnosticism, combined multimedia interaction, a workable security model for multi-source aggregate-component content---are eating software development, and the browser is becoming the OS of the modern era. We know users want this because users were willing to use Flash (even though Flash broke out of the security model of the old browser).
There'll always be a place for small text-based pages much as modern computing will always have a place for command-line tools, but the genie is out of the bottle and it won't be put back in.
This it outrageous. Browsers are user-agents, not advertising accelerators. They should hide as much personal identifiable information as possible. This is exactly why using a browser from an advertising company is not a good idea. They use it to improve their service... The lie gets old...
This comment was sadly written in Chrome, since I need it for testing...
edit: pretty much exactly 10 years ago they already tried their shit with a unique id. We should have learned from that experience.
Lol, is it news? I mean, it worked like this as long as I can remember, privacy conscious users were complaining for years, helplessly watching as Chrome market share grows, but nobody really cared, so... And now, suddenly, people act like this is big news and they are outraged by such blatant and unexpected(!) intrusion into their privacy.
Wow. I don't even know how I feel about it anymore.
It appears that chrome based Edge does not send this header. I've switched to firefox for everything I can switch, perhaps it time to use Edgeium over chrome for anything else.
Well Mozilla burnt my trust in them over the last couple of years ... maybe Brave?
Some don't like their model to tip content providers but they seem - and I've not made rigorous enquiries here (please inform!) - to be a relatively trustworthy mod of Chromium!?
Can you test it in Microsoft's new Edge browser based on Chromium? I'm very curious about that. (I don't know how to test such a thing myself, sorry :S)
I use (sometimes/often) mitmproxy and remove or change suspect headers. It is also nice to remove all the fb, google and more crap from the html. And much more. It is a lot of work not to break a website. I don't know whether I am more trackable or not - this is the 'only browser' without x-client-data header.
Am I correct to understand that this backdoor tracking of individual users applies to the standard Chromium browser (i.e., the non Eloston ungoogled-chromium) as well as the Chrome browser?
If so, its incredibly consistent with Google's surveillance capitalist business model.[1] Wow. I'm thankful for Firefox.
With that said, one can simply filter out these analytics with a c:\Windows\Systems32\Drivers\etc\hosts -> pointing to 0.0.0.0 or PiHole solution (https://pi-hole.net/), yes?
I mean, this is probably not the holistic solution, but this is why we have a firewall, vpn, antivirus, filters to just keep DNS in check, yes?
Yes, you can if you are willing to block google.com, android.com and youtube.com.
doubleclick.com might not be terrible for most, though.
Interesting enough, it does not add headers when accessing a country specific google domain in the EU - such as google.de or google.fr.
Is that GDPR kicking in - with a nod the the brexiteers given that google.co.uk gets these headers... ?
Irrespective of whether you use any other google products, if you use chrome google can now track you over any property that uses google ads, recaptcha, etc.
The header is inserted by the browser after any extensions run, and google pins google properties so you can have an intermediate proxy that strips the header, so they gain persistent tracking of all users across most of the web?
If it wasn’t a tracking vector why do they limit it to just google ads, etc? Why not other ad providers as well?
This is another instance that google doesn’t care about users privacy and track without their consent by using chrome installation Id. This probably might be against GDPR, so Chrome installed base in Europe multiplied by per day fine, hopefully runs into a years revenue of google.
Another lesson don’t trust for profit companies with privacy protection especially advertising technology company like google with motto like don’t be evil or organize world’s information designed to mislead.
Honestly, it's 2020, even if your technical understanding is so low that you have no idea what a "browser" is, you know that Google will do anything in it's impressive power to track down everything you do with legal or illegal means.
Thanks to Snowden, this is no longer a conspiracy theory. It's a fact.
Google should be fined for this but they probably won't be.
This sounded harder to do than it was in my experience. I figured the alternatives to their products would be less polished. But I switched to Firefox and honestly prefer it to Chrome. (They allow extensions on Android, meaning adblock, which is a game changer for me.) DDG for search is great. Protonmail for email is fine, etc. There isn't much in the Google ecosystem that I miss tbh.
The only thing I have problems finding something that works is Google maps. As an Android user there are a few different options but Google did make a damn good maps app.
For every single claim Google makes about being pro-privacy, their definition of privacy ("data shared between you and Google and no one more") is implicit.
It's a surveillance company that makes proprietary software to sell you ads. As soon as you get that into your head, you'll be much less shocked.
"We personally get to track you" is not a unique stance, and it's far from a backdoor. It's just another vile move from a surveillance company that's pretty explicit that that's their goal.
Sure, the general pattern of behaviour is familiar, but I didn't know about this specific manifestation, and now I do. What's the use of being so dismissive about specific information on which one can act?
I dropped chrome a long time ago and switched to Brave. Does Brave have these same issues, considering it uses webkit for it's rendering engine? Am I just being paranoid?
Quite a lot of reasons. I assume you asked that because you're thinking it's used to gather information on its users. That could be one of the many reasons. At least initially it was because Mozilla/Firefox didn't want to adopt a multi-process architecture.
In terms of strategic reasons, as a company that depends on people browsing on their websites other reasons are obvious: avoid lock in that could be pushed by third-party browser makers/competitors (say IE becomes the most popular and it implements proprietary extensions that work only on their websites[1]), ensure there exists a fast secure browser so that people can keep browsing even if everyone else stops making good browsers out there.
[1] Now before you go ahead and point out how Google proposes HTML/HTTP features that get implemented in their browsers and on the server side, all such features have public specification and source code, so anyone else could implement them too. This is very different from the IE days of yore, where MS was extending IE through ActiveX. ActiveX was developed in house and they were releasing binary plugins/SDKs to develop ActiveX plugins, effectively maintaining full control over it (one would have to develop ActiveX compatible technology from scratch if they wanted it open source, with Chrome all they have to do is fork the source code).
Not sure why this is being downvoted. It hits the nail on the head. If you are concerned about privacy around advertising then using a browser from the biggest online ad company is short sighted.
so that you don't have to pay royalties to other browsers for being the main search engine.
I mean you have to pay one less. And if you have the most used browser, you save a lot.
In the good old days everyone and their grandmother just sideloaded their malware toolbars with freeware crap like picasa or maps or outright bundled their bloatware with the system like Google still does for Android.
When Chrome was first developed, browsers and the web were relatively slow, and slowing down due to the popularization of Javascript and heavier websites.
Google's worked on a number of technologies to make the web faster; Chrome (and V8), their own DNS, image and video compression technologies, AMP, HTTP/2 (SPDY), HTTP/3 (QUIC), webserver plugins (mod_pagespeed), benchmark tooling (Lighthouse), and extensive guides on website speed optimization.
The reason is simple; faster internet = faster browsing = more page views = more ad impressions + more behaviour tracking data points. And it's a win-win for Google as well, because it earns them goodwill (well, except for AMP); especially at the time Chrome was a breath of fresh air compared to Firefox, and it's taken a lot of time and effort just to keep up, with mixed results (to the point where a number of manufacturers have just given up and adopted Chrome's renderer).
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).
reply