Hacker News new | past | comments | ask | show | jobs | submit login
Chrome Feature: IP Protection (chromestatus.com)
39 points by judiisis 5 days ago | hide | past | favorite | 64 comments

This seems like it will have the opposite effect: unmask folks trying to use a proxy/VPN by having them go through a Chrome proxy first. It'll also keep IP data only available to Google for tracking purposes.

Probably isn't a good time to being doing this and revoking third party cookies while under antitrust investigations.

We don't have any details about how it works, but it's possible to implement this in an anonymous way. See my other comment: https://news.ycombinator.com/item?id=37551708. Whether google actually does this is unknown, but considering that google is voluntarily disclosing this to the public I'm willing to hold off the pitchforks until we get more details.

But is it possible to implement this in a way that the user can rely on beyond google saying “trust me bro, we implemented this right and have no ability to turn this off without you knowing about it even if we'd rather you not know”?

Safari's version of this feature stops working when I switch my VPN on.

This seems similar to Cloudflare + Apple partnership on Private Relay [0]; except the traffic first goes through Cloudflare before exiting via Apple / Akamai servers; whereas in Chrome's case, the first hop is Google themselves.

Apart from the all the QUIC vpn / proxy work Cloudflare et al (standardising Private Relay) are involved in [1][2], the OHAI working group [3] is closing in on its reviews too.

Interestingly, there is an active IETF draft for how such private proxies could be built: https://datatracker.ietf.org/doc/draft-iab-privacy-partition...

[0] https://blog.cloudflare.com/icloud-private-relay/

[1] https://datatracker.ietf.org/wg/masque/documents/

[2] https://datatracker.ietf.org/wg/privacypass/documents/

[3] https://datatracker.ietf.org/wg/ohai/documents/

OHAI seems to be related to Oblivious HTTP.

To be honest, I still don't understand the use case for that when there's already MASQUE, which seems like a more flexible and elegant solution to the same or at least a very similar problem.

Do you know what OHAI does in detail and what its advantages over MASQUE would be?

I might be wrong, but OHAI is an additional HPKE layer within the TLS protected HTTP tunnel; a more nauced take on the HTTP CONNECT method, if you will. MASQUE seems more of IPsec take 2.

See section 3.1 for a brief comparison between the two: https://datatracker.ietf.org/doc/html/draft-schinazi-masque-...

Ah, so basically the distinction is private relaying at the HTTP exchange level vs. at the TLS flow level?

MASQUE is more about tunneling TLS flows (i.e. TCP or TCP-ish connections such as QUIC/HTTP 3) than about the IP layer, is my understanding, but I suppose that's what you mean by IPsec take 2?

> MASQUE is more about tunneling TLS flows than about the IP layer, is my understanding, but I suppose that's what you mean by IPsec take 2?

MASQUE has now evolved to the point one can potentially build VPNs with it: https://datatracker.ietf.org/doc/draft-ietf-masque-connect-i...

see also apnic's post on ohttp & masque: https://blog.apnic.net/2023/03/23/hiding-behind-masques/

> MASQUE has now evolved to the point one can potentially build VPNs with it

Wow, so we've gone full circle :D Hopefully this will only be used using the QUIC Datagram – IP-over-TCP isn't fun. But I can see it making sense in certain scenarios/as a last resort.

I'm aware of the great apnic post, but it seems to predate OHAI. Hopefully somebody will write an explainer on that as well.

> In order to access the proxy a user must be logged in to Chrome. To prevent abuse a Google run authentication server will grant access tokens to the Google run proxy based on a per-user quota.

How does this protect user privacy, overall?

Presumably it uses a blinded token system rather than sending your google id. The token system ensures that each user can't go over their quota, because google will only sign a certain amount of tokens per user, but the proxy server doesn't know the identity of the user because all they get is a blinded token.

That seems indeed very likely, given that it's what Google is already doing for their VPN: https://one.google.com/about/vpn/howitworks

