Friday, April 23, 2010

[Gd] Upcoming Google Apps Marketplace Office Hours and Webinars

| More

Google Apps Developer Blog: Upcoming Google Apps Marketplace Office Hours and Webinars

The Google Apps Marketplace team will be hosting a series of upcoming events to help you learn how to sell your cloud application on the Marketplace and reach the 25 million Google Apps users at 2 million businesses.


Overview of the Google Apps Marketplace

This webinar will provide an overview of the Google Apps Marketplace, the value of integrating applications with Google Apps apps and the process of integrating, testing and selling your application. We’ll show some example integrations and leave plenty of time for Q&A.

Wednesday 4/28 @ 9am PDT (12pm EDT, 4pm GMT)
Register here.

Wednesday 5/5 @ 4pm PDT (7pm EDT, 11pm GMT)
Register here.

Marketing Best Practices for Launching your Marketplace App

Since we launched the Google Apps Marketplace last month, we’ve been pleased to see a growing number of developers launching products and finding phenomenal success selling integrated apps to Google Apps customers. In this webinar, we’ll cover the most critical tactics for generating installs of your app based on our learnings from apps that have already launched as well as some ongoing marketing tactics for you to pursue.

Thursday 4/29 @ 10am PDT (1pm PDT, 5pm GMT)
Register here.

Office Hours

Office Hours with Engineering and Marketing teams

Are you already building your application on the Google Apps Marketplace and have questions about your integration or launch for the Google Engineering or Marketing teams? Stop by our virtual office hours and chat with us via Wave.

Wednesday 4/27 @ 2pm PDT (5pm EDT, 9pm GMT)
No registration necessary, but you must have a Wave account to join the discussion on Wednesday!

Tuesday 5/4 @ 9am PDT (12pm EDT, 4pm GMT)
No registration necessary, but you must have a Wave account to join the discussion on Tuesday!

If you don’t yet have a Wave account, sign up here at least a day advance to make sure your account is ready.

We hope you can join us for one of the webinars or office hours!

Posted by the Google Apps Marketplace Team

[Gd] [Libraries][Update] jQueryUI 1.7.3 and 1.8.1

| More

Google AJAX API Alerts: [Libraries][Update] jQueryUI 1.7.3 and 1.8.1

jQueryUI was updated with versions 1.7.3 and 1.8.1.

[Gd] Games on App Engine: An interview with Jay Kiburz, developer for Neptune’s Pride

| More

Google App Engine Blog: Games on App Engine: An interview with Jay Kiburz, developer for Neptune’s Pride

One of the many classes of application that App Engine facilitates building is online games, particularly collaborative ones. Games often start off small, but can see incredible growth rates as people convince their friends to join, and App Engine’s seamless scaling makes handling these sort of traffic spikes a breeze. Recently, we got together with Jay Kiburz, developer for the game Neptune’s Pride, and asked him a few questions about his game, and how App Engine has worked out for him.

Q. Can you tell us a little about Neptune’s Pride?

Neptune's Pride is a real-time multi-player game of strategy, intrigue and galactic conquest. The game is played over several weeks, and players can log in at any time to upgrade their stars, dispatch their ships and most important of all, conspire with the other players.

Neptune's Pride is not like most web strategy games. The game itself is very simple, which allows players to focus on high level strategic decisions, teamwork and diplomacy.

Q. How long did it take to build your back-end on App Engine? Did you build it from scratch, or port it from another setup?

Neptune's Pride is my first App Engine game, and in fact my first web-based game. It's difficult to say exactly how long was spent developing the back-end as the game grew organically.

One thing I can say is that I spent much less time working on server code than I do working on the interface. Less than 5% of my time is spent writing code that runs on the server.

Q. Which runtime did you implement Neptune's Pride in?

Python, I love Python! Python is my language of choice for any project. Plus, the Java runtime didn't exist when I first started working on Neptune's Pride.

If there were a Javascript runtime I would consider using it, only so that my client and server code were written in the same language. What I want to know is why browsers don't have Python interpreters?

[Ed: There is a Java-based Javascript runtime available, at]

