Posted by Adam Mein, Technical Program Manager, Google Security Team

In November 2010, we introduced a different kind of vulnerability reward program that encourages people to find and report security bugs in Google’s web applications. By all available measures, the program has been a big success. Before we embark further, we wanted to pause and share a few things that we’ve learned from the experience.

“Bug bounty” programs open up vulnerability research to wider participation.

On the morning of our announcement of the program last November, several of us guessed how many valid reports we might see during the first week. Thanks to an already successful Chromium reward program and a healthy stream of regular contributions to our general security submissions queue, most estimates settled around 10 or so. At the end of the first week, we ended up with 43 bug reports. Over the course of the program, we’ve seen more than 1100 legitimate issues (ranging from low severity to higher) reported by over 200 individuals, with 730 of those bugs qualifying for a reward. Roughly half of the bugs that received a reward were discovered in software written by approximately 50 companies that Google acquired; the rest were distributed across applications developed by Google (several hundred new ones each year). Significantly, the vast majority of our initial bug reporters had never filed bugs with us before we started offering monetary rewards.

Developing quality bug reports pays off... for everyone.

A well-run vulnerability reward program attracts high quality reports, and we’ve seen a whole lot of them. To date we’ve paid out over $410,000 for web app vulnerabilities to directly support researchers and their efforts. Thanks to the generosity of these bug reporters, we have also donated $19,000 to charities of their choice. It’s not all about money, though. Google has gotten better and stronger as a result of this work. We get more bug reports, which means we get more bug fixes, which means a safer experience for our users.

Bug bounties — the more, the merrier!

We benefited from looking at examples of other types of vulnerability reward programs when designing our own. Similarly, in the months following our reward program kick-off, we saw other companies developing reward programs and starting to focus more on web properties. Over time, these programs can help companies build better relationships with the security research community. As the model replicates, the opportunity to improve the overall security of the web broadens.

And with that, we turn toward the year ahead. We’re looking forward to new reports and ongoing relationships with the researchers who are helping make Google products more secure.

Posted by Adrian Ludwig, Android Security Engineer

We frequently get asked about how we defend Android users from malware and other threats. As the Android platform continues its tremendous growth, people wonder how we can maintain a trustworthy experience with Android Market while preserving the openness that remains a hallmark of our overall approach. We’ve been working on lots of defenses, and they have already made a real and measurable difference for our users’ security. Read more about how we defend against malware in Android Market on the Google Mobile Blog here.

(Cross-posted from the Gmail Blog)

Posted by Adam Dawes, Product Manager

Email phishing, in which someone tries to trick you into revealing personal information by sending fake emails that look legitimate, remains one of the biggest online threats. One of the most popular methods that scammers employ is something called domain spoofing. With this technique, someone sends a message that seems legitimate when you look at the “From” line even though it’s actually a fake. Email phishing is costing regular people and companies millions of dollars each year, if not more, and in response, Google and other companies have been talking about how we can move beyond the solutions we’ve developed individually over the years to make a real difference for the whole email industry.

Industry groups come and go, and it’s not always easy to tell at the beginning which ones are actually going to generate good solutions. When the right contributors come together to solve real problems, though, real things happen. That’s why we’re particularly optimistic about today’s announcement of DMARC.org, a passionate collection of companies focused on significantly cutting down on email phishing and other malicious mail.

Building upon the work of previous mail authentication standards like SPF and DKIM, DMARC is responding to domain spoofing and other phishing methods by creating a standard protocol by which we’ll be able to measure and enforce the authenticity of emails. With DMARC, large email senders can ensure that the email they send is being recognized by mail providers like Gmail as legitimate, as well as set policies so that mail providers can reject messages that try to spoof the senders’ addresses.

We’ve been active in the leadership of the DMARC group for almost two years, and now that Gmail and several other large mail senders and providers — namely Facebook, LinkedIn, and PayPal — are actively using the DMARC specification, the road is paved for more members of the email ecosystem to start getting a handle on phishing. Our recent data indicates that roughly 15% of non-spam messages in Gmail are already coming from domains protected by DMARC, which means Gmail users like you don’t need to worry about spoofed messages from these senders. The phishing potential plummets when the system just works, and that’s what DMARC provides.

