This document describes the features in Chrome that communicate with Google or third-party services (for example, if you've changed your default search engine), and describes the controls available to you regarding how your data is used by Chrome. Here we’re focusing on the desktop version of Chrome, and touch only tangentially on Chrome OS and Chrome Mobile. This document does not cover features that are still under development, such as features in the beta, dev and canary channel and active field trials.
If you have questions about Google Chrome and Privacy that this document doesn’t answer, please contact the privacy team at email@example.com. We’d be happy to hear from you.
Google Chrome uses a combined web address and search bar (we call it the “omnibox”) at the top of the browser window.
When you type in the omnibox, your default search engine can predict websites and searches that are likely completions of what you have entered so far. These predictions make searching faster and easier.
In order to provide the predictions, Chrome sends the text that you have typed into the omnibox to your default search engine (you can configure your default search engine in Chrome's settings). Your IP address and certain cookies are also sent to your default search engine with the request in order to deliver results most relevant to you.
If Google is set as your default search engine, partial query data is retained for two weeks, after which a randomly selected, anonymized 2% sample of the partial query data is retained in order to help improve the prediction feature. Chrome will also send a general classification of what you typed into the omnibox, such "URL", "search query", or "unknown".
If you select one of the suggested queries, Chrome will send your original search query, the suggestion you selected, and the position of the suggestion back to Google. This information helps improve the quality of our suggestion engine, and is logged and anonymized in the same manner as Google web searches.
Omnibox predictions are on by default, and can be disabled byunchecking the box in the “Privacy” section of Google Chrome's settings.
Chrome attempts to speed up navigation by prerendering pages you're likely to navigate to. To do so, Chrome uses a variety of local heuristics, described in detail in the prerendering whitepaper. These network predictions can be disabled by unchecking the box in the "Privacy" section in Chrome’s settings.
If you choose to sync your Chrome history, it can be used to improve predictions. To do so, both the URL of the page you're currently visiting, as well as the page Chrome predicts you'll visit next, are sent to Google.
Google search locale
If Google is set as your default search engine, Chrome will try to determine the most appropriate locale for Google search queries conducted from the omnibox in order to give you relevant search results based on your location. For example, if you were in Germany, your omnibox searches may go through google.de instead of google.com.
In order to do this, Chrome will send a request to google.com each time you start the browser. If you already have any cookies from the google.com domain, this request will also include these cookies, and is logged as any normal HTTPS request to google.com would be (see the description of “server logs” in the Privacy FAQ for details). If you do not have any cookies from google.com, this request will not create any.
Search Integration on the New Tab Page
When you open a new tab, Chrome loads a new tab page from your default search engine (e.g., google.com). This page is preloaded in the background and refreshed periodically so that it opens quickly. Your IP address and cookies are sent to your search engine with each refresh request, as well as your current browser theme, so that the new tab page can be correctly displayed. See the embedded search API for more details.
If you have an extension installed that overrides the New Tab Page, this functionality may not be available.
Phishing and malware protection
Google Chrome includes a feature called Safe Browsing to help protect you against phishing and malware attacks. This helps prevent evil-doers from tricking you into sharing personal information with them (“phishing”) or installing malicious software on your computer (“malware”). The approach used to accomplish this was designed specifically to protect your privacy and is also used by other popular browsers.
Safe Browsing checks URLs against a list of known-bad websites that is maintained locally on your computer and updated regularly. If you navigate to a URL that matches against the local known bad-list, Chrome sends a partial URL fingerprint (the first 32 bits of a SHA-256 hash of the URL) to Google for verification that the URL is indeed dangerous. Chrome also contains some client-side logic that can detect bad behavior on sites that don’t appear on the Safe Browsing list. If a site looks suspicious, Chrome will query Google with the full URL for further information. You may or may not get a warning depending on the combination of client-side checks and additional information available from Google's server-side data. You can see how this warning might look by visiting our test page: http://malware.testing.google.test/testing/malware/
If you do get a malware warning, you can opt-in to send additional data to Google that helps us improve the Safe Browsing service. If you opt-in, Chrome will send a report containing the full URL and contents of the website, as well as the URL of the page which directed you to that site. While opted-in, this data will be sent every time you receive a malware warning in order to verify whether the site is still serving content that may exploit users. This data is sent over SSL, and does not include data from sites you visit in Incognito mode, nor data originally sent over HTTPS.
To protect against malicious binaries, Safe Browsing also checks the URL of executable files that you download against a list of known-good URLs maintained locally on your computer and updated regularly. Chrome trusts executables that match URLs in the whitelist, and also those downloaded from the local network, or signed by a trusted authority. Executables that don’t fall into one of these buckets are considered untrusted. In this case Chrome sends the downloaded URL, a hash of the downloaded file, the IP of the download server, and the referer URL to Google for further verification. You may choose to also send unknown or suspicious downloaded files to Google to help us improve malware detection.
For all Safe Browsing requests, the transferred data is logged in its raw form for up to two weeks. After at most two weeks, Safe Browsing will delete the raw logs, storing only calculated data in an anonymized form which does not include your IP addresses or cookies. Additionally, Safe Browsing requests don’t use your user profile, and won’t be attached to your Google Account. They are however, tied to the other SafeBrowsing requests made from the same device.
You can disable phishing and malware protection by unchecking the box in the "Privacy" section of Google Chrome's options. Please be aware that Chrome will no longer be able to protect you from websites that try to steal your information or install harmful software if you disable this feature. We really don’t recommend turning it off.
Navigation error tips
Google Chrome can show tips to help guide you to the page you were trying to reach in cases where the web address cannot be found, a connection cannot be made, the server returns a very short (under 512 byte) error message, or you've navigated to a parked domain.
Google Chrome will first check the address against a locally-stored list of suspected parked domains. If there is a match, Chrome sends a partial fingerprint (a hash prefix) of the URL to Google for verification that the domain is indeed parked. This uses the same methodology as the Safe Browsing service (see the “Phishing and malware protection” section, above).
In the case of other navigation errors, the URL of the web page you're trying to reach is stripped of all GET parameters, and then sent to Google in order to retrieve navigation tips. This information is logged and anonymized in the same manner as Google web searches. The logs are used to ensure and improve the quality of the feature.
Additionally, to provide you with more informative error messages when a domain name cannot be found, Chrome will investigate the underlying cause by attempting to resolve a fixed hostname (“google.com”) using both Google Public DNS and the default DNS service configured for your system.
In the event that Chrome detects SSL connection timeouts, certificate errors, or other network issues that might be caused by a captive portal (a hotel's WiFi network, for instance), Chrome will make a cookieless request to http://www.gstatic.com/generate_204 and check the response code. If that request is redirected, Chrome will open the redirect target in a new tab on the assumption that it's a login page. Requests to the captive portal detection page are not logged.
You can disable navigation error tips by unchecking the box in the "Privacy" section of Google Chrome's options.
Google Chrome and the Chrome Apps Launcher use Google Update to keep you up to date with thelatest and most secure versions of software. In order to provide greater transparency and to make the technology available to other applications, the Google Update technology is open source.
Google Update requests include information that help us understand how many people are using Google Chrome and the Chrome Apps Launcher, specifically, whether the software was used in the last day, the number of days since the last time it was used, the total number of days that it has been installed, and the number of active profiles. Google Update also periodically sends a non-unique four-letter tag to Google which contains information about how you obtained Google Chrome. This tag is not personally identifiable, does not encode any information about when you obtained Google Chrome, and is shared with everyone who obtained Google Chrome the same way.
Since Chrome OS updates the entire OS stack, Google Update on that platform will additionally send the current Chrome OS version and hardware model information in order to ensure that the correct update is delivered. This information is not personally identifiable, and is common to all users of Chrome OS on the same revision of device.
A similar system is in place to keep extensions and applications that you’ve installed up to date. These requests include similar information (the application id, when the application was last used, and how long it’s been installed). We use these update requests to determine the aggregate popularity and usage of applications and extensions. For security reasons, Chrome will occasionally send a cookieless request to the Chrome Web Store to verify that installed extensions and applications that claim to be from the store are genuine.
In order to keep updates as small as possible, Google Chrome is internally split into a variety of components, each of which is independently updateable. Each component is uniquely identified via an ID that is shared among all Google Chrome installations (for example “fmeadaodfnidclnjhlkdgjkolmhmfofk”). Requests for component updates contain these IDs and the components’ versions -- as every installation uses the same ID, these are not personally identifiable.
In order to measure the success rate of Google Chrome downloads and installations, a randomly-generated token is included with Google Chrome's installer. This token is sent to Google during the installation process to confirm the success of that particular installation. It is generated for every install, is not associated with any personal information, and is deleted once Google Chrome runs and checks for updates the first time.
Promotional tags and tokens
Installations of Google Chrome on Windows and Mac OS X, Android, and iOS that are installed or reactivated via a promotional campaign send a non-unique promotional tag that contains information about how Chrome was obtained, the week when Chrome was installed, and the week when the first search was performed. The tag looks similar to “1T4ADBR_enUS236US239”, and the article “How To Read An RLZ String” makes it clear exactly what information is being passed along. This non-unique tag is included when performing searches via Google (the tag appears as a parameter beginning with "rlz=" when triggered from the Omnibox, or as an “x-rlz-string” HTTP header). We use this information to measure the searches and Chrome usage driven by a particular promotion.
For Chrome OS, a non-unique promotional tag is sent, which indicates the type of device you are using rather than a promotional campaign.
For users who choose to automatically send usage statistics and crash reports, the RLZ string is sent along with the report. This allows us to improve Chrome based on variations that are limited to specific geographic regions.
Installations of Google Chrome received or reactivated via promotional campaigns also send a token when you first launch Chrome and when you first search from Google. The same token will be sent if Chrome is later reinstalled and is only sent at first launch and at first use of the Omnibox after reinstallation or reactivation. Rather than storing the token on the computer, it is generated when necessary by using built-in system information that is scrambled in an irreversible manner. This generated machine identifier does not exist in Chrome OS.
Google Chrome uses a software library called "RLZ" to generate and send this information. The RLZ library was fully open-sourced in June 2010. For more information, please see the In the Open, for RLZ post on the Chromium blog.
For the desktop version of Chrome, you can opt-out of sending this information to Google by uninstalling Chrome, and installing a version downloaded directly fromwww.google.com/chrome. To opt-out of sending the RLZ string in Chrome OS, press Ctrl + Alt + T to open the crosh shell, type rlz disable followed by the enter key, and then reboot your device.
Usage statistics and crash reports
You can choose to automatically send usage statistics and crash reports to Google in order to help improve Chrome’s feature set and stability.
Usage statistics contain aggregated information such as preferences, user interface feature usage, responsiveness, and memory usage. These statistics do not include any personal information. Crash reports contain system information at the time of the crash, and may contain web page URLs or personal information depending on what was happening at the time of the crash.
If you enable this feature, Google Chrome stores a randomly generated unique token, which is sent to Google along with your usage statistics and crash reports. This token does not contain any personal information and is used to de-duplicate reports and maintain accuracy in statistics.
This feature is enabled by default on Chrome OS and the beta channel of Chrome for Android, and disabled by default on Windows, Mac OS X, Linux, Android, and iOS. You can enable or disable the feature in the "Privacy" section of Google Chrome's settings.
Suggestions for spelling errors
Google Chrome can provide smarter spell-checking by sending text you type into the browser to Google's servers, allowing you to use the same spell-checking technology used by Google products, such as Docs. If the feature is enabled, Chrome will send the entire contents of text fields as you type in them to Google along with the browser’s default language. Google returns a list of suggested spellings, which will be displayed in the context menu. Cookies are not sent along with these requests. Requests are logged temporarily and anonymously for debugging and quality improvement purposes.
This feature is disabled by default, and can be enabled via the “Ask Google for suggestions” context menu that appears after right-clicking on misspelled words. When disabled, spelling suggestions are generated locally without sending data to Google's servers.
Google Chrome’s built-in translation feature helps you read more of the Web, regardless of the language of the web page. The feature is enabled by default.
Automatic translation can be disabled at any time in Chrome’s settings in the “Languages” section.
Language detection is done entirely using a client-side library, and does not involve any Google servers. For translation, the contents of a web page are only sent to Google if you explicitly decide to translate it by clicking “Translate” on the bar, or if you’ve previously chosen “Always translate” for a given language via the translate bar Options menu.
Sign In to Chrome
Google Chrome provides the option to sign in via your Google Account and synchronize your browsing history and settings (such as your open tabs, bookmarks, themes, extensions, and some application data) to make them available across multiple devices. This allows Google and Chrome to bring you a consistent experience across Google services.
The feature can be enabled or disabled at any time in the “Sign In” section of Chrome’s settings. Signing into Chrome and logging into Chrome OS will automatically log you into the associated Google Account, and allow you to choose which data types get synchronized and which don’t. For example, you could choose extensions and bookmarks, but not themes.
By default, passwords are encrypted locally with a key tied to your Google Account before being sent to Google’s servers for storage and distribution. You may optionally choose to encrypt all synchronized data with a distinct sync passphrase via the “Advanced Sync Options” button in Chrome Settings instead. If you choose this option, it’s important to note that Google won’t have access to the sync passphrase you set; we won’t be able to help you recover data if you forget it. Regardless of what data you choose to encrypt, all data is always sent over secure SSL connections to Google’s servers.
Google Chrome has a form autofill feature that helps you fill out forms on the web more quickly. Autofill is enabled by default, but can be disabled at any time in Chrome’s settings.
If Autofill is enabled, and you encounter a web page containing a form, Chrome will send some information about that form to Google. This information includes a hash of the web page’s hostname together with form identifiers such as field names, the basic structure of the form, and Chrome’s guess at each field’s data type (that is, “field X looks like a phone number, and field Y looks like a country”). This is necessary to help Chrome match up your locally stored Autofill data with the contents of the form, and to improve the quality of form filling over time.
If Autofill is enabled, and you submit a form, Chrome sends the data types you actually used for filling in the form in order to improve its guesses over time. The actual text you typed into the form is not sent.
You can manage your Autofill entries via Chrome’s settings, and edit or delete saved information at any time. Chrome will never store credit card information without explicitly asking you and getting confirmation first.
Also, if you choose, you can bring your Autofill data with you to all your Chrome enabled devices by syncing it as part of your browser settings (see the “Sign In to Chrome” section in this document). If you choose to sync Autofill information, the field values will be sent as described in “Sign In to Chrome”; otherwise, the field’s values are not sent.
Google Chrome supports the Geolocation API, which provides access to fine-grained user location information with your consent.
By default, Chrome will request your permission when a web page asks for your location information, and does not send any location information to the web page unless you explicitly consent.
Furthermore, whenever you are on a web page which is using your location information, Chrome will display a location icon on the right side of the omnibox. You can click on this icon in order to find out more information or manage location settings.
In Chrome’s settings, by clicking “Show advanced settings.”, then clicking “Content Settings” and scrolling to the “Location” section, you can choose to allow all sites to receive your location information, have Chrome ask you every time (the default), or block all sites from receiving your location information. You can also configure exceptions for specific web sites.
In Chrome for Android, if Google is set as your default search engine and you have permitted Google Apps to use your geolocation in Android OS's settings, omnibox searches in Chrome for Android will automatically send your location to Google.
If you do choose to share your location with a web site, Chrome will send local network information to Google (also used by other browsers such as Mozilla Firefox) in order to estimate your location. This local network information can include data about nearby Wi-Fi access points or cellular signal sites/towers (even if you’re not using them), and your computer’s IP address. The requests are logged, and aggregated and anonymized before being used to operate, support, and improve the overall quality of Google Chrome and Google Location Services.
For further reading on the privacy and user interface implications of the Geolocation API (as well as other HTML5 APIs), see ”Practical Privacy Concerns in a Real World Browser” written by two Google Chrome team members.
Speech to Text
Chrome supports three mechanisms for converting speech to text: input elements that contain an x-webkit-speech attribute, the experimental speechInput extension API, and the Web Speech API. All of these mechanisms use Google’s servers to perform the conversion. Using the feature sends an audio recording to Google (audio data is not sent directly to the page itself), along with your default browser language and the language settings of the page that triggered the query. Cookies are not sent along with these requests.
If you have opted-in to sending usage statistics, Chrome will send some additional information to help find and fix problems with the service, including the URL of the website using the API, your operating system, and the manufacturer and model of your computer and audio hardware.
No cookies are sent along with these requests.
Google Cloud Print
The Google Cloud Print feature allows you to print documents from your browser over the Internet. You do not need a direct connection between the machine that executes Chrome and your printer.
If you choose to print a web page via Cloud Print, Chrome will generate a PDF of this website and upload it over an encrypted network connection to Google’s servers. If you choose to print other kinds of documents, they may be uploaded as raw documents to Google’s servers.
A print job will be downloaded by either a Chrome browser (“Connector”) or a Cloud Print capable printer that you selected when printing the website. In some cases the print job must be submitted to a third-party service to print (HP’s ePrint, for example).
The print job is deleted from Google’s servers when any of three criteria is met:
- You delete the print job
- The job has been printed and marked as printed by the printer/connector
- The job has been queued on Google’s servers for 30 days
You can manage your printers and print jobs on the Google Cloud Print website.
SSL certificate error reporting
Chrome contains a list of expected SSL certificate information for a variety of high-value websites in an effort to prevent man-in-the-middle attacks. For Google websites in particular, Chrome will alert Google to a possible attack by sending information about the SSL certificate chain to our security team if the certificate provided by the web server doesn’t match the expected signature.
TLS Channel IDs
Chrome is testing an implementation of a new security feature called "TLS Channel ID" which will allow a server to assert in a strong way that new HTTPS sessions originate from the same client as a previous session. This assertion mitigates the risk of session theft, among other advantages, as cookies can be cryptographically tied to a particular Channel ID. In this scenario, stolen cookies will be significantly more difficult to convert into stolen sessions.
Channel IDs do not contain any information about the user, and a different Channel ID will be created for each requesting server. Channel IDs are not shared between Chrome profiles, and any Channel ID created during Incognito browsing will be destroyed when exiting the Incognito session.
You can determine which Channel IDs have been created (and remove unwanted IDs) by visiting the Cookies and Site Data dialog (available at chrome://settings/cookies). Channel IDs are also subject to removal when "Cookies and Site Data" are cleared via the "Clear Browsing Data" dialog (chrome://settings/clearBrowserData).
For more technical details and background information, visit browserauth.net and the work-in-progress IETF draft.
Installed Applications and Extensions
Installing an application or extension from the Chrome Web Store directly or via an inline installation flow on a third-party site involves a request to the Chrome Web Store for details about the application. This request includes cookies, and if you’re logged into Google when you install an application, that installation is recorded as part of your Google account. The store uses this information to recommend applications to you in the future, and in aggregate to evaluate application popularity and usage. As noted above, applications and extensions are updated via Google Update.
Applications installed in Chrome may send notifications ("You've got mail!") if you allow them to. The notification’s text is sent over a secure channel from the developer to Google, and then from Google to you. Google servers handle the notifications as plain text, and retain up to 7 days of notifications per application in order to ensure delivery to users.
If you opt-in to notifications for an application, Chrome provides the application with an ID token which can be used to send you information. A unique token is generated for each application that uses notifications for a given user.
Notifications use Google’s synchronization servers as their delivery mechanism, and therefore can only be delivered to users who are signed into Chrome, and who have opted-in to synchronization.
Continue where I left off
If you have selected the option to “Continue where I left off” in Chrome settings, then when opening Chrome, the browser will attempt to bring you right back to the way things were when the browser was closed. Chrome will reload the tabs you had open, and persist session information to get you up and running as quickly as possible. This has the practical impact of extending the concept of a browsing session across restarts. In this mode, session cookies are no longer deleted when the browser closes, but remain available on restart to keep you logged into your favorite sites.
By default, this feature is enabled for Chrome OS users. Users on all platforms can enable or disable the feature by selecting the “Continue where I left off” setting under “On Startup”.
We want to build features that users want, so a subset of users may get a sneak peek at new functionality being tested before it’s launched to the world at large. A list of field trials that are currently active on your installation of Chrome will be included in all requests sent to Google. This Chrome-Variations header (X-Client-Data) will not contain any personally identifiable information, and will strictly describe the state of the installation of Chrome itself.
The variations active for a given installation are determined by a seed number between 0 and 7999 (13 bits of entropy) which is randomly selected on first run. If you would like to reset your variations seed, run Chrome with the command line flag “--reset-variation-state”.
Do Not Track
If you enable the “Do Not Track” preference in Chrome’s settings, Chrome will send a DNT:1 HTTP header with your outgoing HTTP, HTTPS and SPDY browsing traffic. The header will not be sent with system traffic such as the geolocation, metrics or device management services.
The effect depends on whether a website responds to the request, and how the request is interpreted. For example, some websites may respond to this request by showing you ads that aren't based on other websites you've visited. Many websites will still collect and use your browsing data - for example to improve security, to provide content, services, ads and recommendations on their websites, and to generate reporting statistics.
Chrome ships with an Adobe Flash Player implementation that is based on the Pepper API. Flash and other Pepper-based plugins may ask you for “Access to your computer”. If you grant this permission, the plugin is granted unsandboxed access. This allows content providers to offer you access to DRM protected content like videos or music but may have security and privacy implications, so consider carefully whether you trust a plugin or website with this privilege.
In order to verify that a user is allowed to access certain types of licensed content, Chrome facilitates a license request when, for example, a movie is loaded into a <video> element. This request contains a request ID which Chrome generates, and which is destroyed as soon as the media element (<video> in our example) is destroyed. The server returns a session ID, which is stored locally, but expected to be unique across browsing sessions.
Chrome will serve license requests to any server, but the data associated with the request is only accessible to that request's target origin. In other words, session IDs behave similarly to other locally stored HTML5 data sources.
In order to give you access to licensed music, the Google Music Manager app can retrieve a device identifier that is derived from your hard drive partitions. The identifier can be reset by reinstalling your operating system.
If a website you visit chooses to use Adobe Flash Access DRM protection, Chrome for Windows and Chrome OS will give Adobe Flash access to a device identifier. You can deny this access in the settings under Content Settings, Protected content. The same applies to the Netflix plugin on Chrome OS.
To receive HD content on Chrome OS, a content provider may ask Chrome to verify the eligibility of the device. To do so, the device will provide a non-permanent machine identifier which will be added in a certificate and passed on to the content provider. You will be prompted to allow or deny this verification check. For more information, please see our help center.
When you sign into a Chrome OS device, Chrome on Android, or a desktop Chrome profile with an account associated with a Google Apps domain, Chrome checks whether or not the domain has configured enterprise policies. If so, the Chrome OS device or Chrome profile is assigned a unique ID, and registered as belonging to that domain. Any configured policies will be applied to the device or profile. In order to revoke the registration, you'll need to wipe the Chrome OS device, sign out of Chrome on Android, or remove the desktop profile.
Registered profiles check for policy changes periodically (every 3 hours by default). In some supported cases, the server will push policy changes to the client without waiting for Chrome's periodic check. Unregistered profiles check whether policy has been turned on for their domain each time Chrome starts up.
The policy list contains details about the types of configuration that can be done via Cloud Policy.
Data Compression (Chrome for Android or iOS)
If you choose to enable "Reduce data usage," Chrome (for Android or iOS) will send your HTTP traffic through Google's optimizing servers in order to reduce the amount of data downloaded and improve overall performance. You can find more information about the data compression benefits in the Chromium blog post.
The proxy service is disabled for connections to HTTPS origins and for connections made from Incognito tabs. These connections will not be routed through Google's servers.
For connections with HTTP origins, request URLs are logged, but request headers and cookies are stripped from the logs. Additionally, the content of proxied pages will be cached according to each page’s cache policy as specified by its headers (Expires, Cache-Control, etc.) but not logged. These logs are not associated with your Google Account, and the entire log entry will be removed within 6 months. Google will use both the request and response data to improve the service; for example, more effective optimizations can be uncovered by analyzing timing data for pages loaded through the proxy service.
Your IP address is forwarded on to the origin HTTP server via an X-Forwarded-For header, in accordance with the HTTP standard. The data compression service is a transparent proxy, and not an anonymization service.
To verify that the compression service is available, Chrome will make an HTTP request to "check.googlezip.net" before routing traffic through the proxy.
If you create a supervised user on Chrome or Chrome OS, certain information such as the supervised user’s browsing activity, profile settings and permissions requests for blocked content will be sent to Google in association with your Google Account. You can access the browsing activity of your supervised users at chrome.com/manage. In order to remove data that is associated with a supervised user from Google’s servers, please sign in to your Google Account at chrome.com/manage and delete the respective supervised user.
Online payments with Google Wallet