Q. What tip(s) would you offer new developers still exploring or just getting started with App Engine?

The power of App Engine is that you don't need to think about App Engine. "It just works!"

If you're a small developer like me, you don't really care much about what’s happening on the server. Some engineers want to tinker with things and know they have total control. My application’s interface is far more important.

I don't know if this is good advice, but one thing I wish I had done differently would be to have fewer, larger models.

There are a few occasions where I thought It would be a good idea to break a model up because some of the time I only need a subset of the data. I use reference properties to connect my models together so it's no work to retrieve the extra data, however it introduces additional requests, and additional points of failure. I think I would have preferred to just pull more data out of the database with fewer requests.

Q. Your core application is a game - how do you use App Engine to support what has traditionally been a client-centric type of app?

Actually, I didn't really tackle this problem very well. My game code was written as a stand alone Python application with no knowledge at all of the underlying database. Every time the user logs in or gives an order to one of their units, I just pull the whole structure out of the database, un-pickle it, process the order, and shove it back in.

This was fine for Neptune's Pride where a game can have no more that 12 players and has a finite set of data.

I have already started planning a game, more like an MMO, were all players can interact with each other and play on a "global" playing field. This game will need to be much smarter about how data is stored and retrieved from the database.

Q. What App Engine tools or APIs have been particularly useful in developing Neptune's Pride?

I don't know I can point to any one API or tool that has been particularly useful. Isn't the power of App Engine the fact that it's a one stop shop?

Q. What led you to choose App Engine as the platform to use?

Because it was easy. I know its not a very exciting thing to say on the App Engine blog, but really I chose it because I don't want to be thinking about my server, I want to be thinking about my game. App Engine allows me to do that.

Q. Are there any features that you're looking forward to, or that will be particularly useful for you?

I like the sound of background servers that run longer than 30 seconds. I have a couple of processes now that prune data out of the database, these operations are slow. Perhaps I shouldn't bother given how cheap storage is, but I like the idea of my application running forever with no human interaction.

These cleanup operation are the only things that occasionally throw Deadline Exceeded Errors.

Comet communication sounds like something I should be interested in!

Q. If you could change one aspect of App Engine, what would it be?

Another difficult question! Nothing is really getting in my way.

Google has so many great services and tools. I'd like it to be even easier to hook them all up together. If I were going to ask the App Engine team for any one feature it would be to have a look at all the other services out there and make sure it's easy to access them, then give me some code I can just copy and paste into my app :)

Q. Have you had any difficulty scaling your app as it increased in popularity?

Nope, again everything has just worked. As somebody who is new to all this I don't really even know what kinds of problems to expect as I scale, or what performance I should expect, or even the definition of a lot of users. All I can tell you is that I've seen no performance change between 2k requests and 200k requests a day.

I did hit my quota one day, and as a result the game was down for about 4-5 hours. Now I like to keep my usage under 10% of my quota so that if I do experience a spike in traffic there is plenty of room to grow.

I imagine if I grow much bigger I will need to change the application’s interface so that it’s easier for you to find a game, or join your friends in a game. I'm holding off making these changes because I'm also trying to work out the best way to build "social" tools into the game.

I want players to be able build a network of friends they enjoy playing against, then provide some tools to help them stay in touch and coordinate the creation of new games or other events like competitions.

Q. Have you used Appstats? Did you learn anything surprising about your app, and did it have an impact on your app's performance?

I did implement the stats when they first came out but didn't find anything very exciting. I simply confirmed what I already knew, which was that my game code is the slowest part of the application.

Q. Your monetization strategy is quite novel for an online game. What has the uptake and user response been like? Would you recommend it to other developers?

Actually, I just thought I was doing what everybody else is doing these days, a virtual currency. I chose it over a subscription model so players have the freedom to spend it as fast or as slow as they like.

I'm not sure I will use it on the next game. I've been considering a non renewing subscription rather than extracting credits from players every time they join a game. Pay once, forget about it, and enjoy all the sites features as a premium member.

Q. What peak QPS do you see currently? What is your latency for different types of requests?

The game peaks at about 6-8 Requests/Second. Average CPU is about 280ms (130 API).

Q. Any tips to help me overrun the interstellar empires of the rest of the App Engine team?

Know when to strike!

Posted by Nick Johnson, App Engine Team

[Gd] Large scale application development and MVP - Part II

| More

Google Web Toolkit Blog: Large scale application development and MVP - Part II

If you're interested in building large scale applications the MVP way, you may want to checkout the latest addition to our articles section: Large application development and MVP - Part II.

Is this follow-up article, we look into how techniques such as UiBinder and code splitting work in conjunction with an MVP-based app, as well as how to create complex and optimized UIs, without moving too much code into your views.


Thursday, April 22, 2010

[Gd] Google Test Automation Conference 2010 - Hyderabad, India

| More

Google Testing Blog: Google Test Automation Conference 2010 - Hyderabad, India

Thanks for all the enquiries about this year's GTAC event. We have been busy planning and are now ready to share the details. GTAC 2010 will be hosted by Google office in Hyderabad, India on October 28th & 29th, 2010.

As in previous years, the focus of the conference will be on solving software engineering challenges using tools and automation. This year the conference theme is "Test to Testability". With this theme our goal is to look beyond the challenges faced during testing and the complex products that are being developed today. We also want to highlight methodologies and tools that can be used to build testability into our products and to look at how developer tools can be a means towards effective and efficient testing. GTAC 2010 hopes to bring together a group that shares lessons learned and practical experiences regarding testing web apps, services, and systems.

One of the strengths of the conference is that it's driven by a peer group and vocal participation. As in previous years, GTAC is an invitation only conference to share great ideas and to have your thoughts challenged and refined. When you apply, we will be asking you to share with us what ideas and insights you'll be bringing to the conference and how these can further the discussion. The application process for attending will be opening in mid-May 2010.

Today we are also launching the official site for this event and will be updating it and this blog with relevant information in the coming weeks. The next announcement will be a call for attendance and proposals, so do watch these spaces.

Please send suggestions, questions and recommendations to: or post your comments here to this blog.

Looking forward to having a great set of participants and presenters to make this a fun and valuable learning event!

Sujay Sahni on behalf of the GTAC 2010 Committees

[Gd] OpenSocial State of the Union & 1.0 Release Celebration!

| More

OpenSocial API Blog: OpenSocial State of the Union & 1.0 Release Celebration!

The OpenSocial Foundation cordially invites you to come and meet the developers and community leaders that are driving OpenSocial. This is your chance to learn more about what the various OpenSocial providers are doing and get involved in shaping the next version of the specification.

Oh, and now that OpenSocial 1.0 has been released, it’s time to celebrate! We’ll have a happy hour immediately following the State of the Union with lots of tasty food and cold beverages.

The State of the Union & 1.0 Release celebration will take place on May 18th from 1 – 6pm PDT. Our good friends at MySpace have graciously agreed to host event in their San Francisco offices. We hope to see you there!

Please RSVP at

Posted by Dave Peck & Mark Weitzel on behalf of the OpenSocial Foundation


[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to 5.0.375.17 for Windows and Mac

  • Disabled profile based Autofill (this will return in a future release)
  • Various UI features related to the url bar/ omnibox have been removed from this release (e.g. http:// truncation, star icon, etc...)

    • We are currently examining ways to address the usability issues that were raised and plan to reintroduce in a future release
  • Various crash fixes
  • We have restored the shortcuts for the bookmarks bar and bookmarks manager (Ctrl+B and Ctrl+Shift+B respectively)
  • See all
Known Issues
  • Drop down box does not close after clicking on the expand arrow a second time. (Issue: 42350)
More details about additional changes are available in the svn log of all revision.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Anthony Laforge
Google Chrome

[Gd] Best practices for launching your Marketplace app

| More

Google Apps Developer Blog: Best practices for launching your Marketplace app

Since we launched the Google Apps Marketplace last month, we’ve been pleased to see a growing number of developers launching products and finding phenomenal success selling integrated apps to Google Apps customers. As more ISVs enter the Marketplace, we want to make sure we see this success continue and accelerate.

Next week, we’ll be hosting a webinar detailing best practices for a successful launch in the Marketplace. We’ll cover the most critical tactics for generating installs of your app based on our learnings from apps that have already launched. We’ll also cover some of the extras you may want to consider to get added mileage out of your launch, as well as ongoing marketing tactics for you to pursue.

Whether you’re totally unfamiliar with the Marketplace, currently developing an app, or have already launched an app in the Marketplace, this webinar should help you maximize your chances of successfully launching an app in the Marketplace. Please join us!

Best practices for a successful launch in the Google Apps Marketplace
Thursday, April 29, 2010 - 10:00 a.m. PDT / 1:00 p.m. EDT / 6:00 p.m. GMT
Register here for the Webinar.

Posted by Chris Kelly, Google Apps Marketplace Team

[Gd] Sometimes blue text just isn’t enough

| More

iGoogle Developer Blog: Sometimes blue text just isn’t enough

Nearly every iGoogle user has an RSS feed or two on their homepage - from top news to celebrity gossip, recipes, and much much more. In true Google fashion, we originally launched RSS support with a simple headline-only presentation. However, we all know the power of pictures, and so, we're happy to announce the addition of image support to our standard RSS gadget.

With this new feature, users have three different display views.

Headline only
Headline only view

SlideshowHeadline and lead story
Slideshow and Headline and lead story views

When users go to iGoogle today, they’ll notice that not all feeds have the same view. We default each feed to what we believe is the optimal display based on the images currently available in the feed. Of course, users can change the display setting by choosing "edit settings" in the drop down menu for each feed.

These new views not only create a better experience for users, but also give publishers an opportunity to more easily expose rich content, often already present in their RSS feeds. To take advantage of this new feature, publishers simply need to add images and associated Media RSS and/or enclosure elements to their existing RSS feeds. We’ll then grab the images, resize them down as necessary, and provide hosting/caching. Additionally, we’ll make the images clickable and display a 150 character snippet in the “Headline and lead story” view.

Here are a sampling of feeds to try out:

This feature is launching in the US over the next day with full international support coming soon. Please see our feed publisher instructions for more information.

Posted by James Lee, iGoogle Engineer

[Gd] To slash or not to slash

| More

Official Google Webmaster Central Blog: To slash or not to slash

Webmaster Level: Intermediate

That is the question we hear often. Onward to the answers! Historically, it’s common for URLs with a trailing slash to indicate a directory, and those without a trailing slash to denote a file: (with trailing slash, conventionally a directory) (without trailing slash, conventionally a file)

But they certainly don’t have to. Google treats each URL above separately (and equally) regardless of whether it’s a file or a directory, or it contains a trailing slash or it doesn’t contain a trailing slash.

Different content on / and no-/ URLs okay for Google, often less ideal for users

From a technical, search engine standpoint, it’s certainly permissible for these two URL versions to contain different content. Your users, however, may find this configuration horribly confusing -- just imagine if and produced two separate experiences.

For this reason, trailing slash and non-trailing slash URLs often serve the same content. The most common case is when a site is configured with a directory structure:

Your site’s configuration and your options

You can do a quick check on your site to see if the URLs:
  1. http://<your-domain-here>/<some-directory-here>/
    (with trailing slash)
  2. http://<your-domain-here>/<some-directory-here>
    (no trailing slash)
don’t both return a 200 response code, but that one version redirects to the other.
  • If only one version can be returned (i.e., the other redirects to it), that’s great! This behavior is beneficial because it reduces duplicate content. In the particular case of redirects to trailing slash URLs, our search results will likely show the version of the URL with the 200 response code (most often the trailing slash URL) -- regardless of whether the redirect was a 301 or 302.

  • If both slash and non-trailing-slash versions contain the same content and each returns 200, you can:
    • Consider changing this behavior (more info below) to reduce duplicate content and improve crawl efficiency.
    • Leave it as-is. Many sites have duplicate content. Our indexing process often handles this case for webmasters and users. While it’s not totally optimal behavior, it’s perfectly legitimate and a-okay. :)
    • Rest assured that for your root URL specifically, is equivalent to and can’t be redirected even if you’re Chuck Norris.
Steps for serving only one URL version

What if your site serves duplicate content on these two URLs:


meaning that both URLs return 200 (neither has a redirect or contains rel=”canonical”), and you want to change the situation?
  1. Choose one URL as the preferred version. If your site has a directory structure, it’s more conventional to use a trailing slash with your directory URLs (e.g., rather than, but you’re free to choose whichever you like.

  2. Be consistent with the preferred version. Use it in your internal links. If you have a Sitemap, include the preferred version (and don’t include the duplicate URL).

  3. Use a 301 redirect from the duplicate to the preferred version. If that’s not possible, rel=”canonical” is a strong option. rel=”canonical” works similarly to a 301 for Google’s indexing purposes, and other major search engines as well.

  4. Test your 301 configuration through Fetch as Googlebot in Webmaster Tools. Make sure your URLs:
    are behaving as expected. The preferred version should return 200. The duplicate URL should 301 to the preferred URL.

  5. Check for Crawl errors in Webmaster Tools, and, if possible, your webserver logs as a sanity check that the 301s are implemented.

  6. Profit! (just kidding) But you can bask in the sunshine of your efficient server configuration, warmed by the knowledge that your site is better optimized.

Written by Maile Ohye, Developer Programs Tech Lead

[Gd] Most v13 services turned off today

| More

AdWords API Blog: Most v13 services turned off today

Per our announcement six months ago, and our reminders over the last 100 days, today we’re sunsetting the following v13 services:

If you’re still using any of these services, you’ll start to see your calls fail with error code 213. Migrate to the v200909 version of the API to avoid failed calls. Review our per-call migration guide to move your applications over to v2009.

Please note that AccountService, ReportService, and TrafficEstimatorService will remain available in version v13 of the API until we’ve provided this functionality in the new API. We’ll give you at least four months to migrate these last three v13 services once their replacements are available.

As always, please ask questions and share your feedback on the developer forum. Our team is happy to answer questions about v2009 and starting today, is no longer supporting questions about the v13 services that we’ve sunset.

– Jason Shafton, Product Marketing Manager

Wednesday, April 21, 2010

[Gd] App Engine SDK 1.3.3 Released

| More

Google App Engine Blog: App Engine SDK 1.3.3 Released

Today we released version 1.3.3 of the App Engine SDK for both Java and Python. This is a minor release that includes changes and a few issue fixes for the datastore, administration console, and when deploying applications. For more information on all the changes, please read the 1.3.3 release notes for Java and Python.

Additionally, the Python SDK has a new experimental feature that gives you the option to use SQLite as the datastore stub backend. Using SQLite within the dev_appserver should speed up performance of your local datastore when testing on large datasets. (Note that this feature does not add SQL support to the App Engine SDK or service.) If you try out this feature, please give us your feedback on the App Engine Python users group.

1.3.3 is now available on the App Engine download page. As always, we welcome your feedback on the App Engine group.

Posted by The App Engine Team

Tuesday, April 20, 2010

[Gd] UserPrefs in Gadget URLs

| More

iGoogle Developer Blog: UserPrefs in Gadget URLs

There's been a change in the way we send parameters to gadgets which use Content type="url". In short, we started sending the user prefs parameters after a # - the URL fragment identifier. As it turns out, this change caused problems for developers who rely on using URL parameters in server side code - since the url fragment isn't sent to the server.

If this change caused trouble for your gadget then we have figured out a way to exempt gadgets individually for up to about two weeks - that's until May 4. So time is still tight but not as tight. Read on to the end of this post for details.

We didn't intend to break any gadgets and I would normally announce changes like this on the blog and in the forum earlier. The team discussed ways that affected gadgets can deal with the new location of the parameters for type=url gadgets and have a couple ideas for fixes.

First, if your gadget can deal with the user prefs completely in Javascript without another trip to the server then do so. Use the documented apis for user prefs. Gadgets that are already using these API functions to retrieve user prefs are not affected by this iGoogle change.

The other, hopefully less common, case is if you use the parameters in server side code in a way that slightly alters the delivered content. An example would be setting up location-dependant data with the user location stored in their preferences. In this case you can have the gadget read the parameters from the URL in Javascript and send an AJAX request to your server for the data you need to render the relevant sections of your gadget. Of course your gadget should use the documented user prefs apis as above.

A side-effect of the second fix may be that your gadget's initial render can happen sooner which can improve user-perceived performance (while taking roughly the same time to load overall).

We realize this unintended consequence may be difficult to deal with immediately. So we've figured out a way to exempt specific gadgets for up to two weeks if you need the time. Just give the URL of your gadget in this forum thread and we'll add you to the list.

I encourage anyone to post specific questions about fixes for your code in new threads in the iGoogle Developer forum. While it's not normally the best place for help with server-side code, in this case you may find other developers in similar situations.

Posted by Rob Russell, Developer Relations

[Gd] Hello to orkut Developers!

| More

Google Code Blog: Hello to orkut Developers!

As we announced in the last update to the former orkut Developer Blog last week, henceforth we’ll be posting all orkut developer updates to this blog.

We think this is also a good opportunity to quickly introduce the newly-launched Developer page to you. We recently added this feature to the orkut sandbox which we hope to be a one-stop solution for developers looking to manage their applications from a single page and view their stats. You can submit your apps directly from here and verify them to complete the submission process. You can also maintain your apps from here and migrate them to a new URL, or delete them entirely from the directory. And if you have applications that have already been approved and included in the directory, expand their details to track the number of installs, uninstalls, renders and other useful stats updated every week.

Here’s what it looks like in action:

Please note that the Developer page requires you to be on the new orkut UI to work.

So keep your apps coming and point your browser to the one page to manage them all: And stay tuned for all orkut updates right here on the Google Code Blog!

By Prashant Tiwari and Ridhima Kedia, orkut Team

[Gd] URL removal explained, Part III: Removing content that you don't own

| More

Official Google Webmaster Central Blog: URL removal explained, Part III: Removing content that you don't own

Webmaster Level: All

Welcome to the third episode of our URL removals series! In episodes one and two, we talked about expediting the removal of content that's under your control and requesting expedited cache removals. Today, we're covering how to use Google's public URL removal tool to request removal of content from Google’s search results when the content originates on a website not under your control.

Google offers two tools that provide a way to request expedited removal of content:

1. Verified URL removal tool: for requesting to remove content from Google’s search results when it’s published on a site of which you’re a verified owner in Webmaster Tools (like your blog or your company’s site)

2. Public URL removal tool: for requesting to remove content from Google’s search results when it’s published on a site which you can’t verify ownership (like your friend’s blog)

Sometimes a situation arises where the information you want to remove originates from a site that you don't own or can't control. Since each individual webmaster controls their site and their site’s content, the best way to update or remove results from Google is for the site owner (where the content is published) to either block crawling of the URL, modify the content source, or remove the page altogether. If the content isn't changed, it would just reappear in our search results the next time we crawled it. So the first step to remove content that's hosted on a site you don't own is to contact the owner of the website and request that they remove or block the content in question.
  • Removed or blocked content

    If the website owner removes a page, requests for the removed page should return a "404 Not Found" response or a "410 Gone" response. If they choose to block the page from search engines, then the page should either be disallowed in the site's robots.txt file or contain a noindex meta tag. Once one of these requirements is met, you can submit a removal request using the "Webmaster has already blocked the page" option.

    Sometimes a website owner will claim that they’ve blocked or removed a page but they haven’t technically done so. If they claim a page has been blocked you can double check by looking at the site’s robots.txt file to see if the page is listed there as disallowed.
    User-agent: *
    Disallow: /blocked-page/
    Another place to check if a page has been blocked is within the page’s HTML source code itself. You can visit the page and choose “View Page Source” from your browser. Is there a meta noindex tag in the HTML “head” section?
    <title>blocked page</title>
    <meta name="robots" content="noindex">
    If they inform you that the page has been removed, you can confirm this by using an HTTP response testing tool like the Live HTTP Headers add-on for the Firefox browser. With this add-on enabled, you can request any URL in Firefox to test that the HTTP response is actually 404 Not Found or 410 Gone.

  • Content removed from the page

    Once you've confirmed that the content you're seeking to remove is no longer present on the page, you can request a cache removal using the 'Content has been removed from the page' option. This type of removal--usually called a "cache" removal--ensures that Google's search results will not include the cached copy or version of the old page, or any snippets of text from the old version of the page. Only the current updated page (without the content that's been removed) will be accessible from Google's search results. However, the current updated page can potentially still rank for terms related to the old content as a result of inbound links that still exist from external sites. For cache removal requests you’ll be asked to enter a "term that has been removed from the page." Be sure to enter a word that is not found on the current live page, so that our automated process can confirm the page has changed -- otherwise the request will be denied. Cache removals are covered in more detail in part two of the "URL removal explained" series.

  • Removing inappropriate webpages or images that appear in our SafeSearch filtered results

    Google introduced the SafeSearch filter with the goal of providing search results that exclude potentially offensive content. For situations where you find content that you feel should have been filtered out by SafeSearch, you can request that this content be excluded from SafeSearch filtered results in the future. Submit a removal request using the 'Inappropriate content appears in our SafeSearch filtered results' option.

If you encounter any issues with the public URL removal tool or have questions not addressed here, please post them to the Webmaster Help Forum or consult the more detailed removal instructions in our Help Center. If you do post to the forum, remember to use a URL shortening service to share any links to content you want removed.

Written by Jonathan Simon, Webmaster Trends Analyst

[Gd] Who's @ Google I/O: 106 companies, and more on the way

| More

Google Code Blog: Who's @ Google I/O: 106 companies, and more on the way

Google I/O is now just a month away, and we're incredibly excited by the breadth of companies and developers that will be showcasing their applications in this year's Developer Sandbox. As of today, over 100 companies are listed on the I/O website, and we anticipate over 180 companies to be confirmed by the time of I/O.

Over the next few weeks, we'll be inviting developers from these companies to do guest posts on this blog -- giving you insight into their development work and their approach to using Google technologies like Chrome, the Android SDK, GWT and Google APIs.

And for those of you who'll be at Google I/O next month, you'll have the opportunity to meet these developers in person at the Developer Sandbox, which runs for the duration of the conference (see event schedule).

Many thanks to the companies that will be joining us in this year's Sandbox, and to those of you who helped sell out this year's conference 10 weeks in advance!

By Joyce Sohn, Google Developer Team

[Gd] Stable Update: Security Fixes

| More

Google Chrome Releases: Stable Update: Security Fixes

Google Chrome has been released to the Stable channel on Windows.

This release fixes the following security issues:
Please see the Chromium security page for more detail. Note that the referenced bugs may be kept private until a majority of our users are up to date with the fix.
  • [$500] [39443High Type confusion error with forms. Credit: kuzzcc.
  • [39698High HTTP request error leading to possible XSRF. Credit: Meder Kydyraliev, Google Security Team
  • [40136Medium Local file reference through developer tools. Credit: Robert Swiecki, Google Security Team; Tavis Ormandy, Google Security Team.
  • [40137Medium Cross-site scripting in chrome://net-internals. Credit: Robert Swiecki, Google Security Team; Tavis Ormandy, Google Security Team.
  • [40138High Cross-site scripting in chrome://downloads. Credit: Robert Swiecki, Google Security Team; Tavis Ormandy, Google Security Team.
  • [40575Medium Pages might load with privileges of the New Tab page.
  • [$500] [40635High Memory corruption in V8 bindings. Credit: kuzzcc; Google Chrome Security Team (SkyLined); Michal Zalewski, Google Security Team.

If you find issues, please let us know:

--Mark Larson, Google Chrome Team


Monday, April 19, 2010

[Gd] Help Google index your videos

| More

Official Google Webmaster Central Blog: Help Google index your videos

Webmaster Level: All

The single best way to make Google aware of all your videos on your website is to create and maintain a Video Sitemap. Video Sitemaps provide Google with essential information about your videos, including the URLs for the pages where the videos can be found, the titles of the videos, keywords, thumbnail images, durations, and other information. The Sitemap also allows you to define the period of time for which each video will be available. This is particularly useful for content that has explicit viewing windows, so that we can remove the content from our index when it expires.

Once your Sitemap is created, you can can submit the URL of the Sitemap file in Google Webmaster Tools or through your robots.txt file.

Once we have indexed a video, it may appear in our web search results in what we call a Video Onebox (a cluster of videos related to the queried topic) and in our video search property, Google Videos. A video result is immediately recognizable by its thumbnail, duration, and a description.

As an example, this is what a video result from looks like on Google:

We encourage those of you with videos to submit Video Sitemaps and to keep them updated with your new content. Please also visit our recently updated Video Sitemap Help Center, and utilize our Sitemap Help Forum. If you've submitted a Video Sitemap file via Webmaster Tools and want to share your experiences or problems, you can do so here.

Posted by Nelson Lee, Product Manager Video Search

[Gd] Using XAuth to simplify the social web

| More

Google Code Blog: Using XAuth to simplify the social web

Earlier today Meebo announced Extended Authentication (XAuth), an open platform that makes it possible for users to bring their preferred services with them across the web.

To learn more about XAuth and why we're among the supporters of this technology, check out our post on the Social Web Blog.

From a technical perspective, we wanted to offer you some additional insights into how this technology works.

If you visit Meebo's XAuth page, you should see an array of logos:

When this page loaded, it requests the list of services that have been registered with XAuth by making an HTML5 window.postMessage request to As you can see in the graphic, no active sessions were detected.

When the user clicks through to one of the linked demo pages — we'll use in this case — the same JavaScript is loaded from When the user successfully authenticates, some basic information is pushed to the browser's HTML5 localStorage:

<script type="text/javascript">
function doLogin(doneUrl) {
/* Tell that a user has just signed into Google on this browser. */
// reveals "someone is logged into Google"
token: "1",
// Expires after 24 hours or if the user explicitly logs out
expire: new Date().getTime() + 60*60*24*1000,
// Allow any domain to read this info (could also be a whitelist of partners)
extend: ["*"],
// Optional callback function once extend() has completed.
callback: makeRedirectFunc(doneUrl)

This information — that the user has an active session at — is now available to any site on the web (because extend: ["*"] uses the wildcard case to make this information world-readable; providers can also choose to restrict access to this information to certain domains or partners).

Upon returning to, the page requests the list of active sessions from XAuth, and passes the browser an array of domains that the browser will match against the local storage for

<script type="text/javascript">
retrieve: ['', '', ''],
callback: receiveTokens }

The major performance and scalability benefits of this design are a result of the single HTTP request made to to determine which services are currently active, rather than one-request-per-domain. The request and response are also purely client-side, so there's no waiting for a server to look up anything in a database — and the XAuth JavaScript files get cached after they are first retrieved, making XAuth overall very efficient.

Once the tokens are retrieved the program iterates through them looking for matches, and then modifies the interface according the service token discovered, like this:

<script type="text/javascript">
function receiveTokens(responseObj) {
var tokens = responseObj.tokens;
var token = tokens[''];
var partners = {};
var tokensFound = false;
if (tokens['']) {
partners['google'] = true;
tokensFound = true;
var status = document.getElementById('status-google');
status.innerHTML = 'Signed In!'; = '#0A0';

In this way, site publishers can detect a user's set of active and preferred services, or request a subset of known services, and present only those services which are known to be currently active. In practice, the list of services provided at any given time by should not be considered exhaustive, but instead a suggestion for how to prioritize complex service selection dialogs and interfaces, like those known as "NASCAR" interfaces.

For more technical information about XAuth, please read the spec, or visit the informational page on

Posted by Chris Messina, Social Web Team