A proxy (i.e. the same approach Apple uses for iCloud Private Relay) would be much better, though since their VPN seems to be using a single, fairly static IPv6 address per user and connection, which allows trivial cross-site tracking of a given user.

It protects user privacy from being violated by Google's competitors.

I think it would be more useful if Google contributed nodes to Tor rather than creating their own (confusingly) centralised, decentralised alternative.

Absolutely not. Tor is chock full of stuff I don’t want to be associated with from spam to worse. Where possible you can block tor traffic, abuse management on tor is pitiful

Couple of things:

- If Tor was 'easier' for the end-user or better supported by the centralised pillars of the Internet (such as Google), maybe "spam or worse" traffic would be made a much smaller percentage and improve Tor's reputation

- Does this mean different scales of anonymity/privacy? Tor for the "spam or worse", and this solution of Google's for the casual, not-quite-as-paranoid, private individual?

P.S. You're absolutely right in your paranoia regarding "I don’t want to be associated with". I've had a member of law enforcement accuse me of, basically, being worthy of suspicion (up to and including legal violation of my rights), because I've "got tor on my computer" (yes, that's their level of understanding). They also said that running Virtual Machines and downloading things from Mega will also get you put on a list.

I'd rather Google assist to improve Tor (and it's associated reputation) than "create my own amusement park with blackjack and hookers". In this case, I think one big pool is better than numerous small ones.

P.S. Mega seems to host a number of Android ROMs, which is my primary, and possibly singular, use case.

You should see the things available on muggle internet, it's horrifying!

Maybe some people want to hide their web traffic from their ISP, but can't be bothered with setting up a real VPN. It seems pretty niche, though.

Perhaps there's a business use for this?

There was an Android-only data saver mode, but it was discontinued [1].

[1] https://support.google.com/chrome/thread/151853370?sjid=4132...

A "real" VPN is actually a pretty poor way to increase privacy when browsing the web. It essentially just swaps out the (often moderately trustworthy) ISP with an often even more dubious VPN provider.

MASQUE (which iCloud Private Relay already uses, and Google could use too) can do significantly better.

Of course, having a choice of more MASQUE providers than just Apple and Google is important.

Maybe like buying a drink ticket on credit card, but then the ticket isn't tied to identity when you buy a beer at the festival.

Authenticated, but not identified, by the end-provider.

Users choose who to be their vpn. The same goes for if they want to enable this feature.

As long as Google records your browser history by being logged in I don't understand the purpose because it will be avaiable to Government request or by subpoena.

Many advertisers seem to be using IP addresses to target users these days, especially when cookies are blocked.

iCloud Private Relay offers pretty much the same functionality, and in some ways, this is better than many single-hop commercial VPNs, where the VPN operator can trivially correlate ingress and egress data (if not account payment data as well).

I'll not comment on the irony of Google launching this particular proxy feature.

If you turn off chrome sync, they won’t get most of it. And with the removal of third-party cookies, Google’s other primary method of appending to https://myhistory.google.com (showing you the websites where Google has received a logged-in cross-origin ad request) will also be gone.

You don't have to turn off sync. Chrome supports end-to-end encryption for sync data. Set a sync password that is different than your Google account password to enable it. This will disable history sync but everything else will still be synced and unreadable by Google.


Now that this has open the floodgates, where many users would be using a VPN like service shipped by default on the worlds most popular browser, one of two bad things will happen:

1. Cloudflare (which is proxying traffic for this feature) is unable to maintain its contact neutral status as governments force it to implement censorship to comply with local laws.

2. Governments force browsers to ship a block list of domains, with tampering the browser binaries being prevented by attestation (which has already been proposed in France.)

Wouldn't governments inclined to do 1. already exert the same pressure on local ISPs?

The roles of the "proxy exit node" network and regional ISPs seem very similar, at least.

