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, and are turned on by default. They can be disabled by unchecking the "Use a prediction service..." box in the “Privacy” section of Google Chrome's settings.
In order to provide these predictions, Chrome sends the text that you have typed into the omnibox, along with a general categorization (e.g. "URL", "search query", or "unknown"), 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.
When you type a single word in the omnibox, 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. If your router goes by the hostname “router”, you can type “router” and are prompted to navigate to http://router/ in addition to searching for the word “router” with your default search provider.
If you've chosen to sync your Chrome history, and if Google is your default search engine, then Chrome may present suggestions when you focus on the Omnibox and before you start typing. To do so, Chrome will include the URL of the page you're viewing. URLs are only sent for HTTP pages and Google HTTPS pages.
If Google is your default search engine, then logs of these suggestion requests are retained for two weeks, after which 2% of the data is randomly selected, anonymized, and retained in order to improve the prediction feature. URLs are not included in this 2% sample.
If you select one of the suggestions, 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.
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 here. These network predictions can be disabled by unchecking the "Predict network actions to improve page load performance" 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 pages Chrome predicts you'll visit next, are sent to Google.
If Chrome's prerendering feature is enabled, pages you're likely to navigate to may be downloaded and rendered in the background to speed up navigations. Prerendering requests are no different than any other requests: cookies will be sent and set according to your settings.
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 omniboxin 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.
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.
Touch to Search
Enabling "Touch to Search" allows you to search for terms by tapping on them.
When you tap on a word, the word itself, and the surrounding text are sent to Google to query a recommended search term (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 our logging policies and the surrounding text is never logged. If you sync your browsing history, the URL of the page is also sent and logged to improve your query suggestions.
When Google returns a search suggestion, a card will peek through at the bottom of the screen, showing the suggested search term. Opening this card is considered as a regular search and navigation on Google. In this case, standard search logging policies apply.
Long pressing on a word opens a peeking card with the selected word. No search suggestions are fetched from Google in this case.
Touch to Search is disabled by default and can be enabled and disabled in the privacy settings of Chrome.
Phishing and malware protection
Google Chrome includes an optional 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.
If you'd rather not send any information to Safe Browsing, you can also turn these features off. 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.
When Safe Browsing is enabled in Chrome, Chrome will contact Google's servers periodically to download the most recent Safe Browsing list, containing suspected phishing and malware sites. The most recent copy of this list is stored locally on your system. Chrome will check the URL of each site you visit or file you download against this local list. 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. Google cannot determine the full URL from this information.
If a URL was indeed dangerous, Chrome reports this anonymously to Google to improve Safe Browsing. The data sent is randomized, constructed in a manner that ensures differential privacy, permitting only monitoring of aggregate statistics that apply to tens of thousands of users at minimum. The reports are an instance of Randomized Aggregatable Privacy-Preserving Ordinal Responses, whose full technical details have been published in a technical report and presented at the 2014 ACM Computer and Communications Security conference. This means that Google cannot infer which website you have visited from this.
In addition to the URL check described above, Chrome also conducts client-side checks. If a website looks suspicious, it sends a subset of likely phishing and social engineering terms found on the page to Google to obtain additional information available from Google's servers on whether the the website should be considered malicious.
If you have 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 will send certain additional data to Google, including the full URL that matched the Safe Browsing list or appeared as a phishing site and 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 pictured below. From that warning screen, you can choose to have Chrome send additional information to Google to help improve Safe Browsing, such as the content of the suspicious page. This information can be used by Google to verify whether the site may still be harmful to future users. While opted-in to help improve Safe Browsing, this information will be sent every time you receive a malware warning. This data is sent to Google over SSL, and does not include any data originally sent over HTTPS except the URLs and referrers of requests, and does not include data from sites you visit in Incognito mode.
You can see how this warning might look below (e.g. on a Mac) or by visiting our test page. The phishing warning will look different.
Safe Browsing also protects you from downloading malicious software. If you attempt to download a file on Chrome’s Safe Browsing list, you will see a warning like the one pictured below.
To do this, Chrome checks the URL of executables you download against a whitelist 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. Other executables are presumed unsafe, and Chrome will send to Google information needed to help determine whether the download is potentially 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 will report the URL of the last downloaded executable and information about the nature of the unexpected changes to the Safe Browsing service.
Where possible, Chrome aids with the detection and removal of software that 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 thesoftware removal tool to remove it.
For some downloads, Chrome may ask to send the suspicious file to Google to improve the quality of download protection. Once opted-in, this data will be sent every time such a file is encountered. You can disable this opt-in at any time in the Chrome settings page.
For all Safe Browsing requests, Google logs the transferred data in its raw form for up to two weeks. Google collects standard log information in connection with Safe Browsing requests, including an IP address and one or more cookies. 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 won’t be associated with your Google Account. They are however, tied to the other Safe Browsing requests made from the same device.
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 “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 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 phishing and malware 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.
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 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.
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 theGoogle 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.
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, passwords, and bookmarks, but not themes.
By default, passwords are encrypted locally with a key stored in 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.
If you're signed in to Chrome and are syncing passwords without a sync passphrase, Chrome may fill the passwords that you saved in Android apps into websites that are associated with the respective apps. Likewise, passwords that you saved for websites can be used to help you sign in to related Android apps. You'll be able to view these passwords you've saved in Chrome and Android from any browser by visiting passwords.google.com. If you have passwords saved for Android applications, Chrome will periodically send a cookieless request to Google to get an updated list of websites that are associated with those applications. To stop your Android apps from automatically signing in using shared passwords with associated websites, you can turn off Auto Sign-In onpasswords.google.com. You can read more about the usage of this feature in this article.
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. If you scan your credit card using the phone camera, the recognition is performed locally.
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. Credit card numbers aren’t synced. However, if you have a Google Wallet account and you are signed in to Chrome, then Chrome may offer to autofill the credit card data stored in your Google Wallet account. The credit card numbers from your Google Wallet 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.
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 two mechanisms for converting speech to text: input elements that contain an x-webkit-speech attribute and the Web Speech API. Both 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.
Hands-free Voice Search
If you opt-in to the feature, Chrome supports hands-free search on Google Search. Say "Ok Google" into your computer's microphone and once that phrase is detected locally, Chrome will convert the query following the phrase "Ok Google" to text via the Web Speech API, which sends audio and the resulting text to Google as a search query.
This audio recording will only be sent to Google after you say "Ok Google" and only while on a Google search page or on the New Tab Page. Detection of the phrase "Ok Google" is done only locally, therefore Google does not collect audio of this phrase. The audio of your search query is deleted from Google’s server after it has been converted to text.
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.
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 atchrome://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.
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). A different registration ID is 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.
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”.
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”.
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 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 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.
When you sign into a Chrome OS device, Chrome on Android, Chrome on iOS, 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 Chrome on iOS, 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.
If you choose to enable Data Saver, Chrome will send your HTTP traffic through Google's optimizing servers in order to reduce the amount of data downloaded and improve overall performance, and protect you against malware and phishing via the Safe Browsing service. 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 to HTTP origins, request URLs are logged. Cookies and If-None-Match headers 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 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 on 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, and not an anonymization service.
By default, the connection between the browser and the Data Saver proxy is over an encrypted channel. A network administrator can restrict the use of an encrypted channel to Data Saver for a specific user by blocking access to a canary URL (http://check.googlezip.net/connect) and returning a response other than a status code 200 with a response body of "OK".
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 atchrome.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 atchrome.com/manage and delete the respective supervised user.
Online payments with Google Wallet
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.
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).
On iOS devices, users can access the Physical Web by adding the Chrome widget to their Today view and turning Bluetooth on. When the Today widget is opened, Chrome will scan for Physical Web smart devices that are broadcasting URLs via Bluetooth Low Energy advertisement packets. Bluetooth signals can be received up to 90 feet away or more depending on signal strength and your environment, although often the range is much shorter due to obstacles and signal noise.
You can enable and disable this feature in the widget. When the feature is enabled, Chrome sends detected URLs, along with the respective signal strengths of broadcasting devices as received by the user’s device, via a cookieless HTTPS request to Google’s Physical Web Service (PWS).
For each URL, the PWS obtains the title of the webpage, filters out unsafe results, and returns a ranking. The ranking of the returned result is based on the proximity of the broadcasting Physical Web object, calculated by the PWS based on detected signal strength, as well as non-personalized signals about the quality and relevance of the webpage.