Security Blog
The latest news and insights from Google on security and safety on the Internet
An update on SHA-1 certificates in Chrome
December 18, 2015
Posted by Lucas Garron, Chrome security and David Benjamin, Chrome networking
As
announced last September
and supported by
further recent research
, Google Chrome does not treat SHA-1 certificates as secure anymore, and will completely stop supporting them over the next year. Chrome will discontinue support in two steps: first, blocking new SHA-1 certificates; and second, blocking all SHA-1 certificates.
Step 1: Blocking new SHA-1 certificates
Starting in early 2016 with Chrome version 48, Chrome will display a certificate error if it encounters a site with a leaf certificate that:
is signed with a SHA-1-based signature
is issued on or after January 1, 2016
chains to a public CA
We are hopeful that no one will encounter this error, since public CAs must stop issuing SHA-1 certificates in 2016 per the
Baseline Requirements for SSL
.
In addition, a later version of Chrome in 2016 may extend these criteria in order to help guard against SHA-1 collision attacks on older devices, by displaying a certificate error for sites with certificate chains that:
contain an intermediate or leaf certificate signed with a SHA-1-based signature
contain an intermediate or leaf certificate issued on or after January 1, 2016
chain to a public CA
(Note that the first two criteria can match different certificates.)
Note that sites using new SHA-1 certificates that chain to local trust anchors (rather than public CAs) will continue to work without a certificate error. However, they will still be subject to the UI downgrade specified in our
original announcement
.
Step 2: Blocking all SHA-1 certificates
Starting January 1, 2017 at the latest, Chrome will completely stop supporting SHA-1 certificates. At this point, sites that have a SHA-1-based signature as part of the certificate chain (not including the self-signature on the root certificate) will trigger a fatal network error. This includes certificate chains that end in a local trust anchor as well as those that end at a public CA.
In line with
Microsoft Edge
and
Mozilla Firefox
, the target date for this step is January 1, 2017, but we are considering moving it earlier to July 1, 2016 in light of ongoing research. We therefore urge sites to replace any remaining SHA-1 certificates as soon as possible.
Note that Chrome uses the certificate trust settings of the host OS where possible, and that an update such as Microsoft’s
planned change
will cause a fatal network error in Chrome, regardless of Chrome’s intended target date.
Keeping your site safe and compatible
As individual TLS features are found to be too weak, browsers need to drop support for those features to keep users safe. Unfortunately, SHA-1 certificates are not the only feature that browsers will remove in the near future.
As we
announced
on our security-dev mailing list, Chrome 48 will also stop supporting RC4 cipher suites for TLS connections. This aligns with timelines for
Microsoft Edge
and
Mozilla Firefox
.
For security and interoperability in the face of upcoming browser changes, site operators should ensure that their servers use SHA-2 certificates, support non-RC4 cipher suites, and follow TLS best practices. In particular, we recommend that most sites support TLS 1.2 and prioritize the ECDHE_RSA_WITH_AES_128_GCM cipher suite. We also encourage site operators to use tools like the
SSL Labs server test
and
Mozilla's SSL Configuration Generator
.
Indexing HTTPS pages by default
December 17, 2015
Posted by
Zineb Ait Bahajji
, WTA, and the Google Security and Indexing teams
[Cross-posted from the
Webmaster Central Blog
]
At Google, user security has always been a top priority. Over the years, we’ve worked hard to promote a more secure web and to provide a better browsing experience for users.
Gmail
,
Google search
, and YouTube have had secure connections for some time, and we also started giving a slight
ranking boost to HTTPS URLs
in search results last year. Browsing the web should be a private experience between the user and the website, and must not be subject to
eavesdropping
,
man-in-the-middle attacks
, or data modification. This is why we’ve been strongly promoting
HTTPS everywhere
.
As a natural continuation of this, today we'd like to announce that we're adjusting our indexing system to look for more HTTPS pages. Specifically, we’ll start crawling HTTPS equivalents of HTTP pages, even when the former are not linked to from any page. When two URLs from the same domain appear to have the same content but are served over different protocol schemes, we’ll typically choose to index the HTTPS URL if:
It doesn’t contain insecure dependencies.
It isn’t blocked from crawling by robots.txt.
It doesn’t redirect users to or through an insecure HTTP page.
It doesn’t have a rel="canonical" link to the HTTP page.
It doesn’t contain a noindex robots meta tag.
It doesn’t have on-host outlinks to HTTP URLs.
The sitemaps lists the HTTPS URL, or doesn’t list the HTTP version of the URL.
The server has a valid TLS certificate.
Although our systems prefer the HTTPS version by default, you can also make this clearer for other search engines by redirecting your HTTP site to your HTTPS version and by implementing the
HSTS header
on your server.
We’re excited about taking another step forward in making the web more secure. By showing users HTTPS pages in our search results, we’re hoping to decrease the risk for users to browse a website over an insecure connection and making themselves vulnerable to content injection attacks. As usual, if you have any questions or comments, please let us know in the comments section below or in our
webmaster help forums
.
Proactive measures in digital certificate security
December 11, 2015
Posted by Ryan Sleevi, Software Engineer
Over the course of the coming weeks, Google will be moving to distrust the “Class 3 Public Primary CA” root certificate operated by Symantec Corporation, across Chrome, Android, and Google products. We are taking this action in response to a
notification by Symantec Corporation
that, as of December 1, 2015, Symantec has decided that this root will no longer comply with the
CA/Browser Forum’s Baseline Requirements
. As these requirements reflect industry best practice and are the foundation for publicly trusted certificates, the failure to comply with these represents an unacceptable risk to users of Google products.
Symantec has informed us they intend to use this root certificate for purposes other than publicly-trusted certificates. However, as this root certificate will no longer adhere to the CA/Browser Forum’s Baseline Requirements, Google is no longer able to ensure that the root certificate, or certificates issued from this root certificate, will not be used to intercept, disrupt, or impersonate the secure communication of Google’s products or users. As Symantec is unwilling to specify the new purposes for these certificates, and as they are aware of the risk to Google’s users, they have requested that Google take preventative action by removing and distrusting this root certificate. This step is necessary because this root certificate is widely trusted on platforms such as Android, Windows, and versions of OS X prior to OS X 10.11, and thus certificates Symantec issues under this root certificate would otherwise be treated as trustworthy.
Symantec has indicated that they do not believe their customers, who are the operators of secure websites, will be affected by this removal. Further, Symantec has also indicated that, to the best of their knowledge, they do not believe customers who attempt to access sites secured with Symantec certificates will be affected by this. Users or site operators who encounter issues with this distrusting and removal should
contact Symantec Technical Support
.
Further Technical Details of Affected Root:
Friendly Name:
Class 3 Public Primary Certification Authority
Subject:
C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Public Key Hash (SHA-1):
E2:7F:7B:D8:77:D5:DF:9E:0A:3F:9E:B4:CB:0E:2E:A9:EF:DB:69:77
Public Key Hash (SHA-256):
B1:12:41:42:A5:A1:A5:A2:88:19:C7:35:34:0E:FF:8C:9E:2F:81:68:FE:E3:BA:18:7F:25:3B:C1:A3:92:D7:E2
MD2 Version
Fingerprint (SHA-1):
74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
Fingerprint (SHA-256):
E7:68:56:34:EF:AC:F6:9A:CE:93:9A:6B:25:5B:7B:4F:AB:EF:42:93:5B:50:A2:65:AC:B5:CB:60:27:E4:4E:70
SHA1 Version
Fingerprint (SHA-1)
: A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B
Fingerprint (SHA-256)
: A4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09:CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05
Year one: progress in the fight against Unwanted Software
December 9, 2015
Posted by Moheeb Abu Rajab, Google Security Team
“At least 2 or 3 times a week I get a big blue warning screen with a loud voice telling me that I’ve a virus and to call the number at the end of the big blue warning.”
“I’m covered with ads and unwanted interruptions. what’s the fix?”
“I WORK FROM HOME AND THIS POPING [sic] UP AND RUNNING ALL OVER MY COMPUTER IS NOT RESPECTFUL AT ALL THANK YOU.”
Launched in 2007
, Safe Browsing has long helped protect people across the web from well-known online dangers like phishing and malware. More recently, however, we’ve seen an increase in user complaints like the ones above. These issues and others—hijacked browser settings, software installed without users' permission that resists attempts to uninstall—have signaled the rise of a new type of malware that our systems haven’t been able to reliably detect.
More than a year ago
, we began a broad fight against this category of badness that we now call “Unwanted Software”, or “UwS” (pronounced “ooze”). Today, we wanted to share some progress and outline the work that must happen in order to continue protecting users across the web.
What is UwS and how does it get on my computer?
In order to combat UwS, we first needed to define it. Despite lots of variety, our research enabled us to develop a
defining list of characteristics
that this type of software often displays:
It is deceptive, promising a value proposition that it does not meet.
It tries to trick users into installing it or it piggybacks on the installation of another program.
It doesn’t tell the user about all of its principal and significant functions.
It affects the user’s system in unexpected ways.
It is difficult to remove.
It collects or transmits private information without the user’s knowledge.
It is bundled with other software and its presence is not disclosed.
Next, we had to better understand how UwS is being disseminated.
This varies quite a bit, but time and again, deception is at the heart of these tactics. Common UwS distribution tactics include:
unwanted ad injection
, misleading ads such as “trick-to-click”, ads disguised as ‘download’ or ‘play’ buttons, bad software downloader practices, misleading or missing disclosures about what the software does, hijacked browser default settings, annoying system pop-up messages, and more.
Here are a few specific examples:
Deceptive ads leading to UwS downloads
Ads from unwanted ads injector taking over a New York Times page and sending the user to phone scams
Unwanted ad injector inserts ads on the Google search results page
New tab page is overridden by UwS
UwS hijacks Chrome navigations and directs users to a scam tech support website
One year of progress
Because UwS touches so many different parts of people’s online experiences, we’ve worked to fight it on many different fronts. Weaving UwS detection into Safe Browsing has been critical to this work, and we’ve pursued other efforts as well—here’s an overview:
We now include UwS in
Safe Browsing
and its
API
, enabling people who use Chrome and other browsers to see warnings before they go to sites that contain UwS. The red warning below appears in Chrome.
We launched the
Chrome Cleanup Tool
, a one-shot UwS removal tool that has helped clean more than 40 million devices. We shed more light on a common symptom of UwS—
unwanted ad injectors
. We outlined
how they make money
and
launched a new filter
in DoubleClick Bid Manager that removes impressions generated by unwanted ad injectors before bids are made.
We started using
UwS as a signal in search
to reduce the likelihood that sites with UwS would appear in search results.
We started
disabling
Google ads that lead to sites with UwS downloads.
It’s still early, but these changes have already begun to move the needle.
UwS-related Chrome user complaints have fallen. Last year, before we rolled-out our new policies, these were 40% of total complaints and now they’re 20%.
We’re now showing more than 5 million Safe Browsing warnings per day on Chrome related to UwS to ensure users are aware of a site’s potential risks.
We helped more than 14 million users remove over 190 deceptive Chrome extensions from their devices.
We
reduced the number of UwS warnings
that users see via AdWords by 95%, compared to last year. Even prior to last year, less than 1% of UwS downloads were due to AdWords.
However, there is still a long way to go. 20% of all feedback from Chrome users is related to UwS and we believe 1 in 10 Chrome users have hijacked settings or unwanted ad injectors on their machines. We expect users of other browsers continue to suffer from similar issues; there is lots of work still to be done.
Looking ahead: broad industry participation is essential
Given the complexity of the UwS ecosystem, the involvement of players across the industry is key to making meaningful progress in this fight. This chain is only as strong as its weakest links: everyone must work to develop and enforce strict, clear policies related to major sources of UwS.
If we’re able, as an industry, to enforce these policies, then everyone will be able to provide better experiences for their users. With this in mind, we’re very pleased to see that the
FTC recently warned consumers
about UwS and characterizes UwS as a
form of malware
. This is an important step toward uniting the online community and focusing good actors on the common goal of eliminating UwS.
We’re still in the earliest stages of the fight against UwS, but we’re moving in the right direction. We’ll continue our efforts to protect users from UwS and work across the industry to eliminate these bad practices.
A new version of Authenticator for Android
December 7, 2015
Posted by Alexei Czeskis, Software Engineer
Authenticator for Android is used by millions of users and, combined with
2-Step Verification
, it provides an extra layer of protection for Google Accounts.
Our latest version has some cool new features. You will notice a new icon and a refreshed design. There's also support for
Android Wear
devices, so you'll be able to get verification codes from compatible devices, like your watch.
The new Authenticator also comes with a developer preview of support for NFC Security Key, based on the FIDO Universal 2nd Factor (U2F) protocol via NFC. Play Store will prompt for the NFC permission before you install this version of Authenticator.
Developers who want to learn more about U2F can refer to FIDO's
specifications
. Additionally, you can try it out at
https://u2fdemo.appspot.com
. Note that you'll need an Android device running the latest versions of Google Chrome and Authenticator and also a
Security Key
with NFC support.
You can find the latest
Authenticator for Android on the Play Store
.
Protecting hundreds of millions more mobile users
December 7, 2015
Posted by Noé Lutz, Nathan Parker, Stephan Somogyi; Google Chrome and Safe Browsing Teams
Google Safe Browsing has been protecting well over a billion desktop users against
malware, unwanted software, and social engineering sites
on the web for years. Today, we’re pleased to announce that we’ve extended our protective umbrella to hundreds of millions of Chrome users on Android.
How To Get It
If you’re an Android user, you probably already have it! This new Safe Browsing client on Android is part of Google Play Services, starting with version 8.1. The first app to use it is Chrome, starting with version 46—we’re now protecting all Android Chrome users by default. If you look at Chrome’s Settings > Privacy menu, you can verify that Safe Browsing is enabled and that you’re protected. Chrome warns you about dangerous sites as shown below. It does this
while preserving your privacy, just like on desktop
.
What Came Before
The Android platform and the Play Store have long had protection against potentially harmful apps. And as our adversaries have improved their skills in trying to evade us, we’ve improved our detection, keeping Android app users safe. But not all dangers to mobile users come from apps.
What’s New
Social engineering
—and phishing in particular—requires different protection; we need to keep an up-to-date list of bad sites on the device to make sure we can warn people before they browse into a trap. Providing this protection on a mobile device is much more difficult than on a desktop system, in no small part because we have to make sure that list doesn’t get stale, yet:
Mobile data costs money for most users around the world. Data size matters a lot.
Mobile data speeds are slower than Wi-Fi in much of the world. Data size matters a lot.
Cellular connectivity quality is much more uneven, so getting the right data to the device quickly is critically important. Data size matters a lot.
Maximum Protection Per Bit
Bytes are big: our mantra is that every single bit that Safe Browsing sends a mobile device must improve protection. Network bandwidth and battery are the scarcest resources on a mobile device, so we had to carefully rethink how to best protect mobile users. Some social engineering attacks only happen in certain parts of the world, so we only send information that protects devices in the geographic regions they’re in.
We also make sure that we send information about the riskiest sites first: if we can only get a very short update through, as is often the case on lower-speed networks in emerging economies, the update really has to count. We also worked with Google’s compression team to make the little data that we do send as small as possible.
Together with the Android Security team, we made the software on the device extra stingy with memory and processor use, and careful about minimizing network traffic. All of these details matter to us; we must not waste our users’ data plans, or a single moment of their battery life.
More Mobile
We hunt badness on the Internet so that you don’t discover it the hard way, and our protection should never be an undue burden on your networking costs or your device’s battery. As more of the world relies on the mobile web, we want to make sure you’re as safe as can be, as efficiently as possible.
Safe Browsing protection from even more deceptive attacks
November 13, 2015
Posted by Emily Schechter, Program Manager and Noé Lutz, Software Engineer
Safe Browsing
has been protecting over one billion people from
traditional phishing attacks
on the web for more than eight years. The threat landscape is constantly changing—bad actors on the web are using more and different types of deceptive behavior to trick you into performing actions that you didn’t intend or want, so we’ve expanded protection to include social engineering.
Social engineering is a much broader category than traditional phishing and encompasses more types of deceptive web content. A social engineering attack happens when either:
The content pretends to act, or looks and feels, like a trusted entity — like a bank or government.
The content tries to trick you into doing something you’d only do for a trusted entity — like sharing a password or calling tech support.
Below are some examples of social engineering attacks that try to trick you into thinking the content is delivered by Google or Chrome. Other trusted brands are also commonly abused for social engineering attacks.
This page tries to trick you into downloading and executing malware or unwanted software. It uses Chrome’s logo and name to confuse you into believing the site is operated by Google. Content like this may include an inconspicuous legal disclaimer that states it is not affiliated with Google. This does not change the deceptive nature of this content—as always, use caution when downloading files from the web.
This is a fake tech phone support page. This page mimics a warning and may trick you into calling a third-party company that pretends to be Google or some other trusted entity, but charges a fee for support. (Chrome does not offer paid remote support).
This is a fake Google login page. It might trick you into disclosing your account login credentials. Other phishing sites like this could trick you into giving up other personal information such as credit card information. Phishing sites may look exactly like the real site—so be sure to look at the address bar to check that the URL is correct, and also check to see that the website begins with https://. See more information
here
.
If we identify that a web page contains social engineering content, Chrome will warn you by displaying the following warning:
(If you believe Safe Browsing has classified a web page in error, please report it
here
.)
We'll continue to improve Google's Safe Browsing protection to help more people stay safer online. Check out the
Safe Browsing Transparency Report
to find out more.
New Research: Encouraging trends and emerging threats in email security
November 12, 2015
Posted by Elie Bursztein, Anti-Fraud and Abuse Research and Nicolas Lidzborski, Gmail Security Engineering Lead
We’re constantly working to help make email more secure for everyone. These efforts are reflected in security protections like
default HTTPS
in Gmail as well as our
Safer Email Transparency report
, which includes information about email security beyond just Gmail.
To that end, in partnership with the University of Michigan and the University of Illinois, we’re publishing the results of a
multi-year study
that measured how email security has evolved since 2013. While Gmail was the foundation of this research, the study’s insights apply to email more broadly, not unlike our
Safer Email Transparency report
. It’s our hope that these findings not only help make Gmail more secure, but will also be used to help protect email users everywhere as well.
Email security strengthens, industry-wide
The study showed that email is more secure today than it was two years ago. Here are some specific findings:
Newer security challenges and how we can address them
Our study identified several new security challenges as well.
First, we found regions of the Internet actively preventing message encryption by tampering with requests to initiate SSL connections. To mitigate this attack, we are working closely with partners through the industry association
M3AAWG
to strengthen “opportunistic TLS” using technologies that we pioneered with Chrome to protect websites against interception.
Second, we uncovered malicious DNS servers publishing bogus routing information to email servers looking for Gmail. These nefarious servers are like telephone directories that intentionally list misleading phone numbers for a given name. While this type of attack is rare, it’s very concerning as it could allow attackers to censor or alter messages before they are relayed to the email recipient.
While these threats do not affect Gmail to Gmail communication, they may affect messaging between providers. To notify our users of potential dangers, we are developing in-product warnings for Gmail users that will display when they receive a message through a non-encrypted connection. These warnings will begin to roll-out in the coming months.
All email services—Gmail included—depend on the trust of their users. Partnering with top researchers helps us make the email ecosystem as a whole safer and more secure for everyone. Security threats won’t disappear, but studies like these enable providers across the industry to fight them with better, more powerful protections today and going forward.
[This work was made possible thanks to the contribution of many Googlers including Vijay Eranti, Kurt Thomas, John Rae-Grant, and Mark Risher.]
Sustaining Digital Certificate Security
October 28, 2015
Posted by Ryan Sleevi, Software Engineer
This post updates our
previous notification
of a misissued certificate for google.com
Following our notification, Symantec published
a report
in response to our inquiries and disclosed that 23 test certificates had been issued without the domain owner’s knowledge covering five organizations, including Google and Opera.
However, we were still able to find several more questionable certificates using only the Certificate Transparency logs and a few minutes of work. We shared these results with other root store operators on October 6th, to allow them to independently assess and verify our research.
Symantec performed another audit and, on October 12th, announced that they had found an additional
164 certificates
over 76 domains and
2,458 certificates
issued for domains that were never registered.
It’s obviously concerning that a CA would have such a long-running issue and that they would be unable to assess its scope after being alerted to it and conducting an audit. Therefore we are firstly going to require that as of June 1st, 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency. In this case, logging of non-EV certificates would have provided significantly greater insight into the problem and may have allowed the problem to be detected sooner.
After this date, certificates newly issued by Symantec that do not conform to the Chromium Certificate Transparency policy may result in interstitials or other problems when used in Google products.
More immediately, we are requesting of Symantec that they further update their public incident report with:
A post-mortem analysis that details why they did not detect the additional certificates that we found.
Details of each of the failures to uphold the relevant Baseline Requirements and EV Guidelines and what they believe the individual root cause was for each failure.
We are also requesting that Symantec provide us with a detailed set of steps they will take to correct and prevent each of the identified failures, as well as a timeline for when they expect to complete such work. Symantec may consider this latter information to be confidential and so we are not requesting that this be made public.
Following the implementation of these corrective steps, we expect Symantec to undergo a Point-in-time Readiness Assessment and a third-party security audit. The point-in-time assessment will establish Symantec’s conformance to each of these standards:
WebTrust Principles and Criteria for Certification Authorities
WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security
WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL
The third-party security audit must assess:
The veracity of Symantec’s claims that at no time private keys were exposed to Symantec employees by the tool.
That Symantec employees could not use the tool in question to obtain certificates for which the employee controlled the private key.
That Symantec’s audit logging mechanism is reasonably protected from modification, deletion, or tampering, as described in Section 5.4.4 of their CPS.
We may take further action as additional information becomes available to us.
Behind the red warning: more info about online site safety
October 20, 2015
Posted by
Adrienne Porter Felt, Chrome Security Engineer and Warning Wizard
Emily Schechter, Safe Browsing Program Manager and Menace to Malware
Ke Wang, Safe Browsing Engineer and Developer of Defense
You’re browsing the web, checking out the latest news on your favorite band, when suddenly you see a red warning screen: “The site ahead contains malware.” These warnings aren’t new—since 2006, Google Safe Browsing has shown them when you navigate to an unsafe site. The warnings protect you from harms caused by unsafe sites, such as malware infections and phishing attacks. But it hasn’t always been clear why a specific website triggers a warning, and you may want to learn more.
To demystify these warnings, we’re launching a
Site Status section
in the Transparency Report. The next time you come across a Safe Browsing warning, you can search for the blocked website in the Transparency Report to learn why it’s been flagged by our systems.
The new Site Status section of the Transparency Report replaces our previous
Safe Browsing diagnostic page
. It includes a clearer interface and simpler explanations of the issues, such as details for sites that host
unwanted software
. We’ve added it to the Transparency Report so that the Safe Browsing section of the report is a one-stop shop for information to help you understand what Safe Browsing is and how it works.
If a favorite website shows up as “dangerous,” it’s often due to user-uploaded bad content or a temporary malware infection. The Site Status will return to normal once the webmaster has cleaned up the website. To help speed up this process, we automatically give the webmaster a heads-up about the problem via
Search Console
; if you use
Google Analytics
, we’ll also warn you there if your site has malware on it. (Webmasters, check the
help center
to learn how to remove malware from your websites.)
We’re constantly working to keep users safe and informed online. Visit the updated Site Status section in the
Transparency Report
to experience it yourself.
Labels
#sharethemicincyber
#supplychain #security #opensource
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome enterprise
chrome security
connected devices
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
iot security
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
security rewards program
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
VDP
vulnerabilities
workshop
Archive
2024
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2023
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2022
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Aug
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
2010
Nov
Oct
Sep
Aug
Jul
May
Apr
Mar
2009
Nov
Oct
Aug
Jul
Jun
Mar
2008
Dec
Nov
Oct
Aug
Jul
May
Feb
2007
Nov
Oct
Sep
Jul
Jun
May
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow