This document describes the features in Chrome that communicate with Google, as well as with third-party services (for example, if you've changed your default search engine). This document also describes the controls available to you regarding how your data is used by Chrome. Here we’re focusing on the desktop version of Chrome; we touch only tangentially on Chrome OS and Chrome for 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, or Android apps on ChromeOS if Play Apps are enabled.
If you have questions about Google Chrome and Privacy that this document doesn’t answer, please contact the privacy team at privacy@chromium.org. We’d be happy to hear from you.
Omnibox
Google Chrome uses a combined web address and search bar (we call it the “omnibox”) at the top of the browser window.
As you use the omnibox, your default search engine can suggest addresses and search queries that may be of interest to you. These suggestions make navigation and searching faster and easier, and are turned on by default. They can be turned off by unchecking "Use a prediction service to help complete searches and URLs typed in the address bar or the app launcher search box" in the “Privacy” section of Chrome's settings.
In order to provide these suggestions, Chrome sends the text you've typed into the omnibox, along with a general categorization (e.g., "URL", "search query", or "unknown"), to your default search engine. Your IP address and certain cookies are also sent to your default search engine with the request, in order to return the results that are most relevant to you. If Chrome determines that your typing may contain sensitive information, such as authentication credentials, local file names, or URL data that is normally encrypted, it will not send the typed text.
If you've chosen to sync your Chrome history, and if Google is your default search engine, Chrome may present suggestions as soon as you place the cursor in the omnibox, before you start typing. To do this, Chrome sends the URL of the page you're viewing to Google. URLs are sent only for HTTP pages and Google HTTPS pages.
If Google is your default search engine, logs of these suggestion requests are retained for two weeks, after which 2% of the log data is randomly selected, anonymized, and retained in order to improve the suggestion feature. URLs are not included in this 2% sample.
If you select one of the omnibox suggestions, Chrome sends your original search query, the suggestion you selected, and the position of the suggestion back to Google. This information helps improve the quality of the suggestion feature, and it's logged and anonymized in the same manner as Google web searches.
If you use a non-Google search provider as your default search engine, queries are sent and logged under that provider's privacy policy.
Additionally, when you use the omnibox to search for a single word, Chrome may send this word to your DNS server to see whether it corresponds to a host on your network, and may try to connect to the corresponding host. This gives you the option to navigate to that host instead of searching. For example, if your router goes by the hostname “router”, and you type “router” in the omnibox, you’re given the option to navigate to http://router/, as well as to search for the word “router” with your default search provider. This feature is not controlled by the "Use a prediction service to help complete searches and URLs..." option because it does not involve sending data to your default search engine.
Network predictions
Chrome uses a prediction service to load pages more quickly. The prediction service uses navigation history and local heuristics to predict which resources and pages are likely to be needed next, and it initiates actions such as DNS prefetching, TCP and TLS preconnection, and prerendering of web pages. To turn off network predictions, uncheck “Use a prediction service to load pages more quickly” in the “Privacy” section of Chrome’s settings.
If you have chosen to sync your Chrome history, your history can be used to improve predictions. When synced history is used, the URL of the current page is sent to Google, as well as the URLs of the pages Chrome predicts you'll visit next.
To improve load times, sites and Android apps can also request the browser to preload links that sites or apps think you might click next to help the page load faster. Preloading requests from Android apps are controlled by the same setting as Chrome-initiated predictions. But preloading requests from sites are always performed, regardless of whether Chrome’s network prediction feature is enabled.
If prerendering is requested, whether by Chrome or by a site or app, the preloaded site is allowed to set and read its own cookies just as if you had visited it (even if you don’t end up visiting the prerendered page). Website-initiated preloading is disabled if you disallow third party cookies, to prevent cookies from being set from pages that you did not visit.
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 key terms for details). If you do not have any cookies from google.com, this request will not create any.
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, as well as your current browser theme, are sent to your search engine with each refresh request so that the New Tab page can be correctly displayed. See the embedded search API for more details.
The New Tab page content may be designed by your default search provider to show suggestions, provided by Chrome, for websites that you might want to visit. These suggestions are embedded by Chrome into the New Tab page in a way that does not expose the suggested websites to your default search provider.
If you’ve chosen to sync your browsing history, Google uses your synced history to generate higher-quality suggestions for the New Tab page. Chrome will help improve the quality of suggestions by sending Google information about the sets of suggestions that were displayed, and those that were selected. If you're not syncing your browsing history or you stop syncing it, these suggestions are based on your local browsing history.
In order to help you get started, Chrome may also suggest content that is popular in your country or region, until you have enough personalized suggestions. Chrome uses your IP address to identify your country or region.
This information about the New Tab page may not apply if you've installed an extension that overrides the New Tab page.
Touch to Search
If you've enabled "Touch to Search" on Chrome Mobile you can search for terms by tapping them.
When you tap a word, the word and the surrounding text are sent to Google to identify recommended search terms (for example, tapping on "Michael" on a site about Michael Jackson might lead to a suggested search for "Michael Jackson"). The tapped word is logged in accordance with standard Google logging policies, and the surrounding text is logged only when the page is already in Google's index. If you sync your browsing history, the URL of the page is also sent and logged, and is used to improve your query suggestions.
When Google returns a search suggestion, a card "peeks through" at the bottom of the screen, showing the suggested search term. Opening this card is considered a regular search and navigation on Google, so standard logging policies apply.
Long-pressing on a word opens a peeking card with the selected word. No communication with Google occurs until the card is opened, and no surrounding text is sent. Saying “Ok Google” after long-pressing on a word provides the word and its surrounding text as context for the voice search.
Touch to Search is enabled in a limited mode by default: potentially privacy-sensitive data, such as the URL and surrounding text, is not sent for HTTPS pages. Touch to Search can be fully enabled and disabled in the card or in the Chrome privacy settings.
Safe Browsing protection
Google Chrome includes an optional feature called "Safe Browsing" to help protect you against phishing, social engineering, malware, unwanted software, and abusive websites or extensions. This protection helps prevent attackers from tricking you (social engineering) into sharing personal information with them (phishing) or installing malicious software on your computer (malware). Safe Browsing also helps protect you from websites and extensions that abuse browser functionality in order to steal your data, corrupt your browser environment, or spam you with unwanted interactions. Safe Browsing is designed specifically to protect your privacy and is also used by other popular browsers.
If you'd rather not send any information to Safe Browsing, you can turn these features off. Please be aware that if you do disable this feature, Chrome will no longer be able to protect you from websites that try to steal your information or install harmful software. We don't recommend turning it off.
Safe Browsing is able to protect users by collecting anonymous metrics to establish a baseline for determining which websites’ behavior or permissions may be harmful. Data that's specific to you or the websites you visit is randomized, constructed in a manner that ensures differential privacy, permitting only the monitoring of aggregate statistics that apply to thousands of users. (The reports are an instance of Randomized Aggregatable Privacy-Preserving Ordinal Responses; for technical details, see this technical report.) In particular, this means Google cannot use the reports to determine which websites you've visited. This data is used only to improve Safe Browsing protection.
When Safe Browsing is enabled in Chrome, Chrome contacts Google's servers periodically to download the most recent Safe Browsing list of unsafe sites, including phishing, social engineering, and malware sites, as well as sites that lead to unwanted software. The most recent copy of this list is stored locally on your system. Chrome checks the URL of each site you visit or file you download against this local list. If you navigate to a URL that appears on the 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 sends a partial URL fingerprint when a site requests a potentially dangerous permission, so that Google can protect you if the site is malicious. Google cannot determine the actual URL from this information.
In addition to the URL check described above, Chrome also conducts client-side checks. If a website looks suspicious, Chrome sends a subset of likely phishing and social engineering terms found on the page to Google, in order to determine whether the website should be considered malicious.
If you've also opted in to sending usage statistics in Chrome and you visit a site or download a file that Chrome has determined could be potentially harmful, Chrome sends some additional data to Google, including the full URL that matched the Safe Browsing list or appeared as a phishing site, plus the referrer URL chain.
If you encounter a website that is on Chrome’s Safe Browsing list, you will see a warning like the one shown below. From there, you can choose to opt in to reporting security incidents to help improve Safe Browsing. If you opt in, an incident report will be sent every time you receive a warning or visit a suspicious page. This information is used solely to improve Safe Browsing. The data is sent to Google over SSL, and it does not include any data originally sent over HTTPS, except the URLs and referrers of requests. It does not include data from sites you visit in Incognito mode.
See below for an example of the Safe Browsing warning. You can also visit our malware warning test page or social engineering test page to see it in action.
Safe Browsing also protects you from downloading malicious software. If you attempt to download a file on Chrome’s Safe Browsing list, you'll see a warning like this one:
To warn you about potentially dangerous files, Chrome checks the URL of potentially dangerous file types you download against a whitelist of known-good URLs maintained locally on your computer and updated regularly. Chrome trusts potentially dangerous file types that match URLs in the whitelist, and it also trusts files downloaded from the local network or signed by a trusted authority. Other potentially dangerous file types are presumed unsafe; for these, Chrome sends Google the information needed to help determine whether the download is harmful, including some or all of the following: information about the full URL of the site or file download, all related referrers and redirects, code signing certificates, file hashes, and file header information. Chrome may then show a warning like the one pictured above.
If Chrome suspects that your settings have been tampered with, Chrome reports the URL of the last downloaded potentially dangerous file, and information about the nature of the possible tampering, to the Safe Browsing service.
For some downloads, Chrome may ask you to opt in to reporting security incidents to Google Safe Browsing, in order to improve the quality of download protection. Once you've opted in, downloaded files that are suspicious will be sent to Google for investigation each time they are encountered. You can change this opt-in setting at any time in the Chrome settings.
For all Safe Browsing requests, Google logs the transferred data in its raw form for up to two weeks. Google collects standard log information for Safe Browsing requests, including an IP address and one or more cookies. After at most two weeks, Safe Browsing deletes the raw logs, storing only calculated data in an anonymized form that does not include your IP addresses or cookies. Additionally, Safe Browsing requests won’t be associated with your Google Account. They are, however, tied to the other Safe Browsing requests made from the same device.
Unwanted software protection
When possible, Chrome helps detect and remove software that breaks Google's Unwanted Software Policy (e.g., changes Chrome's settings without your approval). To do so, Chrome scans your computer periodically for the sole purpose of detecting potentially unwanted software. If such software is detected, Chrome may offer you the option to use the Chrome Cleanup Tool to remove it.
If you run the Chrome Cleanup Tool and don’t opt out of uploading the logs, the Chrome Cleanup Tool will send information to Google about the state of your machine before and after the Cleanup Tool runs. To review the data that will be sent, click "Information about your computer" in the Chrome Cleanup Tool. This data is protected under the Google Privacy Policy and stored for up to 60 days. After that, only aggregated logs are retained.
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 “Safe Browsing 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 “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.
Software Updates
Google Chrome and the Google Chrome Apps Launcher use Google Update to keep you up to date with the latest 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 software updates and hardware manufacturer customizations such as apps, wallpaper, and help articles are delivered. This information is not personally identifiable, and is common to all users of Chrome OS on the same revision of device. For desktop versions of Chrome, limited and not personally identifiable information about your hardware is sent to Google to provide the correct updates.
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. If you are using an extension or application restricted to a certain audience, authentication tokens will be sent with update requests for these add-ons. 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”). Update requests for component updates contain these IDs, the hash of the previous download (called a "fingerprint"), and the components’ versions. As every installation has the same ID, and downloads of the same component have the same fingerprint, none of this information is personally identifiable.
Chrome may download and execute a binary executable, for example as part of the software update or to improve Safe Browsing protection. Any such executable will be cryptographically signed and verified before execution. Chrome may download further static resources like dictionaries on demand to reduce the size of the installer.
Chrome’s recovery component tries to repair Google Update in case it is broken. After the binary was executed, Google Update uploads the statistics on which actions were performed. The statistics contain no personal identifiable information.
Network time
Chrome needs to know the time in order to verify SSL certificates, which are valid only for a specified time. At random intervals or when Chrome encounters an expired SSL certificate, Chrome may send requests to Google to obtain the time from a trusted source. These requests are more frequent if Chrome believes the system clock is inaccurate. These requests contain no cookies and are not logged on the server.
Installation token
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 all platforms 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 data to Google by uninstalling Chrome, and installing a version downloaded directly from www.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.
If you enable usage statistics and crash reports, Chrome will also anonymously report to Google if requests to websites operated by Google fail or succeed in order to detect and fix problems quickly.
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.
If you enable usage statistics and crash reports, Chrome will also report anonymous, randomized data that is constructed in a manner which is not linked to the unique token, and which ensures that no information can be inferred about any particular user's activity. This data collection mechanism is summarized on the Google research blog, and full technical details have been published in a technical report and presented at the 2014 ACM Computer and Communications Security conference.
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.
Translate
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.
If you do choose to translate a web page, the text of that page is sent to Google Translate for translation. Your cookies are not sent along with that request and the request is sent over SSL. This communication with Google's translation service is covered by the Google privacy policy.
Sign In to Chrome
Google Chrome provides the option to sign in with your Google Account and synchronize your Chrome data across multiple devices. Synced data can include bookmarks, saved passwords, open tabs, browsing history, extensions and other settings. In Advanced sync settings, you can choose which types of data to synchronize with this device. By default, all syncable data types are enabled.
You can sign in to Chrome or disconnect your Google Account from Chrome at any time using the “Sign in” section of Chrome’s settings. Signing in to Chrome or Chrome OS will automatically sign you in to the associated Google Account. If you are using a managed device, your system admin may disable the sign in feature or require that data be deleted when you disconnect your account.
Google uses your personal synchronized data to provide you a consistent browsing experience across your devices, and to customize features in Chrome. You can manage your synchronized history by going to chrome://history in your Chrome browser. If “Include history from Chrome and other apps in your Web & App Activity” is checked on the Web & App Activity controls page, Google also uses your synchronized browsing data to provide personalized Google products and services to you. You can change your preference any time, and manage individual activities associated with your Google account.
The paragraph above describes the use of your personal browsing history. Google also uses aggregated and anonymized synchronized browsing data to improve other Google products and services. For example, we use this information to improve Google Search by helping to detect mobile friendly pages, pages which have stopped serving content, and downloads of malware.
If you would like to use Google's cloud to store and sync your Chrome data without allowing any personalized and aggregated use by Google as described in the previous paragraphs, you can choose to encrypt all of your synced data with a sync passphrase. 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 the passphrase. Regardless of how you choose to encrypt your data, all data is always sent over secure SSL connections to Google’s servers.
If you're signed in to Chrome and are syncing passwords and/or other types of login credentials without a sync passphrase, these credentials are stored in your Google Account. Chrome may help you sign in with credentials you've saved in Android apps on websites that are associated with the respective apps. Likewise, credentials you've saved for websites can be used to help you sign in to related Android apps. You can view the credentials you've saved in Chrome and Android by visiting passwords.google.com in any browser. If you've saved credentials for Android applications, Chrome periodically sends a cookieless request to Google to get an updated list of websites that are associated with those applications. To stop websites and Android apps from automatically signing in using credentials you previously saved, you can turn off Auto Sign-In on passwords.google.com or in Chrome settings under "Manage passwords". For more details see this article.
All data synchronized through Google’s servers is subject to Google’s Privacy Policy. To get an overview of the Chrome data stored for your Google Account, go to the Chrome section of Google Dashboard. That page also allows you to stop synchronization completely and delete all sync data from Google’s servers.
Autofill
Google Chrome has a form autofill feature that helps you fill out forms on the web more quickly. Autofill is enabled by default, but it can be turned off at any time in Chrome’s settings.
If Autofill is enabled and you encounter a web page containing a form, Chrome sends some information about that form to Google. This information includes a hash of the web page’s hostname, as well as form identifiers (such as field names), the basic structure of the form, and Chrome’s guess at each field’s data type (for example, “field X looks like a phone number, and field Y looks like a country”). This information helps Chrome match up your locally stored Autofill data with the contents of the form, and it also helps to improve the quality of form-filling over time.
If Autofill is enabled when you submit a form, Chrome sends the data types you actually used in the form. This information helps Chrome improve its guesses over time. The actual text you typed into the form is not sent to Google.
You can manage your Autofill entries via Chrome’s settings, and you can edit or delete saved information at any time. Chrome will never store credit card information without explicit confirmation. If you scan your credit card using a phone camera, the recognition is performed locally.
Chrome may help you sign in to websites with credentials you've saved to Chrome's password manager or Google Smart Lock by autofilling sign-in forms, by offering you an account picker, or by automatically signing you in. You can manage and delete your saved credentials in the “Forms and passwords” section of Chrome’s settings.
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 of this document). If you choose to sync Autofill information, field values are sent as described in “Sign In to Chrome”; otherwise, field values are not sent.
Payments
If you are signed in, Chrome will offer to save your credit cards and related billing addresses to Google Payments. Integration with Google Payments can be disabled via Chrome’s Advanced sync settings. If you choose not to sync credit cards with Google Payments, credit cards will be saved locally but will not be synced. If you are signed in and integration with Google Payments is enabled, Chrome may offer to autofill forms with credit card data stored in your Google Payments account. Credit card numbers from your Google Payments account will be masked until you provide the correct CVV code. When providing your CVV code for verification, you can choose to store the credit card locally as part of your Chrome Autofill data. If you choose not to store the card locally, you will be prompted for your CVV code each time you use the card. If you use a card from Google Payments, Chrome will collect information about your computer and share it with Google Payments to prevent fraudulent use of your card.
To delete credit card information saved in Chrome, follow the “Add and edit credit cards” steps in the Autofill article. When you delete a credit card that's also saved in your Google Payments account, you will be redirected to the Google Payments to complete the deletion. After your card has been deleted from your Google Payments account, Chrome will automatically remove that card from your Autofill suggestions.
On Android, Chrome supports the PaymentRequest API by allowing you to pay for purchases with credit cards from both Autofill and Android Pay. PaymentRequest allows the merchant to request the following information: full name, shipping address, billing address, phone number, email, credit card number, credit card expiration, CVV, and Android Pay credentials. Information is not shared with the merchant until you agree. New credit cards added using PaymentRequest can be saved to Google Payments.
Geolocation
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 your device to use your geolocation in Android OS's settings, omnibox searches in Chrome for Android will automatically send your location to Google. The same is true for Chrome on iOS if you have permitted Chrome to use geolocation in iOS Settings.
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 the Web Speech API, a mechanism for converting speech to text on a web page. It uses 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 the domain of the website using the API, your default browser language and the language settings of the website. Cookies are not sent along with these requests.
Hands-free Voice Search
This feature is only available on Chrome OS. If you opt-in to the feature, Chrome OS will listen for you to say "Ok Google" and then send the audio of the next thing you say, plus a few seconds before, to Google. Detection of the phrase "Ok Google" is performed locally on your computer, and the audio is only sent to Google after it detects "Ok Google". You can enable or disable this feature in Chrome Settings.
On Chrome OS devices with a local audio processor, enabling this feature in Chrome Settings will cause Chrome to listen whenever the screen is on and unlocked. On these devices, Chrome will also prompt you to enable Voice & Audio Activity for the associated Google account. If this setting is enabled, the audio is stored with your Google account, and you can view and delete this audio in Voice & Audio Activity.
On other Chrome OS devices, when this feature is enabled, Chrome listens for “Ok Google” only when a Google search page, the New Tab page, or the Chrome OS Launcher is in the foreground. In this case, the audio is sent to Google anonymously and logged anonymously.
Once the audio has been converted to text, a search with that text is submitted by Chrome to Google for which standard search logging policies apply.
You can determine your Chrome OS device’s behavior by examining the text in the “Search” section of settings.
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.
Chrome also allows users to choose to send information that helps us improve our SSL warnings and error pages. You can opt in to this feature by checking a checkbox on any SSL error page. While you are opted-in, the SSL certificate chain, the server's hostname, the local time, and relevant details about the validation error and SSL error page type will be sent to our security team every time you see an SSL error page. You can opt out anytime by unchecking the box of “Automatically report details of possible security incidents to google” in Privacy setting.
Token Binding
Chrome's Token Binding feature allows a server to validate 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 because cookies can be cryptographically tied to a particular Token Binding ID. This feature makes it significantly more difficult to convert stolen cookies into stolen sessions.
Token Binding IDs do not contain any information about the user, and a different Token Binding ID is created for each secure origin. A Token Binding ID created for one server will be shared with another server only if the original server requests it to be shared. Token Binding IDs are not shared between Chrome profiles, and all Token Binding IDs created during Incognito browsing are destroyed when you exit the Incognito session. Note that Token Bindings are not used for requests that block cookies.
You can determine which Token Binding IDs have been created (and you can remove unwanted IDs) in the Cookies and Site Data dialog (available at chrome://settings/cookies). Token Binding IDs are also subject to removal when "Cookies and Site Data" are cleared via the "Clear Browsing Data" dialog (chrome://settings/clearBrowserData). Token Binding is an evolution of the TLS Channel ID feature.
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.
As they're more deeply integrated into Chrome, applications and extensions that you choose to install can request access to additional capabilities, enabling functionality that doesn't make sense on the web at large: background notifications or raw socket access, for instance. These additional permissions may change the way your data is collected and shared, as extensions and applications might have access to data regarding the websites you visit, and might be capable of monitoring or modifying your interactions with the web. When installing an application or extension, Chrome may first warn you about certain capabilities. Please do take the time to read and evaluate this warning before proceeding with the installation. Note also that interactions with and data collected by these third-party applications and extensions are governed by their own privacy policies, not Google's privacy policy.
Push Messaging
Apps and extensions installed in Chrome, as well as websites that you give permission to, may receive push messages from their respective backend servers. The message’s data is sent over a secure channel from the developer through Google’s infrastructure to Chrome on your device, which can wake up applications, extensions, and websites to deliver the message. Google servers handle the messages as plain text, and retain up to 4 weeks of messages in order to ensure delivery to users even if their devices are offline at the time of sending.
If you install an application or extension that uses push messaging or grant the notifications permission to a website, Chrome provides it with a registration ID which can be used to send messages to the entity (app, extension, or website). One or more registration IDs are generated for each entity that uses push messages. Websites you visit in Incognito mode are not currently allowed to send you push messages and therefore cannot get a registration ID.
When you uninstall an application or extension, or clear cookies for a permitted website, its registration ID is revoked and will not be reused even if the same app or extension is re-installed, or the same website is re-visited. Registration IDs used by Chrome components such as Sync are revoked once they are no longer in use, for example when the user disables Sync. When a registration ID is revoked, the associated entity on your device stops receiving messages sent from its developer’s server.
The registration IDs that are passed to entities contain an encrypted device ID, which is used for routing the messages. Google can decrypt the device ID, but other entities cannot, and the encryption is designed such that two registration IDs for the same device ID cannot be correlated. The device ID is reset when the Chrome profile is removed (via Chrome Settings -> People), or when neither Chrome Sync nor any of the entities requires it for push messages. Any messages routed to registration IDs containing the revoked device ID will not be delivered. On Android the lifetime of the device ID is governed by the operating system and is independent of Chrome.
Chrome custom tabs
On Android devices, an app developer may use a Custom Tab to show web content when you click on a URL from their app. A Custom Tab may look different from a regular Chrome tab, for example it may have app-specified visual style, and the absence of an editable URL bar. Despite the different visual style a Custom Tab may have, the data sent and received in the Custom Tab, such as cookies, saved passwords and browsing history function the same way they do in a normal Chrome tab. The Custom Tab is an app-customized view using the same underlying user profile.
With Chrome Custom Tabs, an Android app developer may also specify custom actions in the Chrome toolbar and overflow menu that are relevant to their app, for example,"share", “save page”, “copy URL”. If you tap on such a button, the address of the current website is shared with the application.
An application can request Chrome to pre-render a given URL in the background. This allows Chrome to show you a pre-loaded site instantly when you open it from the app. At the same time it allows an application to set cookies in your browser in the background. To disable pre-rendering, you can uncheck "Prefetch page resources" in the privacy settings.
Continue where you left off
If you have selected the option to “Continue where you 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 you left off” setting under “On Startup”.
Chrome Variations
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 only describe the state of the installation of Chrome itself, including active variations, as well as server-side experiments that may affect the installation.
The variations active for a given installation are determined by a seed number which is randomly selected on first run. If you did not opt in to providing usage statistics, this number is chosen between 0 and 7999 (13 bits of entropy). If you would like to reset your variations seed, run Chrome with the command line flag “--reset-variation-state”. Experiments may be further limited by country (determined by your IP address), operating system, Chrome version and other parameters.
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 (Chrome cannot, however, guarantee that NPAPI plugins also send the header.) The header will not be sent with system traffic such as the geolocation, metrics or device management services.
The effect of Do Not Track 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 on iOS now uses WKWebView to provide a more stable and faster browser. As a result of this move, the Do Not Track preference is no longer available due to iOS constraints. If Apple makes changes to allow this feature, Chrome will make Do Not Track available again in iOS.
Plugins
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.
Content Licensing
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 for a certificate to verify the eligibility of the device. To do so, the device will provide Chrome a non-permanent machine identifier, which will be added in a certificate and passed on to the content provider. Chrome will prompt you to allow or deny this verification check. For more information, please see our help center.
Cloud policy
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 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 are 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 Chrome on iOS, or remove the desktop profile.
Registered profiles check for policy changes periodically (every 3 hours by default). In some cases, the server pushes policy changes to the client without waiting for Chrome's periodic check. Unregistered profiles check whether a policy has been turned on for their domain each time Chrome starts up.
The policy list contains details about the types of configurations that are available via Cloud Policy.
Data Saver
If you enable Data Saver, Chrome will send your HTTP traffic through Google's optimizing proxy servers. This option reduces the amount of data downloaded, and protects you against malware and phishing via the Safe Browsing service. You can find more information about the data compression benefits on the Chromium blog.
The proxy service is disabled for connections to HTTPS origins and connections made from Incognito tabs. These connections are not routed through Google's servers. For connections to HTTP origins, request URLs are logged. Cookies and If-None-Match headers are stripped from the logs. Additionally, the content of proxied pages is also cached but not logged. The logs are not associated with your Google Account, and the entire log entry is removed within 6 months. These logs are also governed by standard Google search logging policies.
Google uses the logged and cached data to improve both Data Saver and Safe Browsing; for example, more effective optimizations can be uncovered by analyzing timing data for pages loaded through the proxy service, and malware can be detected more rapidly by analyzing response data in realtime.
Your IP address is forwarded to the origin HTTP server via an X-Forwarded-For header, in accordance with the HTTP standard. The Data Saver service is a transparent proxy, not an anonymization service.
By default, the connection between the browser and the Data Saver proxy is over an encrypted channel. However, a network administrator can disable the use of an encrypted channel to Data Saver.
Supervised Users
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.
Incognito and Guest Mode
Incognito mode in Chrome is a temporary browsing mode. It ensures that you don’t leave browsing history and cookies on your computer. The browsing history and cookies are deleted only once you have closed the last incognito window. Incognito mode cannot make you invisible on the internet. Websites that you navigate to may record your visits. Going incognito doesn’t hide your browsing from your employer, your internet service provider, or the websites you visit.
Browsing as a Guest in Chrome allows you to use somebody else's computer without modifying their profile. For example, no bookmarks or passwords get stored on their computer. Note that Guest mode does not protect you for example, if the computer you are using is infected by a keylogger that records what you type.
iOS 8 and Mac OS X Yosemite Handoff Support
While browsing in a standard (i.e. non-Incognito) session, Chrome will share your current URL with iOS 8+ to support the Handoff feature that was added in OS X Yosemite. This information is only sent to Apple devices that are paired with your iOS device, and the data is encrypted in transit.
More information is available at Apple Support, Apple Developers, and in the Apple iOS Security Guide. Chrome support for this feature can be disabled in Chrome settings.
Security Key
A FIDO U2F Security Key provides a non-phishable credential which can be used to authenticate a user. This mitigates the risk of various kinds of man-in-the-middle attacks in which websites try to steal your password and use it later.
To prevent abuse, a website is required to be delivered over a secure connection (HTTPS), and to register the security key before it can be used for identification. Once a website is registered with a specific security key, that security key will provide a persistent identifier, regardless of which computer it is plugged into, or whether you're in incognito or guest mode, but you must physically interact with the security key to give a website access to an identifier (by, for example, touching it, or plugging it in).
Physical Web
The Physical Web feature is available on Chrome on iOS and Android.
On Android devices, users can enable (or disable) the feature in the Privacy settings. On iOS devices, users can enable the feature by adding the Chrome widget to their Today view in the notification center. On both systems, users will need to also turn on Bluetooth.
Chrome scans for Physical Web devices that are broadcasting URLs via Bluetooth Low Energy advertisement packets, using the Eddystone-URL format. Bluetooth signals can be received 90 feet away or more, depending on signal strength and the user’s environment (although often the range is much shorter, due to obstacles and signal noise).
On Android, once a user enables the feature, Chrome scans for nearby devices for a few seconds each time the user unlocks the mobile device in use. The user receives a silent notification when Chrome finds a nearby URL. On iOS, Chrome scans for nearby devices for a few seconds when the Today widget is displayed in the notification center.
In order to show useful results, Chrome sends detected URLs to Google’s Physical Web Service (PWS) via a cookieless HTTPS request. For each URL, the PWS obtains the title of the web page, filters out unsafe results, and returns a ranking based on non-personalized signals about the quality and relevance of the web page.
Bluetooth
Google Chrome supports the Web Bluetooth API, which provides websites with access to nearby Bluetooth Low Energy devices with your consent.
Chrome does not let any page communicate with a device unless you explicitly consent. When a web page asks to pair with a device, Chrome will ask you to choose which device the web page should access, if any. Selecting a device for one page does not give other pages access to the device you have chosen, and does not allow that page to access other devices. Currently, permission for a page to communicate with a device is usually revoked when the page is reloaded, and is always revoked when Chrome is restarted.