Chrome IP Protection: how it worked and where it stands
Chrome IP Protection routed Incognito third-party traffic through two proxies. How it worked, the Masked Domain List, coarse geo, and its retirement status.
Quick summary · TL;DR
- Chrome IP Protection masked IPs from trackers in Incognito. Third-party requests to domains on the Masked Domain List went through two proxies, so the tracker saw a shared address near the user.
- Two hops split what each operator saw. Google's proxy saw the user's IP but not the site; a CDN's proxy saw the site but not the IP, using CONNECT and CONNECT-UDP tunnels.
- Google announced its retirement on October 17, 2025. The GitHub repository was archived on November 3, 2025, and the Chrome feature switch is gone from the network feature list by the Chrome 145 source.
- Location stayed coarse, never chosen. Exits mapped to areas of at least one million users, about 700 in the US, without crossing country borders.
Chrome IP Protection was a Privacy Sandbox feature that hid a user’s IP address from tracking domains in Incognito. Chrome sent third-party requests to domains on the Masked Domain List through two proxies, one run by Google and one by a CDN, so the tracker saw a shared address near the user. Google announced its retirement on October 17, 2025.
How Chrome IP Protection worked
Per the IP Protection explainer (archived by Google on November 3, 2025), it applied only in Incognito, only on Android and desktop, only to users signed in to Chrome before opening the Incognito window, and only to third-party requests to listed domains. Users could switch it off, and managed Chrome shipped it off.
A site visited directly always saw the real IP, as did every embedded domain not on the list.
The two-hop proxy chain
Proxy A. Google ran the first hop, which saw the user’s IP address but not the destination.
Proxy B. An external CDN ran the second hop, which saw the destination hostname but not the user’s IP, and resolved DNS for proxied traffic.
Chrome built nested tunnels with CONNECT and CONNECT-UDP, the MASQUE methods: a QUIC tunnel to proxy A, a second QUIC tunnel through it to proxy B, and end-to-end TLS or QUIC to the site inside both. RSA blind-signature tokens kept either proxy from tying traffic to a Google account. Separate connections used different exit addresses. Each hop relays CONNECT like any proxy server; Chrome’s two-hop design stacks two, so no operator holds both halves.
Coarse geolocation by area
Exit addresses were mapped in a public RFC 8805 geofeed. Google split the map into areas of at least one million users over two weeks (about 700 in the US), each labelled with its largest city. Areas never crossed a country border, and the user could not pick one.
Anti-fraud controls and tokens
Each user got a daily token quota, tokens were short-lived, and traffic per token was capped. Users out of tokens went direct, unproxied. Google also proposed Probabilistic Reveal Tokens: a Sec-Probabilistic-Reveal-Token header that, after a delay of about one day, would reveal the real IP in a sample of requests. The explainer floated a reveal rate of 5-15%.
The Masked Domain List
Which requests got proxied depended on the masked domain list. A domain qualified when it was embedded as a third party and served, targeted or measured ads, collected data for marketing, or ran scripts that looked built for re-identification. Disconnect.me built the list against Google’s criteria and ran appeals, with a decision target of 10 business days and a 60-day wait after a denial.
Counts are from the published list, parsed on October 7, 2026. Google’s own ad and analytics domains, doubleclick.net and google-analytics.com among them, were on it.
Status and retirement timeline
First proposed as Gnatcatcher, the feature was renamed IP Protection for the Phase 0 test announced in October 2023: Google-owned domains only, US users only, one Google-run proxy. In April 2025 the appeals process opened and the explainer promised a Stable launch “no sooner than July 2025”, first in certain regions.
On October 17, 2025, Google’s update on Privacy Sandbox technologies listed IP Protection among the technologies it would retire, next to Topics, Protected Audience and Attribution Reporting. The repository went read-only on November 3, 2025. In the Chromium source, the EnableIpPrivacyProxy switch sat in the network feature list, off by default, at the Chrome 143 tag, and it no longer appears in that file at the 145 tag.
IP Protection vs VPN, Private Relay
A VPN carries all device traffic and lets the user pick a country; IP Protection carried only listed third-party requests. Apple’s iCloud Private Relay sits between them: two relays, the first run by Apple and the second by a third-party provider, covering Safari browsing and DNS queries, with a choice between general location and country-only.
What changes for IP-based signals
| Signal | Under IP Protection | After retirement |
|---|---|---|
| Ad geo targeting | Coarse area, country kept | Real IP again for listed domains |
| Fraud scoring and IVT | Shared exits, PRT samples only | Usual IP reputation applies |
| Frequency capping by IP | Broken across connections | Works as before, cookies permitting |
| First-party sites | Unaffected | Unaffected |
| Analytics on a third-party tag | Shared proxy exits | Real visitor IPs |
Shared exits behaved like carrier addresses behind CGNAT: many people, one address. Systems that already handle CGNAT, as in how websites detect proxies, needed few changes.
Where this leaves your stack
Code for Google’s IP Protection ranges or reveal tokens can leave the roadmap. First-party sites see no change.
Seeing an ad or page as a home user in a chosen city was never IP Protection’s job; nobody could target it. That requirement points to rotating residential proxies with city targeting, used where the target allows automated access. The wider category map is in types of proxies.
Frequently asked questions
Chrome IP Protection was a Privacy Sandbox feature that hid a user's IP address from tracking domains in Incognito mode. It routed third-party requests to domains on the Masked Domain List through two proxies, one run by Google and one by a CDN. Google announced its retirement on October 17, 2025.
Chrome opened a QUIC tunnel to a Google proxy, a second tunnel through it to a CDN proxy, and an end-to-end encrypted connection to the site inside both. The Google proxy saw the user's IP but not the destination, and the CDN proxy saw the destination but not the IP. Blind-signed tokens kept either proxy from linking traffic to a Google account.
No. Google listed IP Protection among the Privacy Sandbox technologies it would retire on October 17, 2025, and archived the project repository on November 3, 2025. The feature switch that gated it no longer appears in Chromium's network feature list at the Chrome 145 source.
No. A VPN carries all device traffic and usually lets the user choose a country. Chrome IP Protection only proxied third-party requests to listed tracking domains in Incognito, and it kept the user's own coarse area.
The Masked Domain List is the public list of third-party domains whose requests Chrome IP Protection proxied. Disconnect.me built it from Google's criteria: ad serving, targeting, measurement, data collection for marketing, or scripts likely used for re-identification. The archived version has 4,335 rows, 223 of them owned by Google.
Only coarsely. The exit address represented an area of at least one million users, labelled with its largest city, and never crossed the user's country border. The user could not pick a different location.
There is no supported way now, because Google announced the feature's retirement in October 2025. During testing it worked only in Incognito, only for users signed in to Chrome before opening the Incognito window, and only in certain regions. Users could switch it off, and enterprise-managed Chrome had it off by default.
Researched and drafted with AI tools, then checked against our publishing rules before it went live: 8 outside links, 5 links to other proxymint pages, no prices and a fact-check pass against our product records. How we write.