And couldn't 2. happen completely independently of this effort? Or is your point that this type of proxying would circumvent existing ISP-level blocking without 1.?


"In order to access the proxy a user must be logged in to Chrome. To prevent abuse a Google run authentication server will grant access tokens to the Google run proxy based on a per-user quota."

In order to prevent abuse... we have to give you a tracking token, to use the "Anonymizing" network. One that tracks down to the browser level, across IP switches! Way cool!

Nice try Google... we've seen tracking tokens from you enough times. :)

Without knowing any details, I strongly suspect authentication work similarly to iCloud Private Relay or Google VPN, both of which use blinded tokens that the proxy operator (here Google) can't correlate directly with an account.

It's Google... If they want to connect the dots, they will.

"It takes 20 years to build a reputation and five minutes to ruin it." - Warren Buffet

I used to trust Google. They really didn't act that scummy, etc. Now-a-days, I 'm not so sure.

Leave the VPN to the VPN providers, IMHO.

> Leave the VPN to the VPN providers, IMHO.

I'm as skeptical about Google's privacy efforts as the next person, but I think most existing commercial VPNs are even worse.

They gain ISP-level insights into your traffic, and history has shown that at least some of them aren't really more trustworthy than the worst ISPs out there (in that they've also been caught selling or at least collecting customer traffic flows, despite all the promises to not keep any logs).

MASQUE is a much better take on browsing privacy. I really do hope that today's VPN providers will be tomorrow's MASQUE proxy providers.

I won't disagree there. In fact if I was the NSA/CIA/etc, I'd just make a VPN provider, and let the traffic roll in, no need to goto the traffic, if they just give it to you, and you get the ability to have trusted access to their machine to boot...

Yes, I know OpenVPN, etc. But 'cmon, we know people would fall for the above :).

This sounds like private relay. I love it! Really love the increasing ecosystem around protecting people from their current network. Who knows what airports and coffeeshops are doing with your traffic analytics anyways.

>Who knows what airports and coffeeshops are doing with your traffic analytics anyways.

There's not much you can mine. Most traffic nowadays is encrypted so all you get is the domain. For most people this basically translates to what apps you use (eg. facebook or reddit) and possibly what company you work for (eg. if you connect to your company's mail server).

> Most traffic nowadays is encrypted so all you get is the domain.

That can be still quite interesting for advertisers, and if you think about home ISPs rather than public Wi-Fi networks, you could easily imagine your ISP also supplying your demographic range and rough location to advertisers.

Even from purely public IP geolocation information alone, I'm able to pinpoint my IPv4 and IPv6 to my ZIP code (which spans only a couple of blocks). IPv6 allows tracking individual devices on a network persistently as well, i.e. distinguishing between people in a household.

Did you see this recent disclosure?


1. That's also something that a vpn/proxy isn't going to solve, so I'm not sure what the relevance to this discussion is

2. If you're at a location that the attacker controls, there's a much more straightforward attack that doesn't even need wifi: recording your keystrokes with hidden cameras

It tell more than that.

Access to www.apple.com (with "www", so it is a browser)? Maybe I can push you an AD for iPhone 15 protective case.

Yes we should all be worried about the local coffee shop who can barely make payroll manipulating our network traffic. Fortunately we can now proxy all traffic through an internet advertising company, with credentials tying it to our identity. We should all consider ourselves fortunate this option now exists. Who knows what Sally's doing with my DNS queries in exchange for a cappuccino. Might as well have Google hoover it all up so they can keep us safe.

It’s not the coffeeshop, it’s the Wi-Fi vendor that gives them some perks for implementing some sort of wall on the network. Like when you join the network and have to click through to get access, that’s a vendor that could be data mining

How is that any different or of more concern than any other ISP in existence?

And the solution is to route all traffic through Google - an advertising company quite literally renowned for its data mining habits and abilities.

> Who knows what airports and coffeeshops are doing with your traffic analytics anyways.

I'm much less concerned about coffeeshops and airports (where I spend only a few hours per year, and modern OSes use MAC address randomization) than I am about my home and mobile ISPs.

Mobile ones are the worst and probably what inspired apple to implement private relay to begin with. I hope they provide it for third party apps soon.

Something that seems to be missed in the comments is that this is not being pitched as a general purpose VPN for routing all your traffic (or even all your Chrome traffic) through. In particular:

> Traffic will be directed to use these proxies based on a third party list of domains.

Given the feature is another of the attempts at reducing cross-site tracking surface, it seems like a good guess that what the idea is to apply this specifically for domains used for that.

Oh, I wonder if this is actually the (at least short-term) motivation for Google's much-criticized WEI [1] efforts?

MASQUE lacking a feedback channel for websites to report spam/abuse was explicitly given as a motivation there, as far as I remember.

I'm still skeptical of WEI as a whole until we know more, though.

[1] https://en.wikipedia.org/wiki/Web_Environment_Integrity

> Phase 1 will use a two-hop proxy configuration to create a connection to a destination server first with a tunnel to a Google owned proxy and second to a third-party owned proxy server. The first proxy will never know the client's target destination and the second proxy will never know the client's IP address.

Unless they share the information with each other, which is guaranteed to be impossible... how exactly?

You connect to proxy 1 and ask it to set up a tunnel to proxy 2 (the tunnel to proxy 2 rides inside the tunnel to proxy 1).

Proxy 1 knows your source IP, its own IP, and the destination IP (proxy 2). Proxy 2 knows the incoming source IP (proxy 1), its own IP, and the destination IP (the website you're accessing). Neither proxy knows both your IP and your destination IP.

I read your comment and still don't get what prevents proxy 1 and proxy 2 from sharing this information with each other.

Ah, I was thinking "share" more technically... yeah, the fact that they're operated by distinct entities makes that less likely but it's not guaranteeing anonymity, anyone tapping both proxies (NSA) could probably correlate your connections pretty easily too, but it's an improvement over a direct connection or a single proxy.

It's highly likely once someone figures out a way to financialize it

Unless Proxy 1 and Proxy 2 have a contract that says, oh hey, let's share data, OK?

Presumably they have to have a contract anyway to agree to tunnel the traffic using this protocol.

Similar to how tor works? This is basically tor but with 2 hops rather than 3.

Had to double check if they are protecting IP (Internet Protocol address) or IP (Intellectual property) by adding some sort of filtering for copyrighted content right in the browser. In any case - nothing useful.

>Traffic will be directed to use these proxies based on a third party list of domains.

this is the interesting bit to me. what is the third-party list of domains? is google going to start masking IPs for traffic to some known-sketchy list of sites?

Tell us who you are and you will be able to access “anonymously” (wink, wink) those sites that you don’t want to disclose you visit.

Maybe IPs deserve more privacy than people.

So, it's tor but with less hops?

Opera already offers this without the need to signin to an account.

iCloud Private Relay clone, implemented worse (no cryptographic privacy to the first hop, as Private Relay does it, AFAICT). Apple always does it first, and possibly best.

Sure, Apple’s will be more private but the “third party” proxy will probably be cloudflare and fastly still so a lot of benefit to end user of not having as much of their traffic vacuumed up by unsavory public networks or cell carriers.

HTTPS will keep specifics about your browsing private but MAC address, list of IPs connected to, and request sizes probably reveals a lot more than people would expect.

MAC address is a hop-to-hop implementation detail and never transmitted to the IP layer.

Also, most devices implement MAC randomization these days, so tracking based on that is also moot.

>but MAC address

Your mac address never reaches the internet. It's stripped off the moment it leaves your LAN.

Think “public wifi”

All device I have (iPhone, Mac, Windows 11, Android) randomize wifi mac address by default.

Applications are open for YC Winter 2024

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact