Friday, February 11, 2011

[Gd] Authentication changes with 2-step verification

| More

AdWords API Blog: Authentication changes with 2-step verification

We recently announced an advanced opt-in 2-step verification process to help make your Google Accounts significantly more secure. 2-step verification adds an extra layer of security to your Google Account by requiring unique “verification codes” in addition to your username and password at sign-in. This means that if your password is stolen, you still have an extra line of defense against a potential hijacker.

Enabling 2-step verification on a Google Account associated with an AdWords Account may lead to an authentication issue when using the AdWords API, which uses ClientLogin. ClientLogin provides the authentication functionality used by the AdWords API, and is not designed to ask for the verification codes in addition to the password. Therefore, APIs accessing this interface must instead use a special password called an application-specific password.

For 2-step verification users, the ClientLogin API will return an error indicating that the user needs to use an application-specific password if the user tries to login with his regular account password.  When this happens the response will contain an extra field that indicates that the error was due to a missing 2-step verification code, and not incorrect credentials.


We recommend that your application detect this error and remind the user to use an application-specific password. The ClientLogin API doesn’t accept verification codes, but application-specific passwords can be created for an account that allow authentication without a verification code.  These can be used in the ClientLogin API just like regular passwords, and they do not expire.  To obtain an application-specific password, the user needs to log in to their Google Account and click on "Authorizing applications & sites."

Under the application-specific passwords section, they should provide the name of the tool or application they wish to generate a password for.  The generated password will only be displayed once, and although it can’t be recovered later it can be revoked at any time.

Here’s what the generated password looks like:

These changes to authentication only apply to applications that authenticate directly against a 2-step enabled account.  Applications that authenticate as an MCC account and specify a client account through the clientEmail or clientCustomerId header of the request need not to worry if 2-step verification is enabled the client account.

To learn more about application-specific passwords, visit the Google Accounts Help Center. Please visit the Official Google Blog for the complete announcement.

As always, please post any questions to the AdWords API Forum.

Posted by Katie Wasilenko, AdWords API Team

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update

The stable channel has been updated to 9.0.597.98 for Windows. This release fixes a regression where IME clients could not attach to Flash (Issue 66605).  Many thanks to everyone for the reports!

If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Anthony Laforge
Google Chrome

[Gd] App Engine 1.4.2 SDK - API Updates and Additions Edition

| More

Google App Engine Blog: App Engine 1.4.2 SDK - API Updates and Additions Edition

It’s only February and we’re already at our second release for the year! Today’s SDK release, 1.4.2 focuses on improving and updating a few existing App Engine APIs.

Improved XMPP API to help applications better interact with users. Notifications are sent when users sign in and out and when their status changes, and the application can now set presence details to be returned to the user. Subscription and Presence notifications are enabled as inbound services in the application configuration.

Task Queue performance and Task Queue API improvements. First, we’ve increased the maximum rate at which tasks can be processed to 100 tasks/second. Applications can also specify the maximum number of concurrent requests allowed per queue in their queue’s configuration file. This can help you more easily manage how many resources your task queue is consuming. We’ve also added an API that allows you to programmatically delete tasks, instead of managing this manually from the Admin Console.

As always, there are more features and issue fixes such as support for JAX-WS complete with a new article on how to build SOAP enabled App Engine apps, as well as support for Django 1.2, so be sure to read the release notes for Java and Python. We’ve also updated the App Engine Roadmap with a few new projects so take a look. And if you have any feedback, please visit the App Engine Groups.

Posted by the App Engine Team


Thursday, February 10, 2011

[Gd] Manymoon - a Google Apps Marketplace success story

| More

Google Apps Developer Blog: Manymoon - a Google Apps Marketplace success story

When we launched the Google Apps Marketplace less than a year ago the goal was to create a vibrant ecosystem and marketplace for independent third party business applications. Today there are hundreds of applications from developers all over the world using Google Apps Marketplace to sell directly to the 30 million Google Apps users at over 3M businesses and higher education institutions. Manymoon is one of the most popular applications on the Google Apps Marketplace, and this week they were acquired by Congratulations to Amit, Manav, Alex, and the entire Manymoon team!

Manymoon began investing in Google Apps integration very early and was one of the early adopters ofthe Google Apps OpenID login feature. They were also one of the first to create a Gmail Contextual Gadget. We worked closely with Manymoon to get their application on the Google Apps Marketplace when we launched last March. Manymoon had immediate success, and quickly became one of most popular applications. Listen to what Manymoon co-founder Amit Kulkarni had to say in a recent interview;

"The results have been fantastic. Since the launch of the Google Apps Marketplace in March, we’ve been signing up as many as 1000 new businesses per week ... and that’s with no sales or marketing people in our company. These customers are finding us on their own in the Google Apps Marketplace, adding the app and getting engaged with it."

"Google Apps Marketplace customers upgrade to a premium edition of Manymoon at a 30% higher rate than non-Google Apps Marketplace customers. The best part, however, is that our monthly registrations increased by 150% since the launch of Google Apps Marketplace. And that’s where the Marketplace really excels, it provides large enough volumes to make the Freemium business model work.

The Google Developer Relations groups loves to work with developers, and help them build great business applications using Google technologies. The Google Apps Marketplace is there to help them sell their applications directly to Google business customers. There is also the Chrome Web Store for web browser applications, and Android Market for mobile apps.

Manymoon is an excellent success story for Google Apps Marketplace and Google Developer Relations, and a nice testament to the value of integrating product features with Google Apps. We are thrilled with their success and happy to see the founders get a great financial exit with the acquisition by Most importantly, we are thrilled to see’s intentions to invest in growing Manymoon on the Google Apps Marketplace, giving Salesforce a new way to work with Google Apps.

Financial exits are great, but there are many other start-ups building successful businesses on the Google Apps Marketplace. Insightly is another amazing success story. In just 3 months they went from coding an idea on nights and weekends, to a best selling app on Google Apps Marketplace. SlideRocket, Aviary, Tungle, Gist, Smartsheet, Outright, MyERP and many others have experienced dramatic growth since joining the Google Apps Marketplace.

See "How To Get Started" on Google Apps Marketplace for more information. See the Google Developer Relations site for links to technical people who can help you. Visit the Google Support Forums for immediate help and answers to your technical questions. Our job is to help developers build great applications, and provide a vibrant marketplace to sell those applications directly to Google customers. Get started today!

Posted by Don Dodge, Google Apps Marketplace Team

Want to weigh in on this topic? Discuss on Buzz


[Gd] How Google Tests Software - Part Two

| More

Google Testing Blog: How Google Tests Software - Part Two

By James Whittaker

In order for the “you build it, you break it” motto to be real, there are roles beyond the traditional developer that are necessary. Specifically, engineering roles that enable developers to do testing efficiently and effectively have to exist. At Google we have created roles in which some engineers are responsible for making others more productive. These engineers often identify themselves as testers but their actual mission is one of productivity. They exist to make developers more productive and quality is a large part of that productivity. Here's a summary of those roles:

The SWE or Software Engineer is the traditional developer role. SWEs write functional code that ships to users. They create design documentation, design data structures and overall architecture and spend the vast majority of their time writing and reviewing code. SWEs write a lot of test code including test driven design, unit tests and, as we explain in future posts, participate in the construction of small, medium and large tests. SWEs own quality for everything they touch whether they wrote it, fixed it or modified it.

The SET or Software Engineer in Test is also a developer role except their focus is on testability. They review designs and look closely at code quality and risk. They refactor code to make it more testable. SETs write unit testing frameworks and automation. They are a partner in the SWE code base but are more concerned with increasing quality and test coverage than adding new features or increasing performance.

The TE or Test Engineer is the exact reverse of the SET. It is a a role that puts testing first and development second. Many Google TEs spend a good deal of their time writing code in the form of automation scripts and code that drives usage scenarios and even mimics a user. They also organize the testing work of SWEs and SETs, interpret test results and drive test execution, particular in the late stages of a project as the push toward release intensifies. TEs are product experts, quality advisers and analyzers of risk.

