If you did a Google search between 6:30 a.m. PST and 7:25 a.m. PST this morning, you likely saw that the message "This site may harm your computer" accompanied each and every search result. This was clearly an error, and we are very sorry for the inconvenience caused to our users.

What happened? Very simply, human error. Google flags search results with the message "This site may harm your computer" if the site is known to install malicious software in the background or otherwise surreptitiously. We do this to protect our users against visiting sites that could harm their computers. We maintain a list of such sites through both manual and automated methods. We work with a non-profit called StopBadware.org to come up with criteria for maintaining this list, and to provide simple processes for webmasters to remove their site from the list.

We periodically update that list and released one such update to the site this morning. Unfortunately (and here's the human error), the URL of '/' was mistakenly checked in as a value to the file and '/' expands to all URLs. Fortunately, our on-call site reliability team found the problem quickly and reverted the file. Since we push these updates in a staggered and rolling fashion, the errors began appearing between 6:27 a.m. and 6:40 a.m. and began disappearing between 7:10 and 7:25 a.m., so the duration of the problem for any particular user was approximately 40 minutes.

Thanks to our team for their quick work in finding this. And again, our apologies to any of you who were inconvenienced this morning, and to site owners whose pages were incorrectly labelled. We will carefully investigate this incident and put more robust file checks in place to prevent it from happening again.

Thanks for your understanding.

Update at 10:29 am PST: This post was revised as more precise information became available (changes are in blue). Here's StopBadware's explanation.

Posted by Marissa Mayer, VP, Search Products & User Experience

Posted by Bartholomew Furrow and Sebastian Kanthak, Google Code Jam Team
At Google, we like to use our own projects for internal development. Following that philosophy, one of the first apps ever made for Google App Engine was the contest platform for Google Code Jam. The application was a good fit: a rich web interface, real-time user interaction, and a heavily parallel design. But we faced one major challenge, which was how to handle the huge scoreboard -- in the first round, we had over 11,000 contestants.
While App Engine's datastore allows you to sort entities by score, it doesn't have a built-in mechanism to answer the following two requests:

1. Given a user, what is his or her rank on the scoreboard? In other words, for some arbitrary row in that scoreboard, what is its position amongst the 11,000 spots? This is useful for showing your own rank, as well as the ranks of your friends.
2. Give me all users on the n-th page of the scoreboard. While it is possible to get all users in sorted order, datastore queries don't allow you to start at page n, and iterating over all of the users on the first n pages takes too much time.

To solve these issues, we came up with a library that maintains a data structure to efficiently support these use cases. We imagine that other applications will have similar problems (e.g., a high-score list in a game), and so we're happy to release our work as the "google-appengine-ranklist" library.
The library supports three different operations:

1. Setting the score of a given user.
2. Given a score, what's the rank of a user with this score? This is used to answer the "What's the rank of person U?" use case.
3. Given a rank, what's the score S for this rank? This can be used to solve the paging problem, by constructing a query that returns the first few users with a score less than or equal to S, in sorted order

If you think this library could be useful for you, take a look at the documentation and at the example application. We'd love to hear from you in our Google Group.

Offline Gmail is now available as an optional, experimental feature in Gmail Labs. Gmail Labs are unsupported features that may break or behave unexpectedly, so use your discretion before enabling this feature.Editions included:Standard, Premier, and Education EditionsLanguages included:US English, UK English (where Gmail Labs is available)How to access what's new:End users can enable offline Gmail from the 'Labs' tab in 'Settings'.Premier Edition administrators must first enable Gmail Labs for their domain for users to see this option. From the administrative control panel, choose 'Email' from the 'Service settings' menu. Check the box next to 'Enable Gmail Labs for my users' and click 'Save changes'. Gmail Labs are unsupported features that may break or behave unexpectedly, so use your discretion before enabling Gmail Labs for your users.For more information:http://googleenterprise.blogspot.com/2009/01/announcing-offline-access-in-gmail-labs.htmlGet these product update alerts by emailSubscribe to the RSS feed of these updates

Posted by Yariv Adan, Google Security TeamWe are happy to announce an important enhancement to our recently launched OpenID endpoint. Google now supports the "Hybrid Protocol", combining OpenID federated login together with OAuth access authorization. Websites can now ask Google to sign-in a user using their Google Account, and at the same time request access to information available via OAuth-enabled APIs such as the Google Data APIs.For example, the website www.Plaxo.com is an early adopter of the new service and has already released a beta version supporting it for some of its new users. Plaxo's UI provides both a richer sign-in offering, using the Federated Login OpenID API, and a simple and secure way to import their Google Contacts using OAuth. In the past, sign-in required multiple redirects between Plaxo and Google, and more importantly, multiple user approval pages, one for OpenID during sign-in and another for the OAuth access authorization request. No more!The Hybrid Protocol allows Plaxo to encapsulate their OAuth authorization request inside the OpenID authentication request, letting Google know that the user wants to use both APIs. Google can now display a single approval page for both requests. Here is how the new user experience looks:In their sign in page, Plaxo offers their users the option to sign in using their Google Account and import their Gmail Contacts.The user is then redirected to the Google website and asked to confirm both sign in and access authorization requests.Finally, the user is redirected back to Plaxo, where she is already signed in and her Google contacts are available. If it's the first time the user signed-in using the Federated Login API, an additional instructive window will be displayed to ensure that the next sign-in experience will be as easy and successful as the first.Not only does the protocol allows a much better user experience as shown above, it also reduces the total number of browser redirects and roundtrips, reducing overall latency.To learn more about this new API see http://groups.google.com/group/google-federated-login-api/web/oauth-support-in-googles-federated-login-api. To make it easier for you to use the new API, we created a collaborative Open Source project together with other major vendors where you can download open source implementations for your Relying Party component. You are invited to contribute your own code and suggested best practices to this website.The Hybrid Protocol is a result of the ongoing effort by the OpenID and OAuth communities to make these protocols more useful for users and websites. Google is working together with the OpenID community to standardize the new protocol as a formal OpenID extension. If you want to help further these efforts and have an impact on what the next advancements are, you are welcome to join the OpenID and OAuth mailing lists.If you're interested in looking at some code, check out our working sample using the Google Data PHP client library. The source code is available here.