Google dragged to UK watchdog over Chrome's upcoming IP address cloaking
theregister.com
theregister.com
I haven't used Chrome since this rolled out, since I didn't see a way to object to the new tracking. This is what the linked article [0] says:
> It’s unclear if toggling these features off will stop Chrome from collecting these data altogether, or if it just won’t share the data with advertisers.
[0] https://theconversation.com/google-chrome-just-rolled-out-a-...
[1] https://developer.chrome.com/en/blog/shipping-privacy-sandbo...
With Apple we know they have a bunch of revenue streams based on selling actual products to users, so there's much less of a hazard there. With Google... who knows what they'll do to juice their next earnings report?
- Some HN commenter in 1890s (probably)
Google is already at the point of too big to fail.
It's actually worse in every way regardless of the user's aims.
Having individual sites track you across their affiliates is much better than having a single party track you across everything for commercialisation purposes.
TBH, the tech community asked for this. The support for google chrome over firefox is driven primarily by technical folk.
The majority of people really don't give a damn what browser they use.
> It has the side effect of sending every domain you visit to the certificate log server.
No? It means that if a certificate is to be trusted, it needs to enter a public append only log server.
It does not "send every domain you visit to CT." The certificate simply has to be in CT before chrome trusts it.
CT logs are public, you can (and many do) make archives of it.
The idea is simple, if a website is to be _publicly trusted_, it needs to also be publicly logged.
You have heavily misunderstood what CT does, and the paradigm of control around it.
You're not thinking about it hard enough. Your CT's would effectively have to be implemented in a way where everyone had a locally cached copy of the log to check against. That at least shuts down an browsing activity leak vector.
If you centralize it, the abuse is a matter of when, not if.
Again, misunderstanding of how it works.
Logs are checked using the SCT in the certificate. It's a signed "promise" from the CT that the pre-certificate will eventually be appended to the logs in a few hours since submission.
The various root programs monitor to ensure that the promise does in fact happen.
Your browser process does *not* reach out to the CT log on its own.
I've worked at both Let's Encrypt and Google Trust Services. CT is something I'm intimately familiar with.
> it has to check the cert log.
No, it does not.
> Yes but how does your browser trust it?
Your browser ships with a log list: https://source.chromium.org/chromium/chromium/src/+/main:com...
The public key of the log is included there. It's checked to see if the SCT is signed with the correct public key.
There are three possible states:
No Safe Browsing protections -> no SCT auditing
Default Safe Browsing protections -> SCT auditing logic selects a small proportion of TLS connections and performs a k-anonymous lookup on an SCT. If that privacy-preserving SCT lookup reveals that the SCT is not known to Google but should be, the client uploads the certificate, SCTs, and hostname to Google (but no other information).
Enhanced Safe Browsing protections -> SCT auditing logic selects a small proportion of TLS connections and uploads the certificate, SCTs, and hostname to Google (but no other information).
I was talking about the validation side. SCT Auditing basically helps ensure that the logs are keeping their promise by letting the root program (Chrome, and Apple) see what certificates are flowing on the internet and if the merkle tree structure is valid.
CT does not require that, that was part of the explicit design goal of CT. To be trusted by a browser a CA has to publish every certificate they issue to multiple CT logs. When the certificate is published to a CT log, the log provides a signed confirmation, and that is included in the final certificate.
Every browser has a set of CT logs that they trust. When they perform the trust evaluation on a certificate they verify the certificate is correctly signed by the CA, and then they go through the included CT annotations and find the annotations from logs that the browser trusts and verify that those annotations are signed with the respective log's public key.
At no point does the browser perform any other network requests (again, a problem with OCSP is that the additional network access during TLS handshakes was incredibly slow and unreliable - if CT required this it would require _more_ fallible network loads). That makes CT faster, and resolves the privacy hole OCSP forced.
Google will likely already have the user's IP from sync, safe browsing, etc, if Google's proxy doesn't know what sites are visited it doesn't sound like this increases Google's access to any user data.
Definitely not the actions of an org trying to exert monopoly power.
I thought privacy sandbox could be used by any website, just the same as Google can use it. Am I wrong?
Disclosure: I work at Google, but as can be seen from my comment, I don't have much knowledge of privacy sandbox.
Discussed here: https://news.ycombinator.com/item?id=31387019 or https://news.ycombinator.com/item?id=27467798
Why is it good when Apple does it but terrible when it is Google?
If they feel this is in the best interest of the end user, then they should divest of either their ad business or control of the browser. Neither company is willing to do this. This IP move is anticompetitive as it consolidates even more control of the ad ecosystem in a handful of companies. Google’s response that they are placed at the same disadvantage as other third parties is not accurate. Google controls the browser and so has full control to communicate any data between the browser and their servers, bypassing the proxies.
There is only one thing that drives these companies and that is maximizing profits for the benefit of their investors. This objective is fine. However, it is disingenuous for either of these companies to hide behind the defense that they care about the privacy of end users.
If Apple cared about the privacy rights of all humans, why do they share all data belonging to their customers in China with the Chinese government. The only reason is profits. Google also shares all their customer’s data with any government that asks.
If there were a thousand companies that each had access to a tiny sliver of a consumers data, we would have a system that naturally protects end user privacy. However, with a few companies controlling the vast majority of the consumer tech landscape, we now have a system where a few for-profit companies are keepers of our data and already sell out when their profits are at stake.
Apple's service is explicitly designed to prevent this exact problem. There's a write up for it on apple's security site (possibly part of the system security doc?). There are intentionally two layers, the connection from the device -> apple's servers, and then the connection from apple's servers to Akamai or cloud flare (or some other CDN). The connection to apple's servers is encrypted to a key from the 2nd layer CDN so apple can't read it, that request is forwarded to the CDN which decrypts it makes the request, then encrypts the response to the client's key and sends that to apple, apple forwards that encrypted blob on to the originating device which can then decrypt it.
The end result is apple cannot ever see the destination or response, and the backend CDN can't see the device that made the request. That should be the design of _any_ privacy conscious proxy service (including all the questionable "privacy!" VPNs). That's kind of why I'm surprised that the claim is that Google's service is a single layer - it's so blatantly invasive.
> We are considering using 2 hops for improved privacy. A second proxy would be run by an external CDN, while Google runs the first hop. This ensures that neither proxy can see both the client IP address and the destination.
— https://github.com/GoogleChrome/ip-protection#core-requireme...
If they choose to go ahead with the second hop it would be the same as Apple’s approach. But it sounds like this has not been committed to yet.
They have much more to be annoyed at. VPN companies, The Tor Project, AD blockers, etc
I use the Google One VPN[0] to cloak my real IP, but only sparingly. For most of my Internet surfing I use a two hop VPN setup. One VPN router with kill switch mode, and then I connect to another VPN service on top of that, a sort of fake Tor / private relay setup.
I don't funnel all my traffic into Google One's VPN. I like to compartment and not put all my eggs in one basket. Looks like I'll be doing the same when this new Google-owned IP cloaking feature ships.
> They have much more to be annoyed at. VPN companies, The Tor Project, AD blockers, etc
While I'm sure they dislike those, the key word here is rival - the claim is that Google has its own ad business, and is only deploying privacy features in a way that hurts other ad companies.
See https://github.com/GoogleChrome/ip-protection/issues/10 for example.
Of course, Google can conceivably backdoor Chrome, and then the exfiltration of data wouldn’t be obvious from the client-side traffic.
> It's designed to run Chrome browser connections through two proxies, one operated by Google and one operated by a third-party (eg, Cloudflare), so that the true public IP address of the user is obscured, hopefully thwarting attempts to track them around the web using that address.
We are considering using 2 hops for improved privacy. A second proxy would be run by
an external CDN ...
"Considering" means "we're thinking about it, but it's in no way final".
Sounds like Google could implement a proxy solution but decide the 2nd hop for improved privacy isn't needed after all.
Or make it optional, defaulting to OFF, etc.
This is of course assuming that the roadmap for these proxies isn't tied into their push for remote attestation ala "Safety" Net and WEI, in which case your "nym" becomes the entire device.
Yup just like most people using Android have their text messages routing through Google. Some don't even realize this.
Google Voice users like myself are SOL but I've never had pretenses that my messages there are private. They're probably stored in plaintext even, there's a lot of 15+ year old GrandCentral cruft underpinning Voice even to this day (speaking only as a user).
I mean, maybe even rethinking IP, TCP/IP entirely.
BT isn't anonymous but a TCP/IP replacement version could be.
If Google's relay just requires a Google account, there's no doubt that dummy accounts will be used to abuse the service. Apparently Private Relay sends a dynamic config of relay servers to use which they could leverage at any time to unmask you. I'm guessing Google will do it similarly.
[0] https://media.ccc.de/v/camp2023-57214-trustmerelay_investiga...
I mean I would like this if it would not come from Google.