Wiki · Concept · Last reviewed June 25, 2026

IP Protection

IP Protection was a Chrome Privacy Sandbox proposal for masking a user's original IP address on qualifying third-party requests in Incognito mode through a two-hop proxy system.

Category: Concept Updated: June 25, 2026 Tags: browser privacy, IP addresses, proxies, Incognito mode, surveillance

Definition

IP Protection was a Chrome Privacy Sandbox proposal for limiting the availability of a user's original IP address in third-party contexts. Google described IP addresses as necessary for routing, fraud prevention, and spam prevention, but also as strong tracking signals: cheap to collect, relatively stable, and useful when combined with other identifiers.

Its 2025 scope was Incognito mode. Google's public overview said IP Protection would mask qualifying third-party traffic for domains on the Masked Domain List, replacing the user's original address with an IP address representing coarse geolocation. The archived GitHub explainer described a list-based approach for third-party Incognito contexts, not a general VPN, first-party anonymity layer, or universal browser privacy shield.

Google announced on October 17, 2025 that IP Protection would be retired, and the Privacy Sandbox status page lists IP Protection under discontinued Chrome features. The GitHub repository was archived on November 3, 2025. Treat it as a discontinued design, not an available privacy guarantee.

Mechanism

The core design was a two-hop proxy. Google's overview said the first proxy, operated by Google, would see the user's IP address and a request to connect to the second proxy, but not the destination. The second proxy, operated by an external CDN, would see the destination domain, but not the user's original IP address. The claim was separation: no single proxy should see both the original IP address and the origin being visited.

The proposal also used HTTPS between the client and each proxy, blind signatures so proxy traffic could not be linked to a user's account, and coarse geolocation so sites could still perform some localization, legal compliance, performance tuning, and geographic advertising. The archived explainer named CONNECT and CONNECT-UDP over MASQUE as forwarding mechanisms for proxied traffic.

Scope mattered as much as the proxy. The feature applied only to qualifying traffic in a third-party context and only for domains on the Masked Domain List. First-party requests were outside scope even if the domain also appeared on the list. A June 2025 blink-dev intent proposed a one percent stable experiment for North American Incognito users and explicitly did not propose WebView support.

Agent Context

For AI Browsers and Computer Use, IP Protection is a useful boundary case. A browser agent may rely on network reputation, geolocation, anti-fraud checks, bot defenses, rate limits, or regional content. If a browser masks the original IP address on third-party requests, the agent's visible page state may not explain why a resource was allowed, blocked, localized, or challenged.

Agent logs should distinguish user location, browser-reported coarse geolocation, proxy egress range, and site-side inference. A failed payment widget, fraud prompt, media block, or localized ad may reflect IP masking rather than user intent or account risk. If the API is unavailable or discontinued, the record should say so rather than assuming proxy behavior.

Governance Use

A review record should name the browser version, mode, region, sign-in precondition, top-level site, requested third-party domain, Masked Domain List status, first-party or third-party context, proxy egress country, geofeed, enterprise policy, and fallback. It should also record whether the affected system uses IP address for routing, localization, fraud prevention, abuse response, ad targeting, or access control.

The topic belongs beside Data Minimization, Private State Tokens, Web Bot Auth, Attribution Reporting API, Topics API, and Real-Time Bidding. It separates network-level address exposure from trust tokens, bot labels, ad measurement, interest signals, and auction markets.

Limits

IP Protection was not consent, account privacy, device anonymity, or a general guarantee that a site cannot identify a person. It targeted one signal in one context: original IP address exposure to listed third-party domains in Incognito mode. A service could still use cookies, logged-in accounts, fingerprinting defenses, payment data, device signals, timing, or first-party records.

The proposal also exposed a hard governance tradeoff. IP addresses are surveillance signals, but they are also operational signals for fraud, abuse, geolocation, performance, sanctions screening, and incident response. Masking them shifts power from sites toward browser and proxy operators, and it makes the Masked Domain List and geofeed into policy surfaces. The discontinuation shows that infrastructure privacy tools can fail even after careful narrowing.

Review Record

Source Discipline

Claims about the two-hop proxy, Masked Domain List, third-party-context scope, coarse geolocation, and blind signatures should cite Google Privacy Sandbox and the archived GitHub explainer. Claims about experiment scope should cite the June 2025 blink-dev intent. Claims about discontinuation should cite the October 17, 2025 Privacy Sandbox update and the feature status page, not old implementation plans alone.

Spiralist Reading

Spiralism reads IP Protection as a lesson in routed visibility. The web cannot work without addresses, but addressability becomes memory when institutions keep and combine it. A proxy can reduce exposure, yet it also asks users to trust a new path: browser vendor, proxy operator, domain list, geofeed, and policy switch. The serious question is not whether the original IP address disappears from one request. It is who now sees enough to govern the route.

Sources

Return to Wiki