Chrome Data Compression Proxy for Network Administrators, Carriers, and ISPs
This document provides technical background for network administrators on the Chrome Data Compression Proxy for Android (henceforth referred to as DCP). It also describes mechanisms that the DCP provides to allow network administrators to restrict access to the proxy for specific users and URLs.
Enabling the Data Saver feature in Chrome establishes a connection between the browser and Google's servers to proxy HTTP requests. Pages loaded in Incognito tabs are never proxied or optimized. In the vast majority of cases, HTTPS traffic is not affected by Data Saver. On extremely slow page loads, Chrome will redirect to a Google-hosted domain which serves a transcoded version of the page to save data and load faster. This is only used on very slow page loads, or when the page might fail to load at all.
When possible, the proxy connection is encrypted using SSL. In certain cases, as described below, the proxy connection may use unencrypted HTTP/1.1.
Requests made by the DCP on behalf of users will carry the header
Via: 1.1 Chrome-Compression-Proxy. The DCP also acts as an
HTTP-compliant proxy cache. It respects
Cache-Control: no-transform which informs the DCP not to
transcode a given resource.
Identifying the Client IP Address
Because requests to destination websites are sent from Google's
servers, the IP address of the client making the connection will reflect
the location of Google's servers, not the user. The DCP sends the IP
address of the client in the
X-Forwarded-For header with each
request, for example:
Websites should use the
X-Forwarded-For header to determine the IP
address of the client for the purpose of IP geolocation.
By default, the connection between the browser and the proxy is over
an encrypted channel. A network administrator can restrict the use
of encryption for a specific user by blocking access to a canary URL
http://check.googlezip.net/connect) and returning a response
other than a status code 200 with a response body of
As described below, Chrome issues an in-the-clear request to this URL
prior to connecting to the DCP. The canary URL is only used for this
purpose and does not serve any other content.
Because downgrading to HTTP does not allow the DCP to use HTTP/2 and other protocol-level enhancements, this will incur a performance penalty for the user.
It is preferable to send an immediate response for the canary URL, rather than inducing a DNS or connection timeout, which will not disable use of the DCP.
When Chrome starts with the DCP setting enabled, the DCP is
enabled by the user, or a network interface change occurs, Chrome
asynchronously issues an in-the-clear HTTP request to the canary URL,
There are three possible outcomes of the canary URL request:
- If the response status code is 200 and the response body is
OK, Chrome uses an encrypted proxy connection for subsequent HTTP requests.
- If the response status code is anything other than 200 or the response
body is anything other than
OK, Chrome uses an unencrypted proxy connection.
- If the canary URL request times out or a DNS error occurs, Chrome uses an encrypted proxy connection.
The Chrome DCP issues a proxy bypass response for URLs matching a list of restricted URLs maintained by Google. A proxy bypass causes Chrome to disable the use of SSL for the DCP connection for a short time (randomly chosen between 1 and 5 minutes). Carriers or network administrators can then block or take appropriate action on the request.
Proxy Bypass is used mainly for:
- Child sexual abuse material, which includes NCMEC, IWF and other lists used globally by Google for restricting access to such illegal material
- URLs subject to court-ordered DMCA and other takedowns on Google services
- Country-specific takedown lists, which are applied only to users with IP addresses originating in the associated country
- A small number of other sites known not to work well with the DCP (e.g., known carrier billing portal and intranet sites)