Security Blog
The latest news and insights from Google on security and safety on the Internet
More Encryption, More Notifications, More Email Security
March 24, 2016
Posted by Nicolas Lidzborski, Gmail Security Engineering Lead and Jonathan Pevarnek,
Jigsaw
Engineer
Today, we’re announcing a variety of new protections that will help keep Gmail users even safer and promote email security best practices across the Internet as a whole.
New tools and industry standards make email even safer
On
Safer Internet Day
this year, we introduced a new visual element to Gmail that lets users know when they’ve received a message that wasn’t delivered using encryption or if they’re composing a message to a recipient whose email service doesn’t support TLS encryption. It’s the red lock icon featured below:
This has had an immediate, positive effect on Gmail security. In the 44 days since we introduced it, the amount of inbound mail sent over an encrypted connection
increased by 25%
. We’re very encouraged by this progress! Given the relative ease of implementing encryption and its significant benefits for users, we expect to see this progress continue.
However, as our recent
research
with the University of Michigan and University of Illinois shows, misconfigured or malicious parts of the Internet can still tamper with email encryption. To help ensure TLS encryption works as intended, we’ve teamed-up with a variety of industry partners — including Comcast, Microsoft, and Yahoo!— to submit a
draft IETF specification
for “SMTP Strict Transport Security.” With this new proposed standard, companies can ensure that mail will only be delivered through encrypted channels, and that any encryption failures should be reported for further analysis, helping shine the spotlight on any malfeasance occurring around the Internet.
Safe Browsing makes Gmail more secure
Since 2007,
Safe Browsing
has protected users across the web by warning them before they visit dangerous sites known for phishing, malware, and
Unwanted Software
. Over the years, we’ve brought the protections afforded by Safe Browsing to other Google products as well, including: Chrome,
Android
, Ads, Google Analytics, and more.
Safe Browsing already protects Gmail users by identifying potentially dangerous links in messages. Starting this week, Gmail users will begin to see warnings if they click these links, further extending this protection to different web browsers and email apps. The full-page warning will look like this:
Enhancing state-sponsored attack warnings
Since 2012
, we’ve warned Gmail users when we suspect they’ve been targeted by state-sponsored attackers:
These warnings are rare—fewer than 0.1% of users ever receive them—but they are critically important. The users that receive these warnings are often activists, journalists, and policy-makers taking bold stands around the world.
Today, we’re launching a new, full-page warning with instructions about how these users can stay safe. They may see these new warnings instead of, or in addition to, the existing ones.
The security of our users and their data is paramount. We’ll continue to build new protections, and work closely with the broader email ecosystem to support and improve standards such as TLS, that keep users safe.
Certificate Transparency for Untrusted CAs
March 21, 2016
Posted by Martin Smith, Software Engineer, Certificate Transparency
Today we are announcing a new Certificate Transparency log for a new set of root certificates: those that were once or are not yet trusted by browsers.
Certificate Transparency
(CT) data has a number of different uses, including protecting users from mis-issued certificates and providing webmasters and other interested parties with a public record of what certificates have been issued for domains.
Initially
, our logs included browser-trusted Certificate Authorities (CAs). However, there are two main classes of CA that can’t easily be included in the existing logs:
Those that were once trusted and have since been withdrawn from the root programs.
New CAs that are on the path to inclusion in browser trusted roots.
Including these in trusted logs is problematic for several reasons, including uncertainties around revocation policies and the possibility of cross-signing attacks being attempted by malicious third-parties.
However, visibility of these CAs’ activities is still useful, so we have created a new CT log for these certificates. This log will not be trusted by Chrome, and will provide a public record of certificates that are not accepted by the existing Google-operated logs.
The new log is accessible at
ct.googleapis.com/submariner
and is listed on our
Known Logs
page. It has the same API as the existing logs.
Initially, Submariner includes certificates chaining up to the set of root certificates that
Symantec
recently announced it had discontinued, as well as a
collection of additional roots
suggested to us that are pending inclusion in Mozilla.
Once Symantec’s affected certificates are no longer trusted by browsers, we will be withdrawing them from the trusted roots accepted by our existing logs (Aviator, Pilot, and Rocketeer).
Third parties are invited to suggest additional roots for potential inclusion in the new log by email to
google-ct-logs@googlegroups.com
.
Everyone is welcome to make use of the log to submit certificates and query data. We hope it will prove useful and help to improve web security.
BinDiff now available for free
March 18, 2016
Posted by Christian Blichmann, Software Engineer
BinDiff is a comparison tool for binary files that helps to quickly find differences and similarities in disassembled code. It is used by security researchers and engineers across the globe to identify and isolate fixes for vulnerabilities in vendor-supplied patches and to analyze multiple versions of the same binary. Another common use case is to transfer analysis results from one binary to another, helping to prevent duplicate analyses of, for example, malware binaries. This also helps to retain knowledge across teams of binary analysts where the individual workflows might vary from analyst to analyst.
More specifically, BinDiff can be used to:
Compare binary files for x86, MIPS, ARM/AArch64, PowerPC, and other architectures.
Identify identical and similar functions in different binaries.
Port function names, comments and local variable names from one disassembly to another.
Detect and highlight changes between two variants of the same function.
Here is a screenshot demonstrating what using BinDiff to display per-function differences looks like:
At Google, the BinDiff core engine powers a large-scale malware processing pipeline helping to protect both internal and external users. BinDiff provides the underlying comparison results needed to cluster the world's malware into related families with billions of comparisons performed so far.
Ever since zynamics
joined Google
in 2011, we have been committed to keeping our most valuable tools available to the security research community. We first lowered the price, and today we are taking the next logical step by making it available free of charge.
You can download BinDiff from the
zynamics web site
. It’s the current version, BinDiff 4.2 for both Linux and Windows. To use it, you also need the commercial Hex-Rays IDA Pro disassembler, 6.8 or later.
Happy BinDiff-ing!
Securing the web, together
March 15, 2016
Posted by Rutledge Chin Feman and Tim Willis, HTTPS Evangelists
Encryption keeps people’s information safe as it moves between their devices and Google, protecting it from interception and unauthorized access by attackers. With a modern encrypted connection, you can be confident that your data will be private and secure.
Today we are launching a new section of our
Transparency Report
to track the progress of encryption efforts—both at Google and on some of the web's most trafficked sites. Our aim with this project is to hold ourselves accountable and encourage others to encrypt so we can make the web even safer for everyone.
Here's an overview of what is included in the new report:
Google sites
Every week, we’ll update this report with progress we've made towards implementing HTTPS by default across Google’s services. We’ve long offered Gmail, Drive, and Search over HTTPS, and in the last year, we’ve begun to add traffic from more products, like
ads
and
Blogger
as well.
We're making positive strides, but we still have a ways to go.
This chart represents the percentage of requests to Google's servers that used encrypted connections. YouTube traffic is currently not included in this data.
We plan on adding additional Google products over time to increase the scope of this report.
Popular third-party sites
Our report also includes data about the
HTTPS connections on many popular sites across the web
, beyond Google. We've chosen these sites based on a combination of publicly-available
Alexa data
and our own Google internal data; we estimate they account for approximately 25% of all web traffic on the Internet.
Certificate Transparency
Websites use certificates to assert to users that they are legitimate, so browsers need to be able to check whether the certificate that you’re being presented is valid and appropriately issued. That is why this report also offers a
Certificate Transparency log viewer
, providing a web interface for users and site administrators to easily check and see who has issued a certificate for a website. For example, if you use this log viewer and search for google.com with ‘include expired' checked, you'll see the
mis-issued google.com certificate from September 2015
.
Encryption for everyone
Implementing HTTPS can be difficult—we know from experience! Some common obstacles include:
Older hardware and/or software that doesn’t support modern encryption technologies.
Governments and organizations that may block or otherwise degrade HTTPS traffic.
Organizations that may not have the desire or technical resources to implement HTTPS.
While there’s no one-size-fits-all solution to these challenges,
we’ve put together a resource for webmasters to use
as they work through this process. We also support industry-wide efforts, like EFF's ‘
Encrypt the Web
’ report, that aim to bring more of the web to HTTPS.
Implementing encryption is not easy work. But, as more people spend more of their time on the web, it’s an increasingly essential element of online security. We hope this report will provide a snapshot of our own encryption efforts and will encourage everyone to make HTTPS the default on the web, even faster.
Get Rich or Hack Tryin’
March 14, 2016
Posted by Nathan Parker, Chrome Defender and Tim Willis, Hacker Philanthropist
Since 2010, we've happily rewarded researchers who find and report security issues to us through Google’s Security Reward Program. Last year,
Google paid researchers more than $2,000,000 for their work
to make Google users safer.
It's no secret that Chrome takes security seriously. Today, we’re introducing two new changes to expand the Chrome Reward Program even further:
Increasing our top reward from $50,000 to $100,000.
Last year we introduced a $50,000 reward for the persistent compromise of a Chromebook in guest mode. Since we introduced the $50,000 reward, we haven’t had a successful submission. That said, great research deserves great awards, so we’re putting up a standing six-figure sum, available all year round with no quotas and no maximum reward pool.
Adding a Download Protection Bypass bounty.
We’re extending our reward program scope to include rewards for methods that bypass Chrome’s
Safe Browsing
download protection features
. There’s much more detail on this new category on
our rewards page
- be sure to take a look if you’re interested.
We look forward to seeing some amazing bugs and continuing to work with the security research community.
Happy hacking!
Scalable vendor security reviews
March 7, 2016
Posted by Lukas Weichselbaum and Daniel Fabian, Google Security
[Cross-posted on the
Google Open Source Blog
]
At Google, we assess the security of hundreds of vendors every year. We scale our efforts through automating much of the initial information gathering and triage portions of the vendor review process. To do this we've developed the Vendor Security Assessment Questionnaire (VSAQ), a collection of self-adapting questionnaires for evaluating multiple aspects of a vendor's security and privacy posture.
We've received feedback from many vendors who completed the questionnaires. Most vendors found them intuitive and flexible — and, even better, they've been able to use the embedded tips and recommendations to improve their security posture. Some also expressed interest in using the questionnaires to assess their own suppliers.
Based on this positive response, we've decided to open source the VSAQ Framework (Apache License Version 2) and the generally applicable parts of our questionnaires on GitHub:
https://github.com/google/vsaq
. We hope it will help companies spin up, or further improve their own vendor security programs. We also hope the base questionnaires can serve as a self-assessment tool for security-conscious companies and developers looking to improve their security posture.
The VSAQ Framework comes with four security questionnaire templates that can be used with the VSAQ rendering engine:
Web Application Security Questionnaire
Security & Privacy Program Questionnaire
Infrastructure Security Questionnaire
Physical & Data Center Security Questionnaire
All four base questionnaire templates can be readily extended with company-specific questions. Using the same questionnaire templates across companies may help to scale assessment efforts. Common templates can also minimize the burden on vendor companies, by facilitating the reuse of responses.
The
VSAQ Framework
comes with a simple client-side-only reference implementation that's suitable for self-assessments, for vendor security programs with a moderate throughput, and for just trying out the framework. For a high-throughput vendor security program, we recommend using the VSAQ Framework with a custom server-side component that fits your needs (the interface is quite simple).
Give VSAQ a try! A demo version of the VSAQ Framework is available here:
https://vsaq-demo.withgoogle.com
Excerpt from Security and Privacy Programs Questionnaire
Let us know how VSAQ works for you:
contact us
. We look forward to getting your feedback and continuing to make vendor reviews scalable — and maybe even fun!
CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow
February 16, 2016
Posted by Fermin J. Serna, Staff Security Engineer and Kevin Stadmeyer, Technical Program Manager
Have you ever been deep in the mines of debugging and suddenly realized that you were staring at something far more interesting than you were expecting? You are not alone! Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting.
Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit!
In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (
bug
). We couldn't immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of
Red Hat
had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.”
This was an amazing coincidence, and thanks to their hard work and cooperation, we were able to translate both teams’ knowledge into a comprehensive patch and regression test to protect glibc users.
That patch is available
here
.
Issue Summary:
Our initial investigations showed that the issue affected all the versions of glibc since 2.9. You should definitely update if you are on an older version though. If the vulnerability is detected, machine owners may wish to take steps to mitigate the risk of an attack.
The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack.
Google has found some mitigations that may help prevent exploitation if you are not able to immediately patch your instance of glibc. The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.
Technical information:
glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query.
Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated.
Under certain conditions a mismatch between the stack buffer and the new heap allocation will happen. The final effect is that the stack buffer will be used to store the DNS response, even though the response is larger than the stack buffer and a heap buffer was allocated. This behavior leads to the stack buffer overflow.
The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.
Exploitation:
Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post. With this
Proof of Concept
, you can verify if you are affected by this issue, and verify any mitigations you may wish to enact.
As you can see in the below debugging session we are able to reliably control EIP/RIP.
(gdb) x/i $rip
=> 0x7fe156f0ccce <_nss_dns_gethostbyname4_r+398>: req
(gdb) x/a $rsp
0x7fff56fd8a48: 0x4242424242424242 0x4242424242420042
When code crashes unexpectedly, it can be a sign of something much more significant than it appears; ignore crashes at your peril!
Failed exploit indicators, due to ASLR, can range from:
Crash on free(ptr) where ptr is controlled by the attacker.
Crash on free(ptr) where ptr is semi-controlled by the attacker since ptr has to be a valid readable address.
Crash reading from memory pointed by a local overwritten variable.
Crash writing to memory on an attacker-controlled pointer.
We would like to thank Neel Mehta, Thomas Garnier, Gynvael Coldwind, Michael Schaller, Tom Payne, Michael Haro, Damian Menscher, Matt Brown, Yunhong Gu, Florian Weimer, Carlos O’Donell and the rest of the glibc team for their help figuring out all details about this bug, exploitation, and patch development.
Building a safer web, for everyone
February 9, 2016
Posted by Gerhard Eschelbeck, VP, Security and Privacy
[Cross-posted from the
Official Google Blog
]
Today is
Safer Internet Day
, a moment for technology companies, nonprofit organizations, security firms, and people around the world to focus on online safety, together. To mark the occasion, we’re rolling out new tools, and some useful reminders, to help protect you from online dangers of all stripes—phishing, malware, and other threats to your personal information.
1. Keeping security settings simple
The
Security Checkup
is a quick way to control the security settings for your Google Account. You can add a recovery phone number so we can help if you’re ever locked out of your account, strengthen your password settings, see which devices are connected to your account, and more. If you complete the Security Checkup by February 11, you’ll also get
2GB of extra Google Drive storage
, which can be used across Google Drive, Gmail, and Photos.
Safer Internet Day is a great time to do it, but you can—and should!—take a Security Checkup on a regular basis. Start your Security Checkup by visiting
My Account
.
2. Informing Gmail users about potentially unsafe messages
If you and your Grandpa both use Gmail to exchange messages, your connections are
encrypted
and
authenticated
. That means no peering eyes can read those emails as they zoom across the web, and you can be confident that the message from your Grandpa in size 48 font (with no punctuation and a few misspellings) is really from him!
However, as our
Safer Email Transparency Report
explains, these things are not always true when Gmail interacts with other mail services. Today, we’re introducing changes in Gmail on the web to let people know when a received message was not encrypted, if you’re composing a message to a recipient whose email service doesn’t support
TLS encryption
, or when the sender’s domain couldn’t be authenticated.
Here’s the notice you’ll see in Gmail before you send a message to a service that doesn’t support TLS encryption. You’ll also see the broken lock icon if you receive a message that was sent without TLS encryption.
If you receive a message that can’t be authenticated, you’ll see a question mark where you might otherwise see a profile photo or logo:
3. Protecting you from bad apps
Dangerous apps that phish and steal your personal information, or hold your phone hostage and make you pay to unlock it, have no place on your smartphone—or any device, for that matter.
Google Play helps protect your Android device by rejecting bad apps that don’t comply with our
Play policies
. It also conducts more than 200 million daily security scans of devices, in tandem with our
Safe Browsing
system, for any signs of trouble. Last year, bad apps were installed on fewer than 0.13% of Android devices that install apps only from Google Play.
Learn more about these, and other Android security features — like app sandboxing,
monthly security updates
for Nexus and other devices, and our
Security Rewards Program
—in new research we’ve made public on our
Android blog
.
4. Busting bad advertising practices
Malicious advertising “botnets” try to send phony visitors to websites to make money from online ads. Botnets threaten the businesses of honest advertisers and publishers, and because they’re often made up of devices infected with malware, they put users in harm’s way too.
We've worked to keep botnets out of our ads systems, cutting them out of advertising revenue, and making it harder to make money from distributing malware and
Unwanted Software
. Now, as part of our effort to
fight bad ads online
, we’re reinforcing our existing botnet defenses by automatically filtering traffic from three of the top ad fraud botnets, comprising more than 500,000 infected user machines. Learn more about this update on the
Doubleclick blog
.
5. Moving the security conversation forward
Recent events—
Edward Snowden’s disclosures
, the
Sony Hack
, the
current conversation around encryption
, and more—have made online safety a truly mainstream issue. This is reflected both in news headlines, and popular culture: “
Mr. Robot
,” a TV series about hacking and cybersecurity, just won a Golden Globe for Best Drama, and
@SwiftOnSecurity
, a popular security commentator, is named after Taylor Swift.
But despite this shift, security remains a complex topic that lends itself to lively debates between experts...that are often unintelligible to just about everyone else. We need to simplify the way we talk about online security to enable everyone to understand its importance and participate in this conversation.
To that end, we’re teaming up with
Medium
to host a virtual roundtable about online security, present and future. Moderated by journalist and security researcher
Kevin Poulsen
, this project aims to present fresh perspectives about online security in a time when our attention is increasingly ruled by the devices we carry with us constantly. We hope you’ll
tune in
and check it out.
Online security and safety are being discussed more often, and with more urgency, than ever before. We hope you’ll take a few minutes today to learn how Google protects your data and how we can work toward a safer web, for everyone.
No More Deceptive Download Buttons
February 3, 2016
Posted by Lucas Ballard, Safe Browsing Team
In
November
, we announced that Safe Browsing would protect you from social engineering attacks - deceptive tactics that try to trick you into doing something dangerous, like installing
unwanted software
or
revealing your personal information
(for example, passwords, phone numbers, or credit cards). You may have encountered social engineering in a deceptive download button, or an image ad that falsely claims your system is out of date. Today, we’re expanding Safe Browsing protection to protect you from such deceptive embedded content, like social engineering ads.
Consistent with the social engineering policy we announced in November, embedded content (like ads) on a web page will be considered social engineering when they either:
Pretend to act, or look and feel, like a trusted entity — like your own device or browser, or the website itself.
Try 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 deceptive content, shown via ads:
This image claims that your software is out-of-date to trick you into clicking “update”.
This image mimics a dialogue from the FLV software developer -- but it does not actually originate from this developer.
These buttons seem like they will produce content that relate to the site (like a TV show or sports video stream) by mimicking the site’s look and feel. They are often not distinguishable from the rest of the page.
Our fight against unwanted software and social engineering is still just beginning. We'll continue to improve Google's
Safe Browsing
protection to help more people stay safe online.
Will my site be affected?
If visitors to your web site consistently see social engineering content, Google Safe Browsing may warn users when they visit the site. If your site is flagged for containing social engineering content, you should troubleshoot with Search Console. Check out our
social engineering help for webmasters
.
Google Security Rewards - 2015 Year in Review
January 28, 2016
Posted by Eduardo Vela Nava, Google Security
We launched our
Vulnerability Reward Program
in 2010 because rewarding security researchers for their hard work benefits everyone. These financial rewards help make our services, and the web as a whole, safer and more secure.
With an open approach, we’re able to consider a broad diversity of expertise for individual issues. We can also offer incentives for external researchers to work on challenging, time-consuming, projects that otherwise may not receive proper attention.
Last January, we summarized these efforts in our first ever
Security Reward Program ‘Year in Review’
. Now, at the beginning of another new year, we wanted to look back at 2015 and again show our appreciation for researchers’ important contributions.
2015 at a Glance
Once again, researchers from around the world—Great Britain, Poland, Germany, Romania, Israel, Brazil, United States, China, Russia, India to name a few countries—participated our program.
Here's an overview of the rewards they received and broader milestones for the program, as a whole.
Android Joins Security Rewards
Android was a newcomer to the Security Reward program initiative in 2015 and it made a significant and immediate impact as soon as it joined the program.
We
launched
our Android VRP in June, and by the end of 2015, we had paid more than $200,000 to researchers for their work, including our largest single payment of $37,500 to an Android security researcher.
New Vulnerability Research Grants Pay Off
Last year, we began to provide researchers with
Vulnerability Research Grants
, lump sums of money that researchers receive before starting their investigations. The purpose of these grants is to ensure that researchers are rewarded for their hard work, even if they don’t find a vulnerability.
We’ve already seen positive results from this program; here’s one example. Kamil Histamullin a researcher from Kasan, Russia received a VRP grant early last year. Shortly thereafter, he found an issue in YouTube Creator Studio which would have enabled anyone to delete any video from YouTube by simply changing a parameter from the URL. After the issue was reported, our teams quickly fixed it and the researcher was was rewarded $5,000 in addition to his initial research grant. Kamil detailed his findings on his
personal blog
in March.
Established Programs Continue to Grow
We continued to see important security research in our established programs in 2015. Here are just a few examples:
Tomasz Bojarski found 70 bugs on Google in 2015, and was our most prolific researcher of the year. He found a bug in our vulnerability submission form.
You may have read about Sanmay Ved, a researcher from who was able to buy google.com for one minute on Google Domains. Our initial financial reward to Sanmay—$ 6,006.13—spelled-out Google, numerically (squint a little and you’ll see it!). We then doubled this amount when
Sanmay donated his reward to charity
.
We also injected some new energy into these existing research programs and grants. In December, we
announced
that we'd be dedicating one million dollars specifically for security research related to Google Drive.
We’re looking forward to continuing the Security Reward Program’s growth in 2016. Stay tuned for more exciting reward program changes throughout the year.
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
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
.