If you’re a large email sender and you want to try out the DMARC specification, you can learn more at the DMARC website. Even if you’re not ready to take on the challenge of authenticating all your outbound mail just yet, there’s no reason to not sign up to start receiving reports of mail that fraudulently claims to originate from your address. With further adoption of DMARC, we can all look forward to a more trustworthy overall experience with email.

Posted by Alma Whitten, Director of Privacy, Product and Engineering

(Cross-posted from the Official Google Blog)

Does this person sound familiar? He can’t be bothered to type a password into his phone every time he wants to play a game of Angry Birds. When he does need a password, maybe for his email or bank website, he chooses one that’s easy to remember like his sister’s name—and he uses the same one for each website he visits. For him, cookies come from the bakery, IP addresses are the locations of Intellectual Property and a correct Google search result is basically magic.

Most of us know someone like this. Technology can be confusing, and the industry often fails to explain clearly enough why digital literacy matters. So today in the U.S. we’re kicking off Good to Know, our biggest-ever consumer education campaign focused on making the web a safer, more comfortable place. Our ad campaign, which we introduced in the U.K. and Germany last fall, offers privacy and security tips: Use 2-step verification! Remember to lock your computer when you step away! Make sure your connection to a website is secure! It also explains some of the building blocks of the web like cookies and IP addresses. Keep an eye out for the ads in newspapers and magazines, online and in New York and Washington, D.C. subway stations.



The campaign and Good to Know website build on our commitment to keeping people safe online. We’ve created resources like privacy videos, the Google Security Center, the Family Safety Center and Teach Parents Tech to help you develop strong privacy and security habits. We design for privacy, building tools like Google Dashboard, Me on the Web, the Ads Preferences Manager and Google+ Circles—with more on the way.

We encourage you to take a few minutes to check out the Good to Know site, watch some of the videos, and be on the lookout for ads in your favorite newspaper or website. We hope you’ll learn something new about how to protect yourself online—tips that are always good to know!

Update 1/17: Updated to include more background on Good to Know.

Posted by Nav Jagpal, Security Team

For the past year, we’ve been sending notifications to network administrators registered through the Safe Browsing Alerts for Network Administrators service when our automated tools find phishing URLs or compromised sites that lead to malware on their networks. These notifications provide administrators with important information to help them improve the security of their networks.

Today we’re adding distribution domains to the set of information we share. These are domains that are responsible for launching exploits and serving malware. Unlike compromised sites, which are often run by innocent webmasters, distribution domains are set up with the primary purpose of serving malicious content.

If you’re a network administrator and haven’t yet registered your AS, you can do so here.

Posted by Brian Ryner, Security Team

In May we announced that we are ending support for the Safe Browsing protocol version 1 on December 1 in order to focus our resources on the new version 2 API and the lookup service. These new APIs provide simpler and more efficient access to the same data, and they use significantly less bandwidth. If you haven't yet migrated off of the version 1 API, we encourage you to do so as soon as possible. Our earlier post contains links to documentation for the new protocol version and other resources to help you make the transition smoothly.

After December 1, we will remove all data from the version 1 API list to ensure that any remaining clients do not have false positives in their database. After January 1, 2012, we will turn off the version 1 service completely, and all requests will return a 404 error.

Thanks for your cooperation, and enjoy using the next generation of Safe Browsing.

Posted by Adam Langley, Security Team

Last year we introduced HTTPS by default for Gmail and encrypted search. We’re pleased to see that other major communications sites are following suit and deploying HTTPS in one form or another. We are now pushing forward by enabling forward secrecy by default.

Most major sites supporting HTTPS operate in a non-forward secret fashion, which runs the risk of retrospective decryption. In other words, an encrypted, unreadable email could be recorded while being delivered to your computer today. In ten years time, when computers are much faster, an adversary could break the server private key and retrospectively decrypt today’s email traffic.

Forward secrecy requires that the private keys for a connection are not kept in persistent storage. An adversary that breaks a single key will no longer be able to decrypt months’ worth of connections; in fact, not even the server operator will be able to retroactively decrypt HTTPS sessions.

Forward secret HTTPS is now live for Gmail and many other Google HTTPS services(*), like SSL Search, Docs and Google+. We have also released the work that we did on the open source OpenSSL library that made this possible. You can check whether you have forward secret connections in Chrome by clicking on the green padlock in the address bar of HTTPS sites. Google’s forward secret connections will have a key exchange mechanism of ECDHE_RSA.

We would very much like to see forward secrecy become the norm and hope that our deployment serves as a demonstration of the practicality of that vision.


(* Chrome, Firefox (all platforms) and Internet Explorer (Vista or later) support forward secrecy using elliptic curve Diffie-Hellman. Initially, only Chrome and Firefox will use it by default with Google services because IE doesn’t support the combination of ECDHE and RC4. We hope to support IE in the future.)

Posted by Nav Jagpal, Security Team

Today, we’re congratulating Safe Browsing Alerts for Network Administrators on its graduation from Labs to its new home at http://www.google.com/safebrowsing/alerts/

We announced the tool about a year ago and have received a lot of positive feedback. Network administrators, large and small, are using the information we provide about malware and phishing URLs to clean up their networks and help webmasters make their sites safer. Earlier this year, AusCert recognized our efforts by awarding Safe Browsing Alerts for Network Administrators the title of “Best Security Initiative.”

If you’re a network administrator and haven’t yet registered your AS, you can do so here.

Posted by Eric Grosse, VP Security Engineering

We learned last week that the compromise of a Dutch company involved with verifying the authenticity of websites could have put the Internet communications of many Iranians at risk, including their Gmail. While Google’s internal systems were not compromised, we are directly contacting possibly affected users and providing similar information below because our top priority is to protect the privacy and security of our users.

While users of the Chrome browser were protected from this threat, we advise all users in Iran to take concrete steps to secure their accounts:

1. Change your password. You may have already been asked to change your password when you signed in to your Google Account. If not, you can change it here.
2. Verify your account recovery options. Secondary email addresses, phone numbers, and other information can help you regain access to your account if you lose your password. Check to be sure your recovery options are correct and up to date here.
3. Check the websites and applications that are allowed to access your account, and revoke any that are unfamiliar here.
4. Check your Gmail settings for suspicious forwarding addresses or delegated accounts.
5. Pay careful attention to warnings that appear in your web browser and don’t click past them.

For more ways to secure your account, you can visit http://www.google.com/help/security. If you believe your account has been compromised, you can start the recovery process here.

Posted by Heather Adkins, Information Security Manager

Today we received reports of attempted SSL man-in-the-middle (MITM) attacks against Google users, whereby someone tried to get between them and encrypted Google services. The people affected were primarily located in Iran. The attacker used a fraudulent SSL certificate issued by DigiNotar, a root certificate authority that should not issue certificates for Google (and has since revoked it).

Google Chrome users were protected from this attack because Chrome was able to detect the fraudulent certificate.

To further protect the safety and privacy of our users, we plan to disable the DigiNotar certificate authority in Chrome while investigations continue. Mozilla also moved quickly to protect its users. This means that Chrome and Firefox users will receive alerts if they try to visit websites that use DigiNotar certificates. Microsoft also has taken prompt action.

To help deter unwanted surveillance, we recommend that users, especially those in Iran, keep their web browsers and operating systems up to date and pay attention to web browser security warnings.

Update Aug 30: Added information about Microsoft's response.

Update Sept 3: Our top priority is to protect the privacy and security of our users. Based on the findings and decision of the Dutch government, as well as conversations with other browser makers, we have decided to reject all of the Certificate Authorities operated by DigiNotar. We encourage DigiNotar to provide a complete analysis of the situation.