The Last Persistent Identifier on the Web
Over the past decade, the advertising and tracking industry has progressively lost access to its most powerful identification tools. Third-party cookies — the dominant mechanism for cross-site tracking — are being phased out. Device fingerprinting is increasingly blocked by privacy-focused browsers. Browser storage partitioning prevents trackers from correlating visits across domains using cached data.
But one identifier has persisted through all of these changes: your IP address. Unlike cookies, an IP address cannot be deleted. Unlike device fingerprints, it requires no JavaScript to read. Unlike storage mechanisms, it is present in every single network request your browser makes, in every HTTP access log on every server you contact, visible to every third-party resource loaded on every page you visit.
Google's Privacy Sandbox IP Protection proposal aims to address this. It is not a VPN. It is not a simple proxy. It is an architectural change to how Chrome routes requests to third-party origins — one that could have significant implications for advertising infrastructure, fraud prevention, security tools, and web analytics at a global scale.
What Is Privacy Sandbox IP Protection?
IP Protection is one component within Google's broader Privacy Sandbox initiative, a collection of browser features and web standards proposals designed to eliminate cross-site tracking mechanisms while preserving some advertising functionality through privacy-preserving alternatives.
The specific IP Protection mechanism works by intercepting Chrome's requests to third-party origins that appear on a Google-maintained blocklist of known tracking domains. When you visit a page and your browser would normally load a tracking pixel, analytics script, or ad from a domain on this list, Chrome routes the request through a two-hop proxy chain rather than connecting directly to the third-party server.
The third-party server receives the request, but instead of seeing your home IP address, it sees the IP address of the second proxy node in the chain. Your real IP is visible only to Google's first-hop proxy — and even Google's proxy only sees that you are connecting to a second-hop proxy, not which third-party domain you are ultimately reaching. This separation of knowledge between the two proxies is the core privacy property of the design.
The Two-Hop Proxy Architecture
The architecture is explicitly designed to prevent any single entity from knowing both your identity and your browsing destination simultaneously. This is sometimes called a blind proxy or two-party compute model, and it is similar in principle to Apple's iCloud Private Relay:
- First hop — Google Proxy: Your Chrome browser sends the request to a Google-operated proxy. Google knows your real IP address (because you connect to their proxy) but does not know the destination URL (because the request is encrypted end-to-end before being handed off). Google authenticates you as a Chrome user but learns nothing about which third-party you are contacting.
- Second hop — Third-Party Proxy (e.g., Cloudflare): Google's proxy forwards the encrypted request to a second proxy operated by a different company. This second proxy knows the destination domain (because it must forward the request) but does not know your real IP (because it only receives the connection from Google's proxy, not from your device). The second proxy forwards the request to the actual third-party server, which sees the second proxy's IP address.
The result: the destination third-party server sees only a proxy IP, not your home IP. Google knows who you are but not where your request went. The second proxy knows where the request went but not who made it. No single entity has both pieces of information simultaneously.
HTTP stack placement: CONNECT, TLS origins, and limits
IP Protection applies to selected HTTP(S) fetches initiated by Chrome’s networking stack. It is not a generic OS TUN interface: other applications and protocols (games, WebRTC, QUIC to non-proxied endpoints) follow their own paths. Enterprise deployments should inventory dependencies on client source IP for APIs and allow-lists, then pilot managed policies before wide rollout.
What IP Protection Covers and What It Does Not
| Traffic Type | IP Protection Applied? | Notes |
|---|---|---|
| Third-party requests to tracked domains | Yes | Based on Google's blocklist of known trackers |
| First-party site requests (the site you're visiting) | No | Direct connection; first-party sees your real IP |
| HTTPS requests to non-listed third parties | No | Only domains on Google's tracker blocklist are affected |
| DNS queries | Partially | DNS for proxied requests handled by proxy; others direct |
| WebRTC connections | No (separate issue) | WebRTC can still leak real IP; requires separate mitigation |
| Requests from non-Chrome browsers | No | IP Protection is Chrome-specific |
| Enterprise/managed Chrome deployments | Configurable | Enterprise policies will be able to disable IP Protection |
Comparison: IP Protection vs. Existing Privacy Tools
| Feature | IP Protection (Chrome) | Apple Private Relay | VPN | Tor |
|---|---|---|---|---|
| Scope | Selected third-party tracking requests | All iCloud Safari traffic | All device traffic | All traffic through Tor Browser |
| Number of hops | 2 | 2 | 1 | 3+ |
| Who knows your IP | Google (first hop) | Apple (first hop) | VPN provider | Entry node only |
| First-party site sees real IP? | Yes | No (all traffic hidden) | No | No |
| Performance impact | Minimal (selected requests) | Moderate | Moderate to significant | Significant |
| Cost to user | Free (built into Chrome) | Requires iCloud+ subscription | Paid service typically | Free |
| Ad industry impact | High (targets tracking specifically) | High | Variable | Negligible (small user base) |
Real-World Implications
For digital advertising: IP-based audience segmentation — where advertisers target users based on geographic location, ISP, or behavioral profiles built from cross-site IP tracking — becomes significantly less accurate. First-party data (data collected directly by the site you are visiting) becomes even more valuable as third-party tracking loses IP resolution. This accelerates the industry's already-ongoing shift toward first-party data strategies.
For fraud prevention and security: Many fraud detection systems, bot detection platforms, and abuse prevention tools use IP addresses as a primary signal. A request arriving from a proxy IP rather than a residential IP looks different in fraud models. Google has indicated it will provide mechanisms for certain security and fraud prevention use cases to obtain signals without full IP disclosure, but the specific implementation details continue to evolve.
For network analytics and logging: Web server access logs will show proxy IPs instead of user IPs for proxied requests. This affects server-side analytics, rate limiting based on source IP, geographic access controls, and any security tool that uses IP addresses to correlate requests. Infrastructure teams will need to update logging pipelines and security rules to account for this change.
For enterprise network security: Many corporate security tools monitor outbound connections by source IP to enforce content policy and detect compromised devices. If Chrome routes some traffic through Google's proxies, this breaks the assumption that all traffic from a company-owned device originates from the device's assigned IP. Enterprise Chrome policy controls will be able to disable IP Protection on managed devices.
Common Misconceptions
Misconception 1: IP Protection Makes You Anonymous
IP Protection hides your IP from selected third-party trackers. The sites you are actually visiting — the first-party domains — still see your real IP address. You are not anonymous. Google knows your IP at the first-hop proxy. Your ISP can still see your traffic. IP Protection addresses a specific cross-site tracking mechanism; it is not a general anonymization tool.
Misconception 2: IP Protection Covers All Your Web Traffic
Only requests to domains on Google's tracker blocklist are proxied. The blocklist will be maintained by Google and will likely cover major ad networks and analytics platforms, but it will not cover every third-party resource on the web. First-party requests, requests to non-listed third parties, and non-Chrome browser traffic are unaffected.
Misconception 3: This Is a Net-Positive Privacy Change for Everyone
Privacy advocates generally support IP masking, but the implementation concentrates significant routing intelligence at Google — the company with the most comprehensive advertising data in the world. Google's first-hop proxy sees every user's real IP for every proxied request, creating a centralized record of which Google Chrome users are making privacy-related requests. Critics argue this is a privacy improvement for users relative to arbitrary third-party trackers, but a consolidation of data at Google.
Misconception 4: WebRTC IP Leaks Are Fixed by IP Protection
WebRTC connections — used by video calls, voice apps, and some streaming services — bypass HTTP proxies entirely and can expose your real IP address regardless of proxy settings. IP Protection does not address WebRTC IP leaks. Users who need to hide their IP from WebRTC-enabled services need a VPN or a browser with explicit WebRTC leak prevention, not just IP Protection.
Pro Tips
- Do not rely on IP Protection as a replacement for a VPN: IP Protection only covers third-party tracking requests in Chrome. A full VPN encrypts all traffic from all applications on your device, including non-Chrome browsers, native apps, and background services. For genuine IP privacy across your entire device, a VPN remains the appropriate tool.
- Enterprise IT teams should prepare Chrome policy configurations now: IP Protection will be rollable via Chrome enterprise policies. Define your organization's policy before the feature becomes default-on so that security monitoring tools dependent on source IP correlation are not unexpectedly broken.
- Update fraud prevention rules to account for proxy IP ranges: If your application uses IP reputation or geolocation for fraud detection, prepare for a portion of legitimate traffic to arrive from Google proxy IP ranges. Review your detection logic to avoid false-positives that would incorrectly flag legitimate Chrome users as suspicious.
- First-party data becomes more valuable, not less: IP Protection specifically targets cross-site tracking. First-party engagement data — actions users take on your own domain — is unaffected. If your analytics rely on cross-site IP correlation, now is the time to migrate toward first-party event tracking.
- Monitor Google's Privacy Sandbox developer blog for implementation updates: The specific domains on the blocklist, the exact proxy architecture, and the enterprise controls are all subject to change as the feature moves from proposal to deployment. Subscribe to chromium.org development updates to track the current implementation status.
- Test your security logging pipeline with proxied IP scenarios: Simulate what your server-side logs and security tools will see when proxied requests arrive from Google proxy IPs rather than residential IPs. Identify which alerting rules, rate limits, or geo-blocks will need adjustment before the feature affects real traffic.
IP Protection represents a significant architectural shift in how Chrome handles privacy — one that will require adaptation from advertising platforms, fraud prevention systems, and enterprise security tools alike. Understanding the two-hop proxy model and its specific scope is the first step to preparing intelligently for the change. Check what your browser reveals about your IP right now.