... or serve cookies via first-party subdomain ...
Also, hasn't Safari already killed third party cookies?
This is the same reason Facebook is throwing such a fit over apple's new prompt. It makes it easy and likely for the average user to disable something without having to dig through settings.
I would strongly prefer that everyone restrict themselves to the capabilities of first-party cookies. But it's still true that Google is not holding themselves to the same restrictions that they're trying to enforce on other parties.
Google is lagging everyone else on this issue because it'll hit their advertising income.
The goal is that advertisers will eventually be far better off working with a system like Private Click Measurement (in Safari betas now and set to be in next releases) than insecure things like CNAME cloaking.
I think we should just make cookies only work when the domain matches exactly.
That's why the ad industry used third-party domains in the first place, BTW - it's a zero-setup solution. Subdomains are minimal-setup; subdirectories are a huge hassle.
Another reason is ad provider doesn't have to trust first party, if ads are served from their server.
I'm not sure which reason is more important.
Easier than changing a cname.
Advertisers can't trust content people to forward requests because it would be too easy to fake them.
However a server like nginx can be set up to proxy requests matching a specific url pattern to another server. This would be a bit more work than adding a DNS entry and referencing that though.
The header, which is not available to any of their competitors, contains unique information about the install that could allow them to track people better than anyone.
https://support.microsoft.com/en-us/microsoft-edge/learn-abo...
I think it's probably about time we stop pretending any of these major tech corporations are good guys.
I could see Apple or Netflix or Amazon, try and expand their offering to include search. They already have income streams that rely on the consumer, so they can build products that are in our best interest.
Are you not familiar with Windows 10's ads and invasive tracking?
TL;DR, they claim that this header is sent to all Google-owned domains, and describes the feature flags that your browser has enabled, and it doesn't contain any PII.
Oh wait
They backpedalled on this by removing from the whitepaper their claim that the X-Client-Data field doesn't contain PII: https://vpnoverview.com/news/google-backpedals-on-claim-that...
Sigh.
I guess the closest thing to a defence to your argument one could mount is "That's not true, Chrome sends it to all Google-owned domains!" which is... not a defence.
Even if that was the case, this is a bullshit argument. They don't need any PII, it's just more fingerprinting. They already have all the personal information they'll ever need by using all the other means.
This cannot be a coincidence. They packed Chrome with fingerprints to work around GDPR by combining fingerprints on their side.
They grabbed onto the wording of PII as "personally identifiable information" that information is identifiable, but not personally identifiable, so it is ok to use for ads.
"So here I was now, two years just to the day of being kicked and clanged into Staja 84F, dressed in the height of prison fashion, which was a one-piece suit of a very filthy like cal colour, and the number sewn on the groody part just above the old tick-tocker and on the back as well, so that going and coming I was 6655321 and not your little droog Alex not no longer."
— The Prisoner
The laws are catching up this in regard. GDPR uses "personal data" and CCPA uses "personal information," both of which more generally refer to data that identifies an individual.
The current text of the whitepaper is
"The combined state of these variations is non-identifying, since it is based on a 13-bit low entropy value (see above). These are transmitted using the "X-Client-Data" HTTP header, which contains a list of active variations"[0].
The X-Client-Data header is still described as non-identifying. You're reaching for controversy where there is none. I've had this conversation with GP before[1], and it's always unenjoyable, because it's like talking to a conspiracy theorist. There's no rational basis for Google doing what you and they suggest that Google is doing. And you're willing to take events that aren't actually evidence of any kind of malaction (like rewording a document to mean essentially the same thing) and try and draw nefarious conclusions out of those things. Like, why?
If you start from the assumption that Google is acting unethically and is entirely untrustworthy, there are tons of other approaches they can take to do fingerprinting that wouldn't be detectable at all. If you're logged in, the entire conversation is moot. If they wanted to track you, they have your google account. So this only matters for logged out users, and even then, the value is marginal even if you assume Google isn't using any other form of nefarious tracking.
And again that all assumes Google is openly lying. If you don't include that in your threat model, well, then, Google probably isn't lying.
[0]: https://www.google.com/chrome/privacy/whitepaper.html#mediad...
That's a false description. 13 bits of entropy is more than most existing fingerprinting vectors. This header allows clients behind NAT to be identified with significantly greater precision.
> There's no rational basis for Google doing what people suggest it's doing.
There is. Their business lives and dies on their ability to track web users, and tracking methods are gradually being eliminated from web standards, therefore Google has a rational basis for adding new tracking methods that it can leverage - especially ones that only it can leverage.
> If you start from the assumption that Google is acting unethically and is entirely untrustworthy
I think the base assumption is less dramatic: that Google is simply acting in its own best interests by prioritizing growth over user privacy.
> If you're logged in, the entire conversation is moot. If they wanted to track you, they have your google account. So this only matters for logged out users, and even then, the value is marginal even if you assume Google isn't using any other form of nefarious tracking.
This is (obviously) about the hundreds of millions of Chrome users who are not logged in, and as I said above, 13 bits of entropy isn't marginal.
> And again that all assumes Google is openly lying. If you don't include that in your threat model, well, then, Google probably isn't lying.
Not necessarily. All it takes is a policy change. It looks like this:
1. Privacy regression is introduced and a restrictive policy is established, e.g. "we won't use that to track people".
2. 6-12 months go by; maybe a new VP gets hired, or a bizdev team discovers that this data could be leveraged for a significant bump in revenue.
3. The policy is relaxed to allow existing & future data to be used for fingerprinting.
Nobody "lied" per se, but the end result is the same.
That doesn't make the X-Client-Data header identifying. Or, if it does, then your definition of "identifying information" is exactly equivalent to your definition of "information", because it is true that any particular axis or piece of data can be used to identify clients with greater precision. The rest is just how identifying the information is. Country is identifying, as is first digit of IP address, but both are less identifying than MAC address or first name. You're welcome to subscribe to such a definition, but it's not the normal one (which is usually that said piece of data can be tied to a specific individual, although you may not be able to correlate that particular individual with a name or similar).
Under this definition, I'd probably agree that the combination of IP address and X-client-data header is identifying, but that's also not a thing anyone is going to be using, because it's not particularly useful.
> There is. Their business lives and dies on their ability to track web users
Sort of. The value of tracking individual users at the granularity you suggest is, as far as I know, dubiously valuable, and importantly, there's no reason to believe it's done. Like there's no evidence to support this beyond the conjecture.
> This is (obviously) about the hundreds of millions of Chrome users who are not logged in, and as I said above, 13 bits of entropy isn't marginal.
But if you're in this situation, and again, Google is being unethical, there are a host of other tracking tools that provide 13 or more bits of entropy that they can use.
> Nobody "lied" per se, but the end result is the same.
I'd classify that as lying (for actually more than one reason). But I'll just leave you with the same point I made to 0xy the last time this was brought up: this X-client-Data header is nearly 9 years old. When it was introduced it was considered nonidentifying and was used for chrome experiments. It is still considered nonidentifying and used for chrome experiments.
And this is why the whole idea doesn't make sense: if the header was introduced now, I could see this train of thought making sense. But it wasn't recently introduced. They've had more than 8 years to use it while there have been all kinds of other ways to get additional bits.
So now your chain of reasoning is more like
1. Telemetry is introduced and a restrictive policy is established, e.g. "we won't use this to track people.
2. 6-12 years pass, multiple executives pass through the area. The CEO of the company changes twice. The entire org chart shifts and metamorphizes more than once. The policies are maintained.
3 [concurrently with 2]. A number of nations pass new privacy laws. Previously, using this particular set of data to track individuals would have been unethical, but legal. It is now both unethical and illegal in many places.
4. Google invests significantly in a different, somewhat privacy preserving alternative to individually identifying tracking technology which is openly criticized because it is mediocre in terms of privacy preservingness.
5. At some point between 2 and 4, they started actively breaking the law by using this can't-be-used-to-identify telemetry to identify unique users. And instead of completely hiding this fact, using it as a competitive advantage, and openly being a leader in privacy (for example by being an early proponent and supporter of things like 3rd party cookie restrictions), they don't do that, and instead suffer reputational harm due to the existing tracking, the telemetry illegally used for tracking, and the proposed new scheme for privacy preserving tracking that is inferior to the illegal telemetry-based approach.
It's a line of reasoning that requires that Google be simultaneously incredibly unethical and incredibly inept. It doesn't make sense.
Google have a header being sent to advertising domains that can be used for tracking purposes, Google didn't ever disclose this fact, and Google made it impossible to disable.
Already that's nefarious.
"Just trust us, we won't abuse this!" is not good enough, considering the way it was implemented is already cloak-and-dagger suspicious.
If this were innocent, it'd be disclosed and you could opt-out. Google made a deliberate choice to not disclose this tracking to users, and made another deliberate choice to have it to be impossible to disable.
Coupled with the other highly questionable choices Google has made with Chrome, such as the giant amount of telemetry available through JavaScript that ad networks are actively abusing and it's hard not to think of Google as nefarious.
For ad networks, including Google's own ad department, Chrome is like a candy store. Firefox and Safari have tracking prevention and cookie mitigations. Chrome on the other hand has undisclosed, impossible to disable ad network tracking headers being sent to DoubleClick explicitly. Chrome's cookie security is similarly a joke, designed for the benefit of ad networks.
Chrome puts ease of tracking above security, time and time again. Not only is this choice made repeatedly, but billions of dollars are made in the process.
Do you mean Tag manager, or some other GTM?
I also, and this'll be seriously counterintuitive, doubt that they could be quite as conscientious of user data if they were handled via GTM. To sketch out the concern here: Chrome telemetry that is not used to identify people and personal ad preferences/data tied to an individual user probably shouldn't be sent via the same channel or logged in the same place. They're used for different purposes, by different people, and likely have different infrastructural concerns related to storage and querying. In fact, it would be rather suspicious if chrome telemetry data was sent via Google's ads logging infrastructure. That would imply an odd level of co-design and coupling.
> sent to DoubleClick explicitly
And everything else owned by Google. It's not sent to Doubleclick specifically, which you never seem to acknowledge. It's sent to stuff that Google owns (and presumably, really just a large selection of things sitting behind the GFE[0]).
> For ad networks, including Google's own ad department, Chrome is like a candy store. Firefox and Safari have tracking prevention and cookie mitigations. Chrome on the other hand has undisclosed, impossible to disable ad network tracking headers being sent to DoubleClick explicitly. Chrome's cookie security is similarly a joke, designed for the benefit of ad networks.
Firefox does the same thing as chrome (via Firefox Telemetry). There's privacy tradeoffs between the two approaches, Firefox's allows the telemetry holder to reconstruct browsing data for a particular user (assuming the browser sends the data out of band to some central server). Google's approach doesn't allow that. There's also some technical advantages to Google's approach in terms of telemetry (both for Chrome and for Google sites), but those don't affect the privacy tradeoffs of how the telemetry is ultimately reported.
> Google didn't ever disclose this fact
You mean except in the Chrome whitepaper.
> "Just trust us, we won't abuse this!" is not good enough, considering the way it was implemented is already cloak-and-dagger suspicious.
But, like, it's not. The lengths you have to go to to make it appear suspicious (including lying repeatedly about how Google didn't disclose the feature) demonstrate how it's not in fact that suspicious. Yes, when you misrepresent the facts, it begins to sound suspicious. But that's because you're misrepresenting what was actually done.
That practice is worse than Facebook. Facebook at least makes some effort to explain privacy implications to users in human readable text that most people can understand.
So I still feel comfortable calling it an undisclosed and impossible to disable feature. Because for the vast majority of users, this is the case. It's not disclosed to them unless they go digging through websites for highly technical whitepapers they don't understand and can't read.
Of course, the privacy policy doesn't explain the precise methodology of how the telemetry is sent, so there's no "oh its done via an http header", because it's a nontechnical explanation with the goal of informing users how their data is being used, and not of giving them details of the method.
[0]: https://www.google.com/chrome/privacy/, search "field trials"
[1]: https://blog.chromium.org/2012/05/changes-to-field-trials-in...
What is the primary purpose of the X-Client-Data header if not for some unplanned future-proofing?
Masquerading about it does not add to credibility
Also, I don't see the important word "only" in the passage you're quoting, so given the usual MO of profit-driven corporations I'm just going to assume they omit other purposes of which there's at least a ton.
Why would Google let their competitors to take advantages from fingerprinting if they can control the browser? In fact, Chrome explicitly mentioned anti-fingerprinting measures in their plan for 3rd party cookie deprecation, which is now called privacy budget.
https://blog.chromium.org/2020/01/building-more-private-web-... https://github.com/bslassey/privacy-budget
https://www.chromium.org/Home/chromium-privacy/privacy-sandb...
Have a look at the concrete proposals: https://www.chromium.org/Home/chromium-privacy/privacy-sandb...
It's all proposed web standards, none of which privilege Google ad serving.
(Disclosure: I work on ads at Google, speaking only for myself.)
However, it doesn't affect cookies which are bound to origin names rather than addresses.
Wonder how people should work around that?
But, point me to a single ISP that gives a cable subscriber more than one IPv6 address. or a /48 as initially everyone was hopping.
ISP profit from NAT. They will never get rid of it. Even if you get a /54 /64 the ad networks will just learn to assign /54 as they do today.
But, another point, ipv4 today is barred from being used to form your advertising profile under current legislation.
My computer rotates out IPv6 addresses every 30 minutes using SLAAC with privacy addresses.
While you can identify the /64, there is no guarantee that it is a single user, just like in IPv4 because of NAT there is no guarantee it is a single user. It'll identity a household, but that's it.
is the key concept I am talking about here and everyone keep saying it is not.
Just like ipv4 is what matter and why ISP will never kill NAT. They profit from it, somehow. and it is not just saving money on ipv4 address space.
https://support.aa.net.uk/IPv6
"Customers are allocated a /48 block of addresses - this is usually per customer, and so a customer with multiple circuits or sites will have a /64 allocated from the larger /48 block"
No, pretty much just those. There are very few extensions available on new builds of mobile Firefox.
I got excited when the blog team announced that the were more available on the nightly buil, but after jumping through loads of hoops I found out there's just a couple of new ones and most extensions are still unavailable.
The real question though is will all of them work?
If someone has a better explanation then Google paying them for doing that, please let me know. I think Mozilla's new CEO is a sock puppet like most of the sheep out there (including me sometimes).
You can install uBlock, but not uMatrix. Many many extensions are banned just because they reviewed ONE extension that they preferred for a certain usecase. For example, for OLED phone night reading, there's the most installed at the time extension "Dark Background and Light text" that offered many customizations and worked on reader mode, and more importantly redish text/links. But too bad, because Mozilla picked the one with NO settings, but a nicer icon (which is literally disney's darth vader, but who cares) called "dark reader" which only have bright blue links and white text (and despite the name do not work on reader mode), and because there is already one extension with "dark mode" they will never whitelist the others, or even provide a setting to enable it on your own.
This is a ridiculous lie, Mozilla has said repeatedly that more extensions are being enabled as support for more extension APIs are added, and it has been true. Several of my extensions which were previously disabled have come back online after updates.
Perhaps it will grow but I'll wait to see that before I believe it.
I'm still waiting very basic and popular extensions (uMatrix anyone?) for SEVERAL MONTHS.
And try to offer community help. Ha!
mozilla have to die for firefox to live.
uMatrix and uBlock share the same base code, and we have uBlock but no uMatrix... it is all so rotten. Almost like mozilla is actively breaking firefox.
They disabled many loved extensions by power users for absolutely no reason at all! after those power users spend years bending to all their capricious changes. moving to webextension? done. moving to a new mobile UI? done. But, they still want you to move to chrome no matter what.
We should take firefox out of their hands before it is too late.
The reasons were stated repeatedly. They rewrote the mobile browser engine, which broke extension API support since all of the internal APIs changed, and they didn't have the resources to support both browsers simultaneously for a long period of time, so they prioritized the most-used extensions first and will enable more extensions as the APIs are hooked back up underneath.
This had tangible benefits - the new browser is significantly snappier and uses less power in my experience.
>We should take firefox out of their hands before it is too late.
It's open source, if you aren't satisfied with the speed of their progress, you can always help out. You say you'd like to take this work out of their hands? Well, here it is.
These are, specifically, unimplemented APIs and known API bugs in the new Firefox Mobile, that are on the Mozilla TODO list, and for which contributions would presumably be welcome. Enjoy.
Unless when you said "we", you actually meant "other people".
I have for example one small extension that I maintain, which is basically little more than a glorified page script which therefore doesn't use any special extension APIs at all. Despite that, it took months for it to be enabled, and if it wasn't as popular as it is I might still be waiting even today.
> the new browser is significantly snappier and uses less power in my experience.
Ha! From a cold start, on my phone launching the new Firefox (with less add-ons) and loading a page seems to take approximatively twice as long as on Firefox 68, and still ~50 % more than even on Firefox 55.
So on the one hand fixing that bug makes sense and has some value, but on the other hand and in practice the increased startup time still feels rather quite annoying, too, given that my phone isn't the latest and fastest model.
*this have nothing to do with my comment*
I am talking two or three iterations AFTER that. please, stop commenting long posts where you have no idea.
yes, mozilla moved to a new engine. Before that they moved to a new extension format. etc etc etc.
All the extension developers worked on the ports already, *THEN* mozilla, only for mobile, enabled "recommended extensions" which was fine. Until they DISABLED the non-recommended (not non-updated to the new tech).
It have nothing to do with technology. In fact I have many of those extensions working on my phone by fiddling with their whitelist urls. No problem running them AT ALL.
This is political.
We've been waiting nearly a year and a half so far for them to enable extensions on the new engine.
One needs to make a mozilla account to complete the last steps and that's where I've been holding off. Mostly out of laziness and also from lack of necessity since I just moved on to other browsers in the mean time.
Step 1: Implement a whole new browser functionality where Google alone can track people.
Step 2: Eliminate 3rd party cookies so Google's competitors have to create increasingly unethical and invasive fingerprinting techniques to remain competitive.
Step 3: Increase advertising rates since they are the only company able to effectively target adverts on the web. (Profit)
Did I miss anything?
Google in their enthusiasm to prevent Microsoft from dominating the web has become worse than Microsoft was in its heyday.