Security Blog
The latest news and insights from Google on security and safety on the Internet
Final removal of trust in WoSign and StartCom Certificates
July 20, 2017
Posted by Andrew Whalley and Devon O'Brien, Chrome Security
As
previously announced
, Chrome has been in the process of removing trust from certificates issued by the CA WoSign and its subsidiary StartCom, as a result of several incidents not in keeping with the high standards expected of CAs.
We started the phase out in Chrome 56 by only trusting certificates issued prior to October 21st 2016, and subsequently restricted trust to a set of whitelisted hostnames based on the Alexa Top 1M. We have been reducing the size of the whitelist over the course of several Chrome releases.
Beginning with Chrome 61, the whitelist will be removed, resulting in full distrust of the existing WoSign and StartCom root certificates and all certificates they have issued.
Based on the
Chromium Development Calendar
, this change is visible in the
Chrome Dev channel
now, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.
Sites still using StartCom or WoSign-issued certificates should consider replacing these certificates as a matter of urgency to minimize disruption for Chrome users.
Identifying Intrusive Mobile Apps Using Peer Group Analysis
July 12, 2017
Posted by Martin Pelikan, Giles Hogben, and Ulfar Erlingsson of Google’s Security and Privacy team
Mobile apps entertain and assist us, make it easy to communicate with friends and family, and provide tools ranging from maps to electronic wallets. But these apps could also seek more device information than they need to do their job, such as personal data and sensor data from components, like cameras and GPS trackers.
To protect our users and help developers navigate this complex environment, Google analyzes privacy and security signals for each app in Google Play. We then compare that app to other apps with similar features, known as functional peers. Creating peer groups allows us to calibrate our estimates of users’ expectations and set adequate boundaries of behaviors that may be considered unsafe or intrusive. This process helps detect apps that collect or send sensitive data without a clear need, and makes it easier for users to find apps that provide the right functionality and respect their privacy. For example, most coloring book apps don’t need to know a user’s precise location to function and this can be established by analyzing other coloring book apps. By contrast, mapping and navigation apps need to know a user’s location, and often require GPS sensor access.
One way to create app peer groups is to create a fixed set of categories and then assign each app into one or more categories, such as tools, productivity, and games. However, fixed categories are too coarse and inflexible to capture and track the many distinctions in the rapidly changing set of mobile apps. Manual curation and maintenance of such categories is also a tedious and error-prone task.
To address this, Google developed a machine-learning algorithm for clustering mobile apps with similar capabilities. Our approach uses deep learning of vector embeddings to identify peer groups of apps with similar functionality, using app metadata, such as text descriptions, and user metrics, such as installs. Then peer groups are used to identify anomalous, potentially harmful signals related to privacy and security, from each app’s requested permissions and its observed behaviors. The correlation between different peer groups and their security signals helps different teams at Google decide which apps to promote and determine which apps deserve a more careful look by our security and privacy experts. We also use the result to help app developers improve the privacy and security of their apps.
Apps are split into groups of similar functionality, and in each cluster of similar apps the established baseline is used to find anomalous privacy and security signals.
These techniques build upon earlier ideas, such as using
peer groups
to analyze privacy-related signals,
deep learning for language models
to make those peer groups better, and
automated data analysis
to draw conclusions.
Many teams across Google collaborated to create this algorithm and the surrounding process. Thanks to several, essential team members including Andrew Ahn, Vikas Arora, Hongji Bao, Jun Hong, Nwokedi Idika, Iulia Ion, Suman Jana, Daehwan Kim, Kenny Lim, Jiahui Liu, Sai Teja Peddinti, Sebastian Porst, Gowdy Rajappan, Aaron Rothman, Monir Sharif, Sooel Son, Michael Vrable, and Qiang Yan.
For more information on Google’s efforts to detect and fight potentially harmful apps (PHAs) on Android, see
Google Android Security Team’s Classifications for Potentially Harmful Applications
.
References
S. Jana, Ú. Erlingsson, I. Ion (2015).
Apples and Oranges: Detecting Least-Privilege Violators with Peer Group Analysis
. arXiv:1510.07308 [cs.CR].
T. Mikolov, I. Sutskever, K. Chen, G. S. Corrado, J. Dean (2013).
Distributed Representations of Words and Phrases and their Compositionality
. Advances in Neural Information Processing Systems 26 (NIPS 2013).
Ú. Erlingsson (2016).
Data-driven software security: Models and methods
. Proceedings of the 29th IEEE Computer Security Foundations Symposium (CSF'16), Lisboa, Portugal.
Making the Internet safer and faster: Introducing reCAPTCHA Android API
June 9, 2017
Posted by Wei Liu, Product Manager, reCAPTCHA
When we launched reCAPTCHA ten years ago, we had a simple goal: enable users to visit the sites they love without worrying about spam and abuse. Over the years, reCAPTCHA has changed quite a bit. It evolved from the distorted text to
street numbers
and names, then
No CAPTCHA reCAPTCHA
in 2014 and Invisible reCAPTCHA in March this year.
By now, more than a billion users have benefited from reCAPTCHA and we continue to work to refine our protections.
reCAPTCHA protects users wherever they may be online. As the use of mobile devices has grown rapidly, it’s important to keep the mobile applications and data safe. Today, on reCAPTCHA’s tenth birthday, we’re glad to announce the first reCAPTCHA
Android API
as part of Google Play Services.
With this API, reCAPTCHA can better tell human and bots apart to provide a streamlined user experience on mobile. It will use our newest Invisible reCAPTCHA technology, which runs risk analysis behind the scene and has enabled millions of human users to pass through with zero click everyday. Now mobile users can enjoy their apps without being interrupted, while still staying away from spam and abuse.
reCAPTCHA Android API is included with Google
SafetyNet
, which provides services like device attestation and safe browsing to protect mobile apps. Mobile developers can do both the device and user attestations in the same API to mitigate security risks of their apps more efficiently. This adds to the
diversity of security protections
on Android:
Google Play Protect
to monitor for potentially harmful applications, device encryption, and regular security updates. Please
visit our site
to learn more about how to integrate with the reCAPTCHA Android API, and keep an eye out for our iOS library.
The journey of reCAPTCHA continues: we’ll make the Internet safer and easier to use for everyone (except bots).
Announcing Google Capture the Flag 2017
June 2, 2017
Posted by Josh Armour Security Program Manager
On 00:00:01 UTC of June 17th and 18th, 2017 we’ll be hosting the
online qualification round
of our second annual Capture The Flag (CTF) competition. In a ‘Capture the Flag’ competition we create security challenges and puzzles in which contestants can earn points for solving them. We will be inviting the top 10 finalist teams to a
secret undisclosed location
(spoiler alert:
it’s Google
) to compete onsite for a prize pool of over USD$31,337 and we’ll help subsidize travel to the venue for the finals to four participants for each of the ten finalist teams. In addition to grand prizes given at the finals, we’ll be rewarding some of the best and creative
write-ups
that we receive during the qualifying round. We want to give you an opportunity to share with the world the clever way you solve challenges.
Why do we host these competitions?
There are three main reasons why we host these competitions.
First, as we've seen with our
Vulnerability Reward Program
, the security community’s efforts help us better protect Google users, and the web as a whole. We’d like to give the people who solve a single challenge or two in a very clever way a chance to teach us and the security community, even if they don’t qualify for the finals. We also think that these challenges allows us to share with the world the types of problems our security team works on every day.
Second, we want to engage the broader security community and reach out to as many people involved as possible. At the
Google CTF
last year the winning team, ‘
Pasten
’ from Israel, earned over 4,700 points competing against 2,400 teams out of which 900 were able to solve at least one of our challenges. Thanks to the community's feedback, we used what we learned last year to make our CTF even better this time.
Lastly, we also want to grow the security community. Upon observing how last year's competition engaged new players from all over the world, we want to continue to create a safe space for people to come and learn while trying to solve challenges and having fun. Our internal security team employs several people who actively compete in CTF competitions in their spare time, so we value this activity and want to give back to and help grow our community.
We hope to virtually see you at the 2nd annual Google CTF on June 17th at 00:00:01 UTC. Check
this site (g.co/ctf)
for more details, as they become available.
The Big Picture
At Google, we aim to reward the hard work of hackers and security researchers. One such avenue is our Google Vulnerability Rewards Programs. Many of the best bug hunters enjoy participating in ‘Capture The Flag’ contests, and great vulnerabilities have been discovered and
disclosed at them
. During last year's Google CTF we also received some security bug reports in our scoreboard, for which we gave out rewards under the VRP. Another way we reward this community is with our
Vulnerability Research Grants Program
and our
Patch Rewards Program
. We look forward to the best contestants taking some time to explore our other programs for opportunities to make some money and help improve the security of the internet.
2017 Android Security Rewards
June 1, 2017
Posted by Mayank Jain and Scott Roberts, Android Security team
[Cross-posted from the
Android Developers Blog
]
Two years ago, we launched the
Android Security Rewards program
. In its second year, we've seen great progress. We received over 450 qualifying vulnerability reports from researchers and the average pay per researcher jumped by 52.3%. On top of that, the total Android Security Rewards payout doubled to $1.1 million dollars. Since it launched, we've rewarded researchers over $1.5 million dollars.
Here are some of the highlights from the Android Security Rewards program's second year:
There were no payouts for the top reward for a complete remote exploit chain leading to TrustZone or Verified Boot compromise, our highest award amount possible.
We paid 115 individuals with an average of $2,150 per reward and $10,209 per researcher.
We paid our top research team,
C0RE Team
, over $300,000 for 118 vulnerability reports.
We paid 31 researchers $10,000 or more.
Thank you to all the amazing
researchers
who submitted complete
vulnerability reports
to us last year.
Improvements to Android Security Rewards program
We’re constantly working to improve the Android Security Rewards program and today we’re making a few changes to all vulnerability reports filed after June 1, 2017.
Because every Android release includes more security protections and no researcher has claimed the top reward for an exploit chains in 2 years, we’re excited to increase our top-line payouts for these exploits.
Rewards for a remote exploit chain or exploit leading to TrustZone or Verified Boot compromise increase from $50,000 to $200,000.
Rewards for a remote kernel exploit increase from $30,000 to $150,000.
In addition to rewarding for vulnerabilities, we continue to work with the broad and diverse Android ecosystem to protect users from issues reported through our program. We collaborate with manufacturers to ensure that these issues are fixed on their devices through monthly
security updates
. Over 100 device models have a majority of their deployed devices running a security update from the last 90 days. This table shows the models with a majority of deployed devices running a security update from the last two months:
Manufacturer
Device
BlackBerry
PRIV
Fujitsu
F-01J
General Mobile
GM5 Plus d, GM5 Plus, General Mobile 4G Dual, General Mobile 4G
Gionee
A1
Google
Pixel XL, Pixel, Nexus 6P, Nexus 6, Nexus 5X, Nexus 9
LGE
LG G6, V20, Stylo 2 V, GPAD 7.0 LTE
Motorola
Moto Z, Moto Z Droid
Oppo
CPH1613, CPH1605
Samsung
Galaxy S8+, Galaxy S8, Galaxy S7, Galaxy S7 Edge, Galaxy S7 Active, Galaxy S6 Active, Galaxy S5 Dual SIM, Galaxy C9 Pro, Galaxy C7, Galaxy J7, Galaxy On7 Pro, Galaxy J2, Galaxy A8, Galaxy Tab S2 9.7
Sharp
Android One S1, 507SH
Sony
Xperia XA1, Xperia X
Vivo
Vivo 1609, Vivo 1601, Vivo Y55
Source
: Google, May 29, 2017
Thank you to everyone who helped make Android safer and stronger in the past year. Together, we made a huge investment in security research that helps Android users everywhere. If you want to get involved to make next year even better, check out our detailed
Program Rules
. For tips on how to submit complete reports, see
Bug Hunter University
.
New Built-In Gmail Protections to Combat Malware in Attachments
May 31, 2017
Posted by Sri Somanchi, Product Manager, Gmail anti-spam
Today we announced
new security features for Gmail customers
, including early phishing detection using machine learning, click-time warnings for malicious links, and unintended external reply warnings. In addition, we have also updated our defenses against malicious attachments.
Let’s take a deeper look at the new defenses against malicious attachments. We now correlate spam signals with attachment and sender heuristics, to predict messages containing new and unseen malware variants. These protections enable Gmail to better protect our users from zero-day threats, ransomware and polymorphic malware.
In addition, we
block
use of file types that carry a high potential for security risks including executable and javascript files.
Machine learning has helped Gmail achieve more than 99% accuracy in spam detection, and with these new protections, we’re able to reduce your exposure to threats by confidently rejecting hundreds of millions of additional messages every day.
Constantly improving our automatic protections
These new changes are just the latest in our ongoing work to improve our protections as we work to keep ahead of evolving threats. For many years, scammers have tried to use dodgy email attachments to sneak past our spam filters, and we’ve long blocked this potential abuse in a variety of
ways
, including:
Rejecting the message and notifying the sender if we detect a virus in an email.
Preventing you from sending a message with an infected attachment.
Preventing you from downloading attachments if we detect a virus.
While the bad guys never rest, neither do we.
These protections were made possible due to extensive contribution from Vijay Eranti & Timothy Schumacher (Gmail anti-spam) & Harish Gudelly (Google anti-virus) & Lucio Tudisco (G Suite anti-abuse)
OSS-Fuzz: Five months later, and rewarding projects
May 8, 2017
Posted by Oliver Chang, Abhishek Arya (Security Engineers, Chrome Security), Kostya Serebryany (Software Engineer, Dynamic Tools), and Josh Armour (Security Program Manager)
Five months ago, we
announced
OSS-Fuzz
, Google’s effort to help make open source software more secure and stable. Since then, our robot army has been working hard at
fuzzing
, processing 10 trillion test inputs a day. Thanks to the efforts of the open source community who have integrated a total of
47
projects, we’ve found over
1,000
bugs (
264
of which are potential security vulnerabilities).
Breakdown of the types of bugs we’re finding
Notable results
OSS-Fuzz has found numerous security vulnerabilities in several critical open source projects:
10
in FreeType2,
17
in FFmpeg,
33
in LibreOffice,
8
in SQLite 3,
10
in GnuTLS,
25
in PCRE2,
9
in gRPC, and
7
in Wireshark. We’ve also had at least one bug collision with another independent security researcher (CVE-2017-2801). (Some of the bugs are still view-restricted so links may show smaller numbers.)
Once a project is integrated into OSS-Fuzz, the continuous and automated nature of OSS-Fuzz means that we often catch these issues just hours after the regression is introduced into the upstream repository, so that the chances of users being affected is reduced.
Fuzzing not only finds memory safety related bugs, it can also find correctness or logic bugs. One example is a carry propagating bug in OpenSSL (
CVE-2017-3732
).
Finally, OSS-Fuzz has reported over 300
timeout and out-of-memory failures
(~75% of which got fixed). Not every project treats these as bugs, but fixing them enables OSS-Fuzz to find more interesting bugs.
Announcing rewards for open source projects
We believe that user and internet security as a whole can benefit greatly if more open source projects include fuzzing in their development process. To this end, we’d like to encourage more projects to participate and adopt the
ideal integration
guidelines that we’ve established.
Combined with fixing all the issues that are found, this is often a significant amount of work for developers who may be working on an open source project in their spare time. To support these projects, we are expanding our existing
Patch Rewards
program to include rewards for the integration of
fuzz targets
into OSS-Fuzz.
To qualify for these rewards, a project needs to have a large user base and/or be critical to global IT infrastructure. Eligible projects will receive $1,000 for initial integration, and up to $20,000 for ideal integration (the final amount is at our discretion). You have the option of donating these rewards to charity instead, and Google will double the amount.
To qualify for the ideal integration reward, projects must show that:
Fuzz targets are checked into their upstream repository and integrated in the build system with
sanitizer
support (up to $5,000).
Fuzz targets are
efficient
and provide good code coverage (>80%) (up to $5,000).
Fuzz targets are part of the official upstream development and regression testing process, i.e. they are maintained, run against old known crashers and the periodically updated
corpora
(up to $5,000).
The last $5,000 is a “
l33t
” bonus that we may reward at our discretion for projects that we feel have gone the extra mile or done something really awesome.
We’ve already started to contact the first round of projects that are eligible for the initial reward. If you are the maintainer or point of contact for one of these projects, you may also
reach out
to us in order to apply for our ideal integration rewards.
The future
We’d like to thank the existing contributors who integrated their projects and fixed countless bugs. We hope to see more projects integrated into OSS-Fuzz, and greater adoption of fuzzing as standard practice when developing software.
Protecting You Against Phishing
May 5, 2017
Posted by Mark Risher, Director, Counter Abuse Technology
As many email users know, phishing attacks—or emails that impersonate a trusted source to trick users into sharing information—are a pervasive problem. If you use Gmail, you can rest assured that every day, millions of phishing emails are blocked from ever reaching your inbox.
This week, we defended against an email
phishing campaign
that tricked some of our users into inadvertently granting access to their contact information, with the intent to spread more phishing emails. We took quick action to revoke all access granted to the attacker as well as steps to reduce and prevent harm from future variants of this type of attack.
Here’s some background to help you understand how the campaign worked, how we addressed it, and how you can better protect yourself against attacks.
How the campaign worked and how we addressed it
Victims of this attack received an email that appeared to be an invite to a Google Doc from one of their contacts. When users clicked the link in the attacker’s email, it directed them to the attacker’s application, which requested access to the user’s account under the false pretense of gaining access to the Google Doc. If the user authorized access to the application (through a mechanism called OAuth), it used the user's contact list to send the same message to more people.
Upon detecting this issue, we immediately responded with a combination of automatic and manual actions that ended this campaign within an hour. We removed fake pages and applications, and pushed user-protection updates through Safe Browsing, Gmail, Google Cloud Platform, and other counter-abuse systems. Fewer than 0.1% of our users were affected by this attack, and we have taken steps to re-secure affected accounts.
We protect our users from phishing attacks in a number of ways, including:
Using machine learning-based detection of spam and phishing messages, which has contributed to 99.9% accuracy in spam detection.
Providing
Safe Browsing
warnings about dangerous links, within Gmail and across more than 2 billion browsers.
Preventing suspicious account sign-ins through dynamic, risk-based challenges.
Scanning email attachments for malware and other dangerous payloads.
In addition, we’re taking multiple steps to combat this type of attack in the future, including updating our policies and enforcement on OAuth applications, updating our anti-spam systems to help prevent campaigns like this one, and augmenting monitoring of suspicious third-party apps that request information from our users.
How users can protect themselves
We’re committed to keeping your Google Account safe, and have layers of defense in place to guard against sophisticated attacks of all types, from anti-hijacking systems detecting unusual behavior, to machine learning models that block malicious content, to protection measures in Chrome and through Safe Browsing that guard against visiting suspicious sites. In addition, here are a few ways users can further protect themselves:
Take the
Google Security Checkup
, paying particular attention to any applications or devices you no longer use, as well as any unrecognized devices.
Pay attention to
warnings and alerts
that appear in Gmail and other products.
Report
suspicious emails
and
other content
to Google.
How G Suite admins can protect their users
We’ve separately notified G Suite customers whose users were tricked into granting OAuth access. While no further admin or user action is required for this incident, if you are a G Suite admin, consider the following best practices to generally improve security:
Review and verify current
OAuth API access by third-parties
.
Run
OAuth Token audit log reports
to catch future inadvertent scope grants and set up automated email alerts in the Admin console using the
custom alerts feature
, or script it with the
Reports API
.
Turn on 2-step verification for your organization and use
security keys
.
Follow the
security checklist
if you feel that an account may be compromised.
Help prevent abuse of your brand in phishing attacks by publishing a
DMARC
policy for your organization.
Use
and enforce rules for
S/MIME encryption
.
Here is a list of more
tips and tools
to help you stay secure on the web.
Next Steps Toward More Connection Security
April 27, 2017
Posted by Emily Schechter, Chrome Security Team
In January, we
began our quest
to improve how Chrome communicates the connection security of HTTP pages. Chrome now marks HTTP pages as “Not secure” if they have password or credit card fields. Beginning in October 2017, Chrome will show the “Not secure” warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in
Incognito mode
.
Treatment of HTTP pages in Chrome 62
Our plan
to label HTTP sites as non-secure is taking place in gradual steps, based on increasingly broad criteria. Since the
change in Chrome 56
, there has been a 23% reduction in the fraction of navigations to HTTP pages with password or credit card forms on desktop, and we’re ready to take the next steps.
Passwords and credit cards are not the only types of data that should be private. Any type of data that users type into websites should not be accessible to others on the network, so starting in version 62 Chrome will show the “Not secure” warning when users type data into HTTP sites.
Treatment of HTTP pages with user-entered data in Chrome 62
When users browse Chrome with Incognito mode, they likely have increased expectations of privacy. However, HTTP browsing is not private to others on the network, so in version 62 Chrome will also warn users when visiting an HTTP page in Incognito mode.
Eventually, we plan to show the “Not secure” warning for all HTTP pages, even outside Incognito mode. We will publish updates as we approach future releases, but don’t wait to get started moving to HTTPS! HTTPS is
easier and cheaper than ever before
, and it enables both the best performance the web offers and powerful new features that are too sensitive for HTTP. Check out our
set-up guides
to get started.
New Research: Keeping fake listings off Google Maps
April 6, 2017
Posted by Doug Grundman, Maps Anti-Abuse, and Kurt Thomas, Security & Anti-Abuse Research
Google My Business
enables millions of business owners to create listings and share information about their business on Google Maps and Search, making sure everything is up-to-date and accurate for their customers. Unfortunately, some actors attempt to abuse this service to register fake listings in order to defraud legitimate business owners, or to
charge exorbitant service fees for services
.
Over a year ago, we teamed up with the University of California, San Diego to research the actors behind fake listings, in order to improve our products and keep our users safe. The full report,
“Pinning Down Abuse on Google Maps”
, will be presented tomorrow at the 2017
International World Wide Web Conference
.
Our study shows that fewer than 0.5% of local searches lead to fake listings. We’ve also improved how we verify new businesses, which has reduced the number of fake listings by 70% from its all-time peak back in June 2015.
What is a fake listing?
For over a year, we tracked the bad actors behind fake listings. Unlike email-based scams
selling knock-off products online
, local listing scams require physical proximity to potential victims. This fundamentally changes both the scale and types of abuse possible.
Bad actors posing as locksmiths, plumbers, electricians, and other contractors were the most common source of abuse—roughly 2 out of 5 fake listings. The actors operating these fake listings would cycle through non-existent postal addresses and disposable VoIP phone numbers even as their listings were discovered and disabled. The purported addresses for these businesses were irrelevant as the contractors would travel directly to potential victims.
Another 1 in 10 fake listings belonged to real businesses that bad actors had improperly claimed ownership over, such as hotels and restaurants. While making a reservation or ordering a meal was indistinguishable from the real thing, behind the scenes, the bad actors would deceive the actual business into paying referral fees for organic interest.
How does Google My Business verify information?
Google My Business currently verifies the information provided by business owners before making it available to users. For freshly created listings, we physically mail a postcard to the new listings’ address to ensure the location really exists. For businesses changing owners, we make an automated call to the listing’s phone number to verify the change.
Unfortunately, our research showed that these processes can be abused to get fake listings on Google Maps. Fake contractors would request hundreds of postcard verifications to non-existent suites at a single address, such as 123 Main St #456 and 123 Main St #789, or to stores that provided PO boxes. Alternatively, a phishing attack could maliciously repurpose freshly verified business listings by tricking the legitimate owner into sharing verification information sent either by phone or postcard.
Keeping deceptive businesses out — by the numbers
Leveraging our study’s findings, we’ve made significant changes to how we verify addresses and are even
piloting an advanced verification process
for locksmiths and plumbers. Improvements we’ve made include prohibiting bulk registrations at most addresses, preventing businesses from relocating impossibly far from their original address without additional verification, and detecting and ignoring intentionally mangled text in address fields designed to confuse our algorithms. We have also adapted our anti-spam machine learning systems to detect data discrepancies common to fake or deceptive listings.
Combined, here’s how these defenses stack up:
We detect and disable 85% of fake listings before they even appear on Google Maps.
We’ve reduced the number of abusive listings by 70% from its peak back in June 2015.
We’ve also reduced the number of impressions to abusive listings by 70%.
As we’ve shown, verifying local information comes with a number of unique anti-abuse challenges. While fake listings may slip through our defenses from time to time, we are constantly improving our systems to better serve both users and business owners.
Archive
2017
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
Google
on
Follow @google
Follow
Give us feedback in our
Product Forums
.
![[UNSET] (27).png](https://web-archive.nli.org.il/National_Library/20170827070107im_/https://lh5.googleusercontent.com/CR_TnXcPF5OVJNbGvw6TS6DPuKGuS68wJAEppBZgbISVSgiuWKzrJlUfgSk7oZoJJlpXvBr6tFrcSiJn2hqZYZlcve9RSHgmnuh8hwpr0Yd9idiLdtWktk5qIuO4rzWYdprdZyBU)
Follow