As the email says, the fastest way for a site to be removed from the malware list is for the webmaster to file a review request via Google Webmaster Tools. Google's automated scanners will periodically re-examine the site even if no such request is received, but the process will take longer. People.com.cn did not file a review request, but our scanners reviewed the site on October 23 and removed the malware warning after finding that the malicious ad was gone.

Malicious display ads are an increasingly common way for sites to unknowingly distribute malware. We recently wrote about the steps that Google takes to help protect our advertising networks. Also, other publishers have recently written about their experiences with deceptive display ads.

The Google Anti-Malware engineering team knows you have many questions related to our scanning and flagging of infected sites, some with short and simple answers and some with more complex answers. The short-answer questions are already -- we hope -- adequately handled on the Webmaster Forums; now we want to do a better job at answering the more complex questions.

To this end, we have created a Google Moderator page for you to submit your questions, and to vote on other webmasters' questions. In two weeks (on Friday the 28th of August), we will close the page and select a few of the top-rated questions. Over the course of the next several weeks, we will do our best to answer each of these in a write-up, to be published here and to the Webmaster Malware Forum.

We hope to repeat this exercise (with a fresh Moderator page) in the fall to give you the opportunity to ask more questions.

Thank you, and see you on the Moderator page!

The Google Anti-Malware engineering team knows you have many questions related to our scanning and flagging of infected sites, some with short and simple answers and some with more complex answers. The short-answer questions are already -- we hope -- adequately handled on the Webmaster Forums; now we want to do a better job at answering the more complex questions.

To this end, we have created a Google Moderator page for you to submit your questions, and to vote on other webmasters' questions. In two weeks (on Friday the 28th of August), we will close the page and select a few of the top-rated questions. Over the course of the next several weeks, we will do our best to answer each of these in a write-up, to be published here and to the Webmaster Malware Forum.

We hope to repeat this exercise (with a fresh Moderator page) in the fall to give you the opportunity to ask more questions.

Thank you, and see you on the Moderator page!

A few of the more interesting bugs we've researched recently include: this one in Opera uncovered by Michal Zalewski's <canvas> fuzzer; a HTTP 449 response code issue in IE found by Tavis Ormandy; contributions to Safari 4's security by Robert Swiecki, SkyLined, and Dean McNamee (and others); an XMLHttpRequest leak in Firefox discovered by Marius Schilder; and a cross-domain leak in Chrome / Safari (the two share a common base) unearthed by Chris Evans.

The collaboration works both ways. We'd like to thank the following browser vendors:
Microsoft for helping with SSL interactions with HTTP proxies, Mozilla for sharing fuzzers, and Apple for sharing and coordinating Webkit-based bugs.

Together as a security community, our combined efforts to find vulnerabilities in browsers, practice responsible disclosure, and get problems fixed before criminals exploit them help make the Internet an overall safer place for everyone. We'd also like to thank all those who have helped us by contributing to Google Chrome.

We've long advocated for — and demonstrated — a focus on strong security in web applications. We run our own business on Google Apps, and we strive to provide a high level of security to our users. We currently let people access a number of our applications — including Gmail, Google Docs, and Google Calendar, among others — via HTTPS, a protocol that establishes a secure connection between your browser and our servers.

Let's take a closer look at how this works in the case of Gmail. We know that tens of millions of Gmail users rely on it to manage their lives every day, and we have offered HTTPS access as an option in Gmail from the day we launched. If you choose to use HTTPS in Gmail, our systems are designed to maintain it throughout the email session — not just at login — so everything you do can be passed through a more secure connection. Last summer we made it even easier by letting Gmail users opt in to always use HTTPS every time they log in (no need to type or bookmark the "https").

Free, always-on HTTPS is pretty unusual in the email business, particularly for a free email service, but we see it as an another way to make the web safer and more useful. It's something we'd like to see all major webmail services provide.

In fact, we're currently looking into whether it would make sense to turn on HTTPS as the default for all Gmail users.

We know HTTPS is a good experience for many power users who've already turned it on as their default setting. And in this case, the additional cost of offering HTTPS isn't holding us back. But we want to more completely understand the impact on people's experience, analyze the data, and make sure there are no negative effects. Ideally we'd like this to be on by default for all connections, and we're investigating the trade-offs, since there are some downsides to HTTPS — in some cases it makes certain actions slower.

We're planning a trial in which we'll move small samples of different types of Gmail users to HTTPS to see what their experience is, and whether it affects the performance of their email. Does it load fast enough? Is it responsive enough? Are there particular regions, or networks, or computer setups that do particularly poorly on HTTPS?

Unless there are negative effects on the user experience or it's otherwise impractical, we intend to turn on HTTPS by default more broadly, hopefully for all Gmail users. We're also considering how to make this work best for other apps including Google Docs and Google Calendar (we offer free HTTPS for those apps as well).

Stay tuned, but we wanted to share our thinking on this, and to let you know we're always looking at ways to make the web more secure and more useful.

Update @ 1:00pm: We've had some more time to go through the report. There's a factual inaccuracy we wanted to point out: a cookie from Docs or Calendar doesn't give access to a Gmail session. The master authentication cookie is always sent over HTTPS — whether or not the user specified HTTPS-only for their Gmail account. But we can all agree on the benefits of HTTPS, and we're glad that the report recognizes our leadership role in this area. As the report itself points out, "Users of Microsoft Hotmail, Yahoo Mail, Facebook and MySpace are also vulnerable to [data theft and account hijacking]. Worst of all — these firms do not offer their customers any form of protection. Google at least offers its tech savvy customers a strong degree of protection from snooping attacks." We take security very seriously, and we're proud of our record of providing security for free web apps.

Update on June 26th: We've sent a response to the signatories of the letter. You can read it here.



The graph shows the top-10 malware sites as counted by the number of compromised web sites that referenced it. All domains on the top-10 list are suspected to have compromised more than 10,000 web sites on the Internet. The graph also contains arrows indicating when these domains where first listed via the Safe Browsing API and flagged in our search results as potentially dangerous.

Other malware researchers reported widespread compromises pointing to the domains gumblar.cn and martuz.cn, both of which made it on our top-10 list. For gumblar, we saw about 60,000 compromised sites; Martuz peaked at slightly over 35,000 sites. Beladen.net was also reported to be part of a mass compromise, but made it only to position 124 on the list with about 3,500 compromised sites.

To help make the Internet a safer place, our Safe Browsing API is freely available and is being used by browsers such as Firefox and Chrome to protect users on the web.


Google’s participation in the Internet Identity Workshop (IIW) has grown from a few lone individuals at its founding in 2005 to fifteen Googlers at the last IIW. The reason for this growth is that as Google has started to provide more APIs and developer tools for our application hosting business, we have found that standards and interoperability for identity and security on the Internet are critical.  Our engineers attend to discuss standards such as OAuth, OpenSocial, OAuth, SAML, Portable Contacts, as well as longer term trends around discovery, malware, phishing, and stronger authentication.  Another major topic is the usability of these technologies, which we summarized in a blog post after the last IIW.

We hope that other companies and individuals working in these areas will register to attend IIW 2009a and start building momentum for another great event.  If you attended either the Facebook hosted UX summit in Feb 2009 or the Yahoo hosted UX summit in Oct 2008, you can join in further discussions on those topics at the upcoming IIW.

Google attendees: Dirk Balfanz, Nathan Beach, Breno de Medeiros, Cassie Doll, Brian Eaton, Ben Laurie, Kevin Marks, John Panzer, Eric Sachs, and more to come