> 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.
> 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.
That's basically saying "even if you opt out, we'll still try to track you, just not as much." Very unpleasant, but then again I'm not surprised to see this attitude from Google.
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.
Couldn't the Chrome installations receive a request from Google that says "Do you want to try out a new thing?", and couldn't the Chrome installations say yes with a certain probability? The only difference I can see is that the subset of users that are guinea pigs couldn't be the same in each test (if Google wanted that the subset is always the same).
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 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.
Kind of true. The whole internet was much more of a toy back then. Tracking was not viewed so maliciously as now. Heck I might have even been convinced by a hard sell "this will help your favorite sites maximize their revenue".
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.
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.
I think this is a common strategy of big players at any industry.
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".
Just yesterday I had to disable anti fingerprinting I'd enabled in Firefox because despite having a solid IP and and existing cookies to login to Google, it's security system rejected me, even after answering security questions. Turn off fingerprinting and I could log in.
So, this is a round about way of agreeing with the hidden dark patterns that Google are bringing to the web. It must stop.
Much of such discussions demonize the company, but we need to look broader. Google is a public company and its shareholders, since they share the company, are also to be pointed out. Discouraging such behaviour is better done by the shareholders by dumping shares since Google could very well argue that if it didn't work to maximize ad revenue, it would not be operating according to fiduciary responsibility principles. (IANAL .. just thinking out loud)
"I think the concern is that this disarms Google's competitors while keeping them fully-armed."
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.
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.
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.
>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?
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).
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.
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.
As long as web developers continue to create (app-)sites that only work in the latest versions of Chrome(and Chromium-ish) browsers, giving users little effective choice over what browsers they can use, this sort of abusive behaviour will continue. The sort of "feature-racing" that Google engages in is ultimately harmful for the open web. Mozilla struggles to keep up, Opera surrendered a while ago, and more recently, Microsoft seems to have already given up completely.
I feel like it's time we "hold the Web back" again. Leave behind the increasingly-walled-garden of "modern" appsites and their reliance on hostile browsers, and popularise simple HTML and CSS, with forms for interactivity, maybe even just a little JavaScript where absolutely necessary. Something that is usable with a browser like Dillo or Netsurf, or even one of the text-based ones. Making sites that are usable in more browsers than the top 2 (or 1) will weaken the amount of control that Google has, by allowing more browsers to appear and gain userbases.
This proposal would not accomplish what you intend. By slowing the adoption of open web technologies, developers and users would lean more heavily on mobile apps, which are also under Google's control considering Android's huge market share.
Developers who want to level the playing field need to develop sites that fully support Firefox and other browsers that are not based on Chromium. Users who want to see a more open web need to use Firefox and non-Chromium browsers, and complain to developers who don't properly support them.
I wish, but that's not what most people want. Hell, it's not what designers want. Thinking back to the Myspace days, people would have the worst websites imaginable. Granted, that was all done with little more than HTML and javascript, but I have little doubt what they would have done with things like HTML5 and even more javascript.
The last decade or so has really reinforced to me that we all ignore or are ignorant of fundamental structural problems with most of the systems we rely on - with us wanting them to "just work."
We're all guilty of this, we just see it up close for the things that we're building and chide others who don't care. Meanwhile we ignore other fundamental structures of modern society.
There's got to be a balance between every website looking exactly the same and fading out of my memory with one identical hamburger menu after another and dancing babies on geocities.
Are there really that many popular extensions not available on Firefox? I may be just one anecdote, but I think I'm pretty typical, and I've found the transition to Firefox to be quite pleasant, and uneventful.
Popular - no. Essential - yes. Case in point - my bank (top 5 in my country) which uses Chrome plugin for security purposes, you need it to create digital signature. So once a year I HAVE to install Chrome (key expires every year) and then delete it. I've also found at least one payment processor not working in Firefox, my city portal for public transport and several small sites. The worrying thing is the trend - with Firefox share dropping below 10% recently it will be abandoned more and more.
My issue is with certain sites that typically either uses non standard Javascript apis that only work in blink or relies on non standard behavior of standard components (numeric form inputs was mentioned here yesterday).
HTML is not enough. It’s why templating languages / libraries were invented, and it’s why SPA’s are so popular. There’s a difference between “sites” and applications. The web has been trending toward supporting applications more and more for a very long time.
The only thing that will make people who want to preserve the content-web happy is if we split the protocols somehow, and that will never happen. This is not likely to change ever.
I havent had js on by default in years. Using a js enabled browser is a drastically worse experience.
suckless surf lest you enable js with a hotkey on a per-process basis if you really want it for something, but 90% of the time, I just close the tab that wants to waste my time.
I think we at HN have a particular responsibility to keep the web free and open. This really is an arms race and only those of us building the tech have the power curtail FAANG's overreach. It might me time to choose a side and firmly push your work toward open web friendly tech.
> Making sites that are usable in more browsers than the top 2 (or 1) will weaken the amount of control that Google has
You do realize/remember that Google is also a search-engine company, one that only stands to benefit (in terms of increased capability of advertising targeting) from a web that's simpler, and therefore more machine-legible.
I’m not so sure about that. Google has the resources, a simpler web makes it easier for competitors, seems like google is already quite competent at machine reading just about everything, even sometimes things that you can’t fond/visit. Domination by web-apps is the equivalent to widening the moat.
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]
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.
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!
"Tracking purposes" is such a weasel word, when we're really talking about device management in an enterprise setting, and this code only gets activated if the root/administrator user has installed a token file on your computer.
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.
True, more precisely - 16 bytes, 32 hex characters. Your link is in agreement "The machine ID is usually generated from a random source during system installation or first boot and stays constant for all subsequent boots." And See https://wiki.debian.org/MachineId at least one distro uses it for the DHCP ID.
Readit News
> 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 )
> 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.
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.
Except for everything you do on your browser. I'm so glad I haven't used Chrome for almost three years.
Wat? You mean to tell me they can identify you if you log into their service?
Am I missing something here? Who cares?
"If, statistics are disabled."
In chrome://version you can see the active variations. It seems to be pretty big numbers to be significant, and so far haven't observed duplicates.
Since this header is generated server-side, you have only to believe I guess ? Plus why Doubleclick would need it :)
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.
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.
Dead Comment
I think it was around 2006 that I got the extension for Firefox; Google bought them about a year later.
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).
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".
So, this is a round about way of agreeing with the hidden dark patterns that Google are bringing to the web. It must stop.
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.
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.
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?
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).
[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.
I feel like it's time we "hold the Web back" again. Leave behind the increasingly-walled-garden of "modern" appsites and their reliance on hostile browsers, and popularise simple HTML and CSS, with forms for interactivity, maybe even just a little JavaScript where absolutely necessary. Something that is usable with a browser like Dillo or Netsurf, or even one of the text-based ones. Making sites that are usable in more browsers than the top 2 (or 1) will weaken the amount of control that Google has, by allowing more browsers to appear and gain userbases.
Developers who want to level the playing field need to develop sites that fully support Firefox and other browsers that are not based on Chromium. Users who want to see a more open web need to use Firefox and non-Chromium browsers, and complain to developers who don't properly support them.
The last decade or so has really reinforced to me that we all ignore or are ignorant of fundamental structural problems with most of the systems we rely on - with us wanting them to "just work."
We're all guilty of this, we just see it up close for the things that we're building and chide others who don't care. Meanwhile we ignore other fundamental structures of modern society.
My issue is with certain sites that typically either uses non standard Javascript apis that only work in blink or relies on non standard behavior of standard components (numeric form inputs was mentioned here yesterday).
The only thing that will make people who want to preserve the content-web happy is if we split the protocols somehow, and that will never happen. This is not likely to change ever.
suckless surf lest you enable js with a hotkey on a per-process basis if you really want it for something, but 90% of the time, I just close the tab that wants to waste my time.
Can you elaborate what exactly is abusive behavior?
> [...] reliance on hostile browsers, [...]
What exactly is a hostile browser?
Dead Comment
You do realize/remember that Google is also a search-engine company, one that only stands to benefit (in terms of increased capability of advertising targeting) from a web that's simpler, and therefore more machine-legible.
[0]: https://github.com/Eloston/ungoogled-chromium
[1]: https://github.com/bromite/bromite/blob/79.0.3945.139/build/...
[2]: https://github.com/bromite/bromite/issues/480#issuecomment-5...
Dead Comment
Previous discussion: https://news.ycombinator.com/item?id=21034849
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.
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.
Deleted Comment
Deleted Comment
[0]: https://chromium.googlesource.com/chromium/src/+/master/comp...
And in a sick twist they have this comment for it:
Quoting from https://www.freedesktop.org/software/systemd/man/machine-id....:
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.
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!
* http://jdebp.uk./Softwares/nosh/guide/commands/machine-id.xm...