From a quality standpoint, SWEs own features and the quality of those features in isolation. They are responsible for fault tolerant designs, failure recovery, TDD, unit tests and in working with the SET to write tests that exercise the code for their feature.

SETs are developers that provide testing features. A framework that can isolate newly developed code by simulating its dependencies with stubs, mocks and fakes and submit queues for managing code check-ins. In other words, SETs write code that allows SWEs to test their features. Much of the actual testing is performed by the SWEs, SETs are there to ensure that features are testable and that the SWEs are actively involved in writing test cases.

Clearly SETs primary focus is on the developer. Individual feature quality is the target and enabling developers to easily test the code they write is the primary focus of the SET. This development focus leaves one large hole which I am sure is already evident to the reader: what about the user?

User focused testing is the job of the Google TE. Assuming that the SWEs and SETs performed module and feature level testing adequately, the next task is to understand how well this collection of executable code and data works together to satisfy the needs of the user. TEs act as a double-check on the diligence of the developers. Any obvious bugs are an indication that early cycle developer testing was inadequate or sloppy. When such bugs are rare, TEs can turn to their primary task of ensuring that the software runs common user scenarios, is performant and secure, is internationalized and so forth. TEs perform a lot of testing and test coordination tasks among TEs, contract testers, crowd sourced testers, dog fooders, beta users, early adopters. They communicate among all parties the risks inherent in the basic design, feature complexity and failure avoidance methods. Once TEs get engaged, there is no end to their mission.

Ok, now that the roles are better understood, I'll dig into more details on how we choreograph the work items among them. Until next time...thanks for your interest.

[Gd] Chrome@GDC2011

| More

Chromium Blog: Chrome@GDC2011

Games are some of the most popular apps on the web platform. Representatives from the Chrome team will be at the Game Developers Conference, to connect with game developers and deliver tech talks on some of the latest web technologies.

On February 28th, as part of Google Developer Day at GDC, Vincent Scheib will present an overview of how the latest HTML5 technologies can be used to create games. On the same day, Gregg Tavares will explain how to get GPU-accelerated graphics with WebGL, and Bill Budge will show how you can program Web games in C++ using Native Client. For a full list of other Google talks check out

We will also be present at Google’s booth on the GDC expo floor. Representatives from our 3D Graphics, Native Client, HTML5 and Chrome Web Store teams will be there to answer your questions on how you can use web technologies to create compelling games for Chrome’s 120+ million active users.

We can’t wait to see you there!

Posted by Ian Lewis, Developer Advocate

[Gd] Chromium to Feature in Pwn2Own Contest!

| More

Chromium Blog: Chromium to Feature in Pwn2Own Contest!

We’re excited that the Google Chrome browser will feature in this year’s Pwn2Own contest. Chrome wasn’t originally going to be included as a target browser in the competition, but Google volunteered to sponsor Chrome’s participation by contributing monetary rewards for Chrome exploits. For the past year we’ve enjoyed working with the security community and rewarding researchers for high quality work through our Chromium Security Reward program. Sponsoring this contest to discover more bugs was a logical step. We thought we’d answer some frequently asked questions in the form of a Q&A session:

Q) Is Chrome OS a target?
A) No, not this year, as Chrome OS is still in beta. Per HP TippingPoint / ZDI guidelines, the actual target will be the latest stable version of the Chrome browser at the time, running on an up-to-date Windows 7 system. A Chrome OS device will, however, be awarded in addition to the prize money.

Q) Are you betting that Chrome can’t be hacked?
A) No. We think the Chrome browser has a strong security architecture, and Chrome has fared well in past years at Pwn2Own. But we know that web browsers from all vendors are very large pieces of software that invariably do have some bugs and complex external dependencies. That’s why the Chromium Security Reward program exists, along with our newer web application reward program. As a team comprised largely of security researchers, we think it’s important to reward the security community for their work which helps us learn. Naturally, we’ll learn the most from real examples of Chrome exploits.

Q) How do the rules work?
A) We worked with ZDI to come up with a rules structure that would reward exploits in code specific to Chromium and in third-party components such as the kernel or device drivers.

Of course, we prefer to pay rewards for bugs in our own code because we learn more and can make fixes directly. On day 1 of the competition, Google will sponsor $20,000 for a working exploit in Chrome, if it uses only Chrome bugs to compromise the browser and escape the sandbox. Days 2 and 3 will also allow for bugs in the kernel, device drivers, system libraries, etc., and the $20,000 prize will be sponsored at $10,000 by Google and $10,000 by ZDI to reflect the occurrence of the exploit partially outside of the Chrome code itself.

Note that ZDI is responsible for the rules and may change them at their own discretion.

Q) Does this competition impact the Chromium Security Reward program?
A) The program still pays up to $3,133.7 per bug. As always, submissions to the program don’t require exploits in order to be rewarded. In addition, we continue to reward classes of bugs (such as cross-origin leaks) that would otherwise not be eligible for prizes at Pwn2Own. We encourage researchers to continue submitting their bugs through the Chromium Security Reward program.

Posted by Chris Evans, Google Chrome Security Team

[Gd] Linking Google Analytics to Webmaster Tools

| More

Official Google Webmaster Central Blog: Linking Google Analytics to Webmaster Tools

Webmaster level: All

If you use Google Analytics to track site data, you can now link your Webmaster Tools verified site to an Analytics profile when they use the same Google Account.

Not only will your Analytics profiles be accessible within Webmaster Tools, but you'll also be able to more easily access a few Google Analytics features:

  • View your Google Analytics Referring Pages report directly from the Links to your site page in Webmaster Tools. This report helps you understand the overall trends in traffic volume from referrals, as well as the sites driving those trends.

  • Access the Google Analytics Dashboard directly from the Analytics link in the top left bar when you’re on a site-related page.

To link a verified site in Webmaster Tools to a Google Analytics profile:

  1. On the Webmaster Tools home page, click Manage next to the site you want, then click Google Analytics profile.

  2. Select the profile you want to associate with the site, then click Save.

Note: If your site has multiple owners, each owner will need to link their own account to a Google Analytics profile.

Written by Zhanlu Wang, Webmaster Tools Team

[Gd] Join Google at the Game Developers Conference

| More

The official Google Code blog: Join Google at the Game Developers Conference

In the next few weeks, thousands of programmers, designers and publishers will head to San Francisco for the annual Game Developers Conference (GDC). Google will be there in full force, showcasing technologies, distribution platforms and monetization solutions that help game developers create amazing games and reach an audience of hundreds of millions.

We’ve planned two developer days with several exciting talks. On February 28th, we’ll discuss web technologies such as HTML5, WebGL and Native Client, as well as Google’s cloud solutions and YouTube APIs. On March 1st, we’ll switch our focus to Android, with tech talks on audio, graphics, compatibility, the new NDK and the use of App Engine to securely serve application data.

Several Googlers are also speaking at the GDC summits and main conference, presenting topics ranging from mobile monetization to games on smart TVs. For a full list of our talks you can visit

Want even more Google? Visit our booth on the expo floor, where you can meet Google experts, check out the latest Android devices, or just relax in our Google TV lounge. If you stop by, you might even be able to score a pass to Google’s first invitation-only GDC party. We look forward to meeting you in person!

By Ian Lewis, Games Developer Advocate

[Gd] HTTPS Support for YouTube Embeds

| More

YouTube API Blog: HTTPS Support for YouTube Embeds

HTTPS, the secure counterpart to HTTP, wraps a layer of encryption around the information traveling between your computer and a web server. YouTube already uses HTTPS to encrypt sensitive data during the account login process. Now we’re planning a gradual expansion of HTTPS across other aspects of the site. The first place you may see HTTPS YouTube URLs is in our various embed codes, all of which currently support HTTPS in addition to the standard HTTP. Anyone can try HTTPS with YouTube embeds today—simply change the protocol portion of the URL from http to https. For example, becomes This applies to URLs found in our newer <iframe> embeds as well as our older-style <object><embed> codes.

If any of your existing code attempts to parse YouTube embed URLs that are entered by end-users, it’s important that you support both HTTP and HTTPS as the URL’s protocol across all the varieties of YouTube embed codes.

Most web browsers will warn users when they access web pages via HTTPS that contain embedded content loaded via HTTP. If your main site is currently accessed via HTTPS, using the new HTTPS URLs for your YouTube embeds will prevent your users from running into that warning. If your site can be accessed either via HTTP or HTTPS, you could employ protocol-relative URLs instead of hardcoding a value; // will automatically resolve to HTTP or HTTPS depending on the protocol used by the host page.

It’s very important to note that this is just a first step in enabling HTTPS for the entire YouTube viewing experience. In particular, only the YouTube player code is accessible via HTTPS at this time. The actual video bitstream, and some additional content loaded by the YouTube player may still be accessed via standard HTTP connections when you use an HTTPS URL in your embed code. Also note that HTTPS remains optional for YouTube embeds; we have no plans to turn off support for the HTTP URLs.

If you have any comments or questions about this change, please let us know in the YouTube API developer’s forum.

–Jeff Posnick, YouTube API Team

[Gd] Beauty On the Outside, High Replication on the Inside

| More

Google App Engine Blog: Beauty On the Outside, High Replication on the Inside

Today we launched Google Art Project in collaboration with 17 of the world’s most renowned museums. Google Art Project is built on top of App Engine and lets you take virtual tours of famous museums using internal Street View technology, view high resolution images of famous art work, and create personal virtual artwork collections.

When Art Project started development several months ago, the team built the application using Java and the Master/Slave Datastore. However, as their launch date approached, we released the new High Replication Datastore configuration. With a scheduled maintenance period so soon after the site’s launch, they decided to switch over to the High Replication Datastore.

Before switching, they ran a load test to set a performance baseline for comparison after the application’s data was migrated. Now that the application has launched, we wanted to share the results of the test with you as an example of what to expect after a switch to the High Replication Datastore. Below are the mean numbers for latency of different parts of the site.

Here’s a description of what each page does behind the scenes:

Homepage: This is the landing page that just serves a static webpage for site navigation. Since this page does not pull information from the datastore, the latency is stable.

Collections: Art Project lets users create individual museum collections. These load tests specifically targeted adding and deleting paintings from a user’s personal collection, as well as rendering those collections. We notice the slightly increased latency from saving and deleting entities in the datastore.

Level Maps: These pages simply performed get() calls on the datastore using entity keys. Latency on these pages is consistent across instances.

Info Spots: This handler performs the most data intensive calculations of all of the handlers. It calculates all line of sight interest points for a user’s map position in a museum gallery room, and saves the points of interest to the datastore for that location. The good news is, this calculation doesn’t have to happen for every user. Once this data has been calculated for a given spot, it can re-used for other visitors to the site.

As you can see, while there was some increased latency when switching to the High Replication datastore, the site latency is still very low. And the migration required no major code changes and no modification to the datastore structure between the two load tests.

For more information about the High Replication Datastore, see the Datastore documentation. The next scheduled maintenance period for the Master/Slave datastore is February 7th, 2011 from 5pm - 6pm PST. The High Replication datastore and Google Art Project will not need to be read-only during this period. On the High Replication Datastore, your application won’t need to be either.

Posted by the App Engine Team

Wednesday, February 9, 2011

[Gd] Introducing Renderscript

| More

Android Developers Blog: Introducing Renderscript

[This post is by R. Jason Sams, an Android engineer who specializes in graphics, performance tuning, and software architecture. —Tim Bray]

Renderscript is a key new Honeycomb feature which we haven’t yet discussed in much detail. I will address this in two parts. This post will be a quick overview of Renderscript. A more detailed technical post with a simple example will be provided later.

Renderscript is a new API targeted at high-performance 3D rendering and compute operations. The goal of Renderscript is to bring a lower level, higher performance API to Android developers. The target audience is the set of developers looking to maximize the performance of their applications and are comfortable working closer to the metal to achieve this. It provides the developer three primary tools: A simple 3D rendering API on top of hardware acceleration, a developer friendly compute API similar to CUDA, and a familiar language in C99.

Renderscript has been used in the creation of the new visually-rich YouTube and Books apps. It is the API used in the live wallpapers shipping with the first Honeycomb tablets.

The performance gain comes from executing native code on the device. However, unlike the existing NDK, this solution is cross-platform. The development language for Renderscript is C99 with extensions, which is compiled to a device-agnostic intermediate format during the development process and placed into the application package. When the app is run, the scripts are compiled to machine code and optimized on the device. This eliminates the problem of needing to target a specific machine architecture during the development process.

Renderscript is not intended to replace the existing high-level rendering APIs or languages on the platform. The target use is for performance-critical code segments where the needs exceed the abilities of the existing APIs.

It may seem interesting that nothing above talked about running code on CPUs vs. GPUs. The reason is that this decision is made on the device at runtime. Simple scripts will be able to run on the GPU as compute workloads when capable hardware is available. More complex scripts will run on the CPU(s). The CPU also serves as a fallback to ensure that scripts are always able to run even if a suitable GPU or other accelerator is not present. This is intended to be transparent to the developer. In general, simpler scripts will be able to run in more places in the future. For now we simply leverage the CPU resources and distribute the work across as many CPUs as are present in the device.

The video above, captured through an Android tablet’s HDMI out, is an example of Renderscript compute at work. (There’s a high-def version on YouTube.) In the video we show a simple brute force physics simulation of around 900 particles. The compute script runs each frame and automatically takes advantage of both cores. Once the physics simulation is done, a second graphics script does the rendering. In the video we push one of the larger balls to show the interaction. Then we tilt the tablet and let gravity do a little work. This shows the power of the dual A9s in the new Honeycomb tablet.

Renderscript Graphics provides a new runtime for continuously rendering scenes. This runtime sits on top of HW acceleration and uses the developers’ scripts to provide custom functionality to the controlling Dalvik code. This controlling code will send commands to it at a coarse level such as “turn the page” or “move the list”. The commands the two sides speak are determined by the scripts the developer provides. In this way it’s fully customizable. Early examples of Renderscript graphics were the live wallpapers and 3d application launcher that shipped with Eclair.

With Honeycomb, we have migrated from GL ES 1.1 to 2.0 as the renderer for Renderscript. With this, we have added programmable shader support, 3D model loading, and much more efficient allocation management. The new compiler, based on LLVM, is several times more efficient than acc was during the Eclair-through-Gingerbread time frame. The most important change is that the Renderscript API and tools are now public.

The screenshot above was taken from one of our internal test apps. The application implements a simple scene-graph which demonstrates recursive script to script calling. The Androids are loaded from an A3D file created in Maya and translated from a Collada file. A3D is an on device file format for storing Renderscript objects.

Later we will follow up with more technical information and sample code.


[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Chrome Dev channel has been updated to 10.0.648.45 for all platforms.  This build contains the following updates:
  • Updated V8 -
  • Update Flash - 10.2
  • Many Crash fixes
  • Background applications UI cleanup
  • Additional settings UI cleanup
  • Fix for differential installers not applying cleanly
  • [r74051] Horizontal scroll should not move the options behind Settings.  (Issue 71689)
  • [r74060] No sound in extension with Chromium (Issue 57263)
Full details about the Chrome changes are available in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Jason Kersey
Google Chrome

[Gd] Android 2.3.3 Platform, New NFC Capabilities

| More

Android Developers Blog: Android 2.3.3 Platform, New NFC Capabilities

Several weeks ago we released Android 2.3, which introduced several new forms of communication for developers and users. One of those, Near Field Communications (NFC), let developers get started creating a new class of contactless, proximity-based applications for users.

NFC is an emerging technology that promises exciting new ways to use mobile devices, including ticketing, advertising, ratings, and even data exchange with other devices. We know there’s a strong interest to include these capabilities into many applications, so we’re happy to announce an update to Android 2.3 that adds new NFC capabilities for developers. Some of the features include:

  • A comprehensive NFC reader/writer API that lets apps read and write to almost any standard NFC tag in use today.
  • Advanced Intent dispatching that gives apps more control over how/when they are launched when an NFC tag comes into range.
  • Some limited support for peer-to-peer connection with other NFC devices.

We hope you’ll find these new capabilities useful and we’re looking forward to seeing the innovative apps that you will create using them.

Android 2.3.3 is a small feature release that includes a new API level, 10.
Going forward, we expect most devices shipping with an Android 2.3 platform to run Android 2.3.3 (or later). For an overview of the API changes, see the Android 2.3.3 Version Notes. The Android 2.3.3 SDK platform for development and testing is available through the Android SDK Manager.


Tuesday, February 8, 2011

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update

The stable channel has been updated to 9.0.597.94 for all platforms. This release contains an updated version of Flash player (10.2), along with the following security fixes.
Security fixes and rewards:
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.

This release incorporates a new version of Flash (10.2), which is a security update.

  • [67234] High Stale pointer in animation event handling. Credit to Rik Cabanier.
  • [$1000] [68120] High Use-after-free in SVG font faces. Credit to miaubiz.
  • [$1000] [69556] High Stale pointer with anonymous block handling. Credit to Martin Barbella.
  • [69970] Medium Out-of-bounds read in plug-in handling. Credit to Bill Budge of Google.
  • [$1000] [70456] Medium Possible failure to terminate process on out-of-memory condition. Credit to David Warren of CERT/CC.
If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Anthony Laforge
Google Chrome

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Chrome Dev channel has been updated to 10.0.648.18 for all platforms.  This build contains the following updates:

  • Updated V8 -
  • [73562] Removed icon from View Background Pages menu item in wrench menu. (Issue: 71489)
  • [r73158] Fix crash on closing Download Manager (Issue: 71027)
  • [r73207] Auto-scroll while drag and dropping apps on the New Tab Page (Issue: 70965)
  • webNavigation extension API ready for testing (Issue: 60100)
  • [r73163] Find bug where web text input would sometimes trigger find-in-page (Issue: 70644)
Full details about the Chrome changes are available in the SVN revision log. If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Jason Kersey
Google Chrome

[Gd] Stable Channel Update

| More

Google Chrome Releases: Stable Channel Update

The stable channel has been updated to 9.0.597.84 for all platforms. Details about the features included in this release can be found on the Google Chrome Blog, in addition this release contains the following security fixes.
Security fixes and rewards:
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.
Special thanks to thecommunity, for playing so much of the game “Z-Type” that they uncovered a Chromium audio bug -- see below!

  1. [Mac only] [42989Low Minor sandbox leak via stat()Credit to Daniel Cheng of the Chromium development community.
  2. [$1000] [55831High Use-after-free in image loadingCredit to Aki Helin of OUSPG.
  3. [59081Low Apply some restrictions to cross-origin drag + drop. Credit to Google Chrome Security Team (SkyLined) and the Google Security Team (Michal Zalewski, David Bloom).
  4. [62791Low Browser crash with extension with missing key. Credit to Brian Kirchoff.
  5. [$1000] [64051High Crashing when printing in PDF event handlerCredit to Aki Helin of OUSPG.
  6. [65669Low Handle merging of autofill profiles more gracefully. Credit to Google Chrome Security Team (Inferno).
  7. [Mac only] [66931Low Work around a crash in the Mac OS 10.5 SSL libraries. Credit to Dan Morrison.
  8. [68244Low Browser crash with bad volume setting. Credit to Matthew Heidermann.
  9. [69195Critical Race condition in audio handlingCredit to the gamers of Reddit!

In addition, we would like to thank Aki Helin, Sergey Glazunov, Ben Hawkes of the Google Security Team, Benoit Jacob, Simon Fraser and miaubiz for reporting bugs to us during the development cycle, so that they never affected the stable channel. Various rewards were issued for this help.

If you find new issues, please let us know by filing a bug. Want to change to another Chrome release channel? Find out how.

Anthony Laforge
Google Chrome