Saturday, May 26, 2012

[Gd] Fridaygram: Moog doodle, new species, eclipse pictures

| More

Google Developers Blog: Fridaygram: Moog doodle, new species, eclipse pictures

Author Photo
By Scott Knaster, Google Developers Blog Editor

Earlier this week we posted a doodle honoring Bob Moog, inventor of the Moog Synthesizer. This instrument started a revolution in electronic music, as musicians in many different genres used the Moog Synthesizer and its descendants to create and enhance their music. This doodle was the first one to use the Web Audio API to create sounds, along with a bunch of other web and Google technologies. But mostly, this doodle was wonderful because it was a lot of fun to play with.

Some things are not so fun to play with, but are cool to look at, like many of the creatures on this year’s list of the top 10 new species as selected by the International Institute for Species Exploration. The list includes a super-fast wasp, a very big millipede, a sneezing monkey, and a really amazing jelly.

photo of new jelly species
Bonaire Banded Box Jelly (Tamoya ohboya). Yeah, it stings. Photo credit: Ned DeLoach

Finally, for some big-time science fun this weekend, use your favorite search engine to find photos of last week’s annular eclipse. Or, if you don’t want to do your own search, you can start with these.

The Official Google Blog post about the Moog doodle includes this wonderful bit of writing: "Bob Moog is something of a patron saint of the nerdy arts..." We respect that here on the Fridaygram, because nerds r us, and that's why we publish posts with items that aren’t always related to developer topics.

Friday, May 25, 2012

[Gd] Changes to the Field Trials infrastructure

| More

Chromium Blog: Changes to the Field Trials infrastructure

In theory there’s no difference between theory and practice. In practice, there is. That’s why we prefer to try new ideas out in the real world and see which features actually helped users get where they want to go. In Chrome we call these tests Field Trials, and they’ve been part of every install steadily making Chrome better since day one. For example, Field Trials helped us improve our Omnibox pre-rendering by about 70 percent - making about 1 in 3 Omnibox navigations faster by a second or more.

If you’re contributing to Chrome, you should consider using Field Trials to help tune your features. Recently we’ve added infrastructure to help make designing and deploying these tests easier than ever. Field Trials will now have a regular update cycle similar to the one that delivers the newest version of Chrome to users, making it easier to rapidly release and retire new variations. We’ve also centralized the logic of which variations are active so that its easy for developers on M21 or higher to reset their variation state, using the --reset-variation-state command line flag. To learn more about variations of Chrome, check out Field Trials at the Chromium project.

 Posted by Tyler Odean, Product Manager

[Gd] Beta Channel Update

| More

Chrome Releases: Beta Channel Update

The Beta channel has been updated to 20.0.1132.17 for Windows, Mac, Linux, and Chrome Frame. This build contains updates to v8 ( and fixes for bugs and stability. Full details about what changes are in this build are available in the SVN revision logInterested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.

Dharani Govindan
Google Chrome

[Gd] Beta Update for Chromebooks

| More

Chrome Releases: Beta Update for Chromebooks

The Beta channel has been updated to 19.0.1084.52 (Platform version: 2046.106.0) for Chromebooks (Acer AC700 and Samsung Series 5).

This release contains security, stability improvements and bug fixes.

If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu. Josafat Garcia
Google Chrome

[Gd] In-app Subscriptions in Google Play

| More

Android Developers Blog: In-app Subscriptions in Google Play

[This post is by Ibrahim Elbouchikhi, Product Manager on the Google Play team. —Dirk Dougherty]

We launched In-app Billing on Google Play a year ago to give developers more ways to sell and engage users over the lifetime of their apps. Since the launch, In-app Billing has been extremely successful in helping developers monetize their apps through try-and-buy, virtual goods, upgrades, and other popular business models. Today, 23 of the 24 top-grossing apps in Google Play use In-app Billing, and the total revenue generated from in-app purchases exceeds revenue from traditional app purchases.

We’re now taking In-app Billing further by adding another important business model — subscriptions. Starting today, developers can use In-app Billing to sell monthly or annual subscriptions from inside of their apps. All subscriptions are auto-renewing, for every app and game and every type of subscription product. Developers just set the price and billing interval and Google Play manages the purchase transactions for them, just as it does for other in-app products and app purchases.

For users, Google Play provides a familiar and convenient purchase experience, highlighting subscription details such as price and billing interval before continuing with purchases. After the transaction, Google Play manages recurring billing and keeps users informed of new charges, sending them an email with each renewal. At any time, users can visit My Apps in the Play Store app to view their subscriptions and cancel any subscription as needed.

While making it easy for developers to offer a great purchasing experience, our subscriptions are also designed for flexibility. Developers can use them to monetize premium dynamic content such as journals and magazines, but they can also use them to sell access to bundled products, game levels, music and video content, value-added services, or any other digital content.

Building on Google Play’s strength as a truly cloud-connected experience, developers can offer users the ability to carry their subscriptions across multiple properties, services, or campaigns. To make this easier, we’re introducing an HTTP-based publisher API through which enterprise-scale backend servers can validate or cancel subscriptions. Using this API, for example, developers can extend access from their Android apps to their web properties, based on subscriptions that are purchased on Google Play.

In the coming days, several developers will be launching apps with Google Play subscriptions and we expect many more to follow. Glu Mobile is launching updated versions of its top Android titles, including Frontline Commando, offering subscriptions through custom VIP currency packages. "We're using Google Play subscriptions to offer consumers a compelling value and a single currency which they can use across Glu’s most popular titles” says Niccolo de Masi, CEO of Glu. “We're excited to bring these capabilities to our Android users and we believe that Google Play subscriptions will fuel further growth in our business."

If you’re a developer, you can get started with subscriptions right away by reading the In-app Billing documentation and downloading the updated sample app. If you are already using in-app billing, you’ll find that adding support for subscriptions is straightforward and involves only minor changes to your code.

You can publish your updated apps and subscription products as soon as you are ready. We’ve already rolled out client support to most Android devices worldwide, so any user with Google Play 3.5 or higher installed can buy subscriptions starting today.

We’re looking forward to seeing how you use subscriptions in your apps!

Join the discussion on

+Android Developers


Thursday, May 24, 2012

[Gd] Multilingual and multinational site annotations in Sitemaps

| More

Official Google Webmaster Central Blog: Multilingual and multinational site annotations in Sitemaps

Webmaster level: All

In December 2011 we announced annotations for sites that target users in many languages and, optionally, countries. These annotations define a cluster of equivalent pages that target users around the world, and were implemented using rel-alternate-hreflang link elements in the HTML of each page in the cluster.

Based on webmaster feedback and other considerations, today we’re adding support for specifying the rel-alternate-hreflang annotations in Sitemaps. Using Sitemaps instead of HTML link elements offers many advantages including smaller page size and easier deployment for some websites.

To see how this works, let's take a simple example: We wish to specify that for the URL, targeting English language users, the equivalent URL targeting German language speakers Up till now, the only way to add such annotation is to use a link element, either as an HTTP header or as HTML elements on both URLs like this:

<link rel="alternate" hreflang="en" href="" >
<link rel="alternate" hreflang="de" href="" >

As of today, you can alternately use the following equivalent markup in Sitemaps:

href="" />

href="" />

href="" />

href="" />


Briefly, the new Sitemaps tags shown in bold function in the same way as the HTML link tags, with both using the same attributes. The full technical details of how the annotations are implemented in Sitemaps, including how to implement the xhtml namespace for the link tag, are in our new Help Center article.

A more detailed example can be found in our new Help Center article, and if you need more help, please ask in our brand new internationalization help forum.

Written by , Webmaster Trends Analyst


[Gd] The Google APIs Explorer has a new look

| More

Google Developers Blog: The Google APIs Explorer has a new look

By Antonio Fuentes and Jake Moshenko,
Google Developer Team

Last March we introduced the Google APIs Explorer, an interactive tool that enables you to try out a Google API in minutes and explore its supported methods. When we launched it, the APIs Explorer supported over a half dozen APIs.

Starting today, the APIs Explorer has a brand new look to make it easier and more fun to navigate. We are also adding new features, including an indexed history of your API calls, a better editor for the body of a request, and a search box so you can search for APIs and methods easily.

screen shot

Moreover, we have been busy adding support for more APIs to the Explorer. The Explorer now supports over two dozen Google APIs, and the list continues to grow! We have also added an indicator to show which methods require authenticated requests.

To get started, here are some sample requests you can try in the Explorer:

The APIs Explorer will help you get started using Google APIs in minutes. If you need more information, visit the documentation. We always welcome your feedback in the Public Forum.

Antonio Fuentes is a Product Manager focusing on developer-facing technologies.

Jake Moshenko is a Software Engineer working on the Google APIs developer experience. He believes that Google APIs should be easy to use, especially from Google platforms.

Posted by Scott Knaster, Editor

[Gd] Stable Channel Update

| More

Chrome Releases: Stable Channel Update

The Chrome Stable channel has been updated to 19.0.1084.52 on Windows, Mac, Linux and Chrome Frame.  

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.

  • [117409] High CVE-2011-3103: Crashes in v8 garbage collection. Credit to the Chromium development community (Brett Wilson).
  • [118018] Medium CVE-2011-3104: Out-of-bounds read in Skia. Credit to Google Chrome Security Team (Inferno).
  • [$1000] [120912] High CVE-2011-3105: Use-after-free in first-letter handling. Credit to miaubiz.
  • [122654] Critical CVE-2011-3106: Browser memory corruption with websockets over SSL. Credit to the Chromium development community (Dharani Govindan).
  • [124625] High CVE-2011-3107: Crashes in the plug-in JavaScript bindings. Credit to the Chromium development community (Dharani Govindan).
  • [$1337] [125159] Critical CVE-2011-3108: Use-after-free in browser cache. Credit to “efbiaiinzinz”.
  • [Linux only] [$1000] [126296] High CVE-2011-3109: Bad cast in GTK UI. Credit to Micha Bartholomé.
  • [126337] [126343] [126378] [127349] [127819] [127868] High CVE-2011-3110: Out of bounds writes in PDF. Credit to Mateusz Jurczyk of the Google Security Team, with contributions by Gynvael Coldwind of the Google Security Team.
  • [$500] [126414] Medium CVE-2011-3111: Invalid read in v8. Credit to Christian Holler.
  • [127331] High CVE-2011-3112: Use-after-free with invalid encrypted PDF. Credit to Mateusz Jurczyk of the Google Security Team, with contributions by Gynvael Coldwind of the Google Security Team.
  • [127883] High CVE-2011-3113: Invalid cast with colorspace handling in PDF. Credit to Mateusz Jurczyk of the Google Security Team, with contributions by Gynvael Coldwind of the Google Security Team.
  • [128014] High CVE-2011-3114: Buffer overflows with PDF functions. Credit to Google Chrome Security Team (scarybeasts).
  • [$1000] [128018] High CVE-2011-3115: Type corruption in v8. Credit to Christian Holler.

Many of these bugs were detected using AddressSanitizer.

Full details about what changes are in this release are available in the SVN revision log. If you find a new issue, please let us know by filing a bug.

Anthony Laforge
Google Chrome

Wednesday, May 23, 2012

[Gd] Dev Update for Chromebooks

| More

Chrome Releases: Dev Update for Chromebooks

The Dev channel has been updated to 20.0.1132.15 (Platform versions: 2268.23.0) for Chromebooks (Acer AC700 , Samsung Series 5, and Cr-48).

This build contains functional & stability improvements. Some highlights of these changes are:
  • Improvements to trackpad on cr-48 
  • Updates to Pepper Flash
  • Several crash fixes

Known issues:
  • Device is freezing after disconnecting external USB mouse (Issue: 31206)

    If you find new issues, please let us know by visiting our help site or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue’ under the wrench menu.

    Karen Grunberg & Danielle Drew
    Google Chrome

    Tuesday, May 22, 2012

    [Gd] Introducing Versions and Libraries in Apps Script

    | More

    Google Apps Developer Blog: Introducing Versions and Libraries in Apps Script

    Have you ever written a particular piece of code over and over again?  Or used scripts to do something that you thought others might want to do as well?  Starting today, you’ll be able to share and reuse those scripts as libraries, right from inside Google Apps Script.

    Why use a Script Library

    I often write scripts which check the National Weather Service for relevant weather-related information.  This allows me to send myself an email if it’s going to rain, reminding me to bring an umbrella to work, or to annotate my spreadsheet of running workouts with the temperature of the day.

    Remembering how to query the National Weather Service every time I write a script is a daunting task, however.  They have a complicated XML format that  is tricky to parse.  As a result, I end up just copying and pasting code each time.  This is not only error-prone, but also has the big disadvantage that I have to fix all of my scripts one by one whenever the Weather Service’s XML format changes.

    The code I use to query the National Weather Service is a perfect use case for a library.  By using a library, I no longer have to copy and paste code in my script project.  Since logic is centralized, updates need to be applied just once.  And now I am able to share my library with other developers who can benefit from the work I’ve already done.

    Writing a Library

    Libraries are written just like any other Apps Script project.  A good library has a clean API which is also well documented.  Here’s a code snippet from my WeatherService library:

    * Queries the National Weather Service for the weather
    * forecast of the given address. Example:
    * <pre>
    * var chances = WeatherService
    * .getPrecipitation("New York, NY");
    * var fridayChance = chances[“Friday”];
    * Logger.log(fridayChance + “% chance of rain on Friday!”);
    * </pre>
    * @param {String} address The address to query the
    * temperature for, in any format accepted by
    * Google Maps (can be a street address, zip
    * code, city and state, etc)
    * @returns {JsonObject} The precipitation forecast, as
    * map of period to percentage chance of
    * precipitation. Example:
    * <pre>
    * { Tonight: 50, Friday: 30, Friday Night: 40, ... }
    * </pre>
    function getPrecipitation(address) {
    // Code for querying weather goes
    // here...

    Notice how detailed the documentation is. We know that good documentation makes for a great library. So, for every library Apps Script will also auto-generate a documentation page based on the code comments using the JSDoc format.  If you want a method in your code to not be exposed to users, simply end its name with an underscore.

    Saving Versions

    Before code can be used as a library, a version of it needs to be saved.  Versions are a new concept in Apps Script, and they represent a snapshot of your project which won’t change even as changes are made to the script code. Versions are useful because they allow you to change your library code without breaking existing users.  Once you’re happy with the changes you’ve made, you can then save a new version. Please see the user guide for saving a version and sharing your code as a library is easy.

    Using Libraries

    Using a library only takes a few steps. To be able to use a library, the owner of the library must share the library and its project key with you. You can follow these instructions to then use a library. To use this National Weather Service library, please visit this page for project key.

    Useful Features of Libraries

    Script Libraries come with three interesting features.

    1. Documentation - In the Script Libraries dialog, you can click on the title link to navigate to documentation page for the library. See example of a generated documentation.
    2. Development Mode can be used to test changes to a library without saving a new version. See our User Guide for more details
    3. Autocomplete in Script Editor - Typing in the editor will auto-complete your library function names.

    Interesting Libraries You Can Use

    To get started on using Script Libraries, you can find a list of useful libraries contributed by two of our top contributors - James Ferreira and Romain Vialard. You can also find a detailed user guide on managing versions and libraries. We hope you enjoy using libraries.

    Gustavo Moura

    Gustavo has been a Software Engineer at Google since 2007. He has been part of the Google Docs team since 2009. Prior to that, he worked on AdWords. In his free time he plays soccer.


    [Gd] Introducing Webmaster Academy

    | More

    Official Google Webmaster Central Blog: Introducing Webmaster Academy

    Webmaster Level: Beginner

    Looking through all of the information in Webmaster Central can feel overwhelming, especially if you’re just getting started with a website. This is why we’re excited to introduce a new set of educational materials in a program called Webmaster Academy. Webmaster Academy provides practical and easy-to-understand lessons for beginner webmasters to help you improve your site with topics like getting your site in our index, providing search engines with helpful information about your video and image content, and understanding Webmaster Tools features.

    We’ve organized the content to represent what beginner webmasters should know in a way that’s both structured and modular, meaning you can go through the whole curriculum, or pick and choose your own path. Once you’ve read the articles, you can easily delve deeper into each topic, as we provide links to more in-depth articles. Most lessons are also accompanied by a video from the Webmaster Central YouTube Channel. If you’re looking to understand search and improve your site, Webmaster Academy is for you!

    Have feedback? Excellent. Post it in our Webmaster Help Forum.

    Posted by Julian Prentice, Search Quality Team
    Contributors: Oliver Barrett & Alexi Douvas, Search Quality Team

    [Gd] A Tale of Two Pwnies (Part 1)

    | More

    Chromium Blog: A Tale of Two Pwnies (Part 1)

    Just over two months ago, Chrome sponsored the Pwnium browser hacking competition. We had two fantastic submissions, and successfully blocked both exploits within 24 hours of their unveiling. Today, we’d like to offer an inside look into the exploit submitted by Pinkie Pie.

    So, how does one get full remote code execution in Chrome? In the case of Pinkie Pie’s exploit, it took a chain of six different bugs in order to successfully break out of the Chrome sandbox.

    Pinkie’s first bug (117620) used Chrome’s prerendering feature to load a Native Client module on a web page. Prerendering is a performance optimization that lets a site provide hints for Chrome to fetch and render a page before the user navigates to it, making page loads seem instantaneous. To avoid sound and other nuisances from preloaded pages, the prerenderer blocks plug-ins from running until the user chooses to navigate to the page. Pinkie discovered that navigating to a pre-rendered page would inadvertently run all plug-ins—even Native Client plug-ins, which are otherwise permitted only for installed extensions and apps.

    Of course, getting a Native Client plug-in to execute doesn’t buy much, because the Native Client process’ sandbox is even more restrictive than Chrome’s sandbox for HTML content. What Native Client does provide, however, is a low-level interface to the GPU command buffers, which are used to communicate accelerated graphics operations to the GPU process. This allowed Pinkie to craft a special command buffer to exploit the following integer underflow bug (117656) in the GPU command decoding:

    static uint32 ComputeMaxResults(size_t size_of_buffer) { return (size_of_buffer - sizeof(uint32)) / sizeof(T); } 

    The issue here is that if size_of_buffer is smaller than sizeof(uint32), the result would be a huge value, which was then used as input to the following function:

    static size_t ComputeSize(size_t num_results) { return sizeof(T) * num_results + sizeof(uint32); } 

    This calculation then overflowed and made the result of this function zero, instead of a value at least equal to sizeof(uint32). Using this, Pinkie was able to write eight bytes of his choice past the end of his buffer. The buffer in this case is one of the GPU transfer buffers, which are mapped in both processes’ address spaces and used to transfer data between the Native Client and GPU processes. The Windows allocator places the buffers at relatively predictable locations; and the Native Client process can directly control their size as well as certain object allocation ordering. So, this afforded quite a bit of control over exactly where an overwrite would occur in the GPU process.

    The next thing Pinkie needed was a target that met two criteria: it had to be positioned within range of his overwrite, and the first eight bytes needed to be something worth changing. For this, he used the GPU buckets, which are another IPC primitive exposed from the GPU process to the Native Client process. The buckets are implemented as a tree structure, with the first eight bytes containing pointers to other nodes in the tree. By overwriting the first eight bytes of a bucket, Pinkie was able to point it to a fake tree structure he created in one of his transfer buffers. Using that fake tree, Pinkie could read and write arbitrary addresses in the GPU process. Combined with some predictable addresses in Windows, this allowed him to build a ROP chain and execute arbitrary code inside the GPU process.

    The GPU process is still sandboxed well below a normal user, but it’s not as strongly sandboxed as the Native Client process or the HTML renderer. It has some rights, such as the ability to enumerate and connect to the named pipes used by Chrome’s IPC layer. Normally this wouldn’t be an issue, but Pinkie found that there’s a brief window after Chrome spawns a new renderer where the GPU process could see the renderer’s IPC channel and connect to it first, allowing the GPU process to impersonate the renderer (bug 117627).

    Even though Chrome’s renderers execute inside a stricter sandbox than the GPU process, there is a special class of renderers that have IPC interfaces with elevated permissions. These renderers are not supposed to be navigable by web content, and are used for things like extensions and settings pages. However, Pinkie found another bug (117417) that allowed an unprivileged renderer to trigger a navigation to one of these privileged renderers, and used it to launch the extension manager. So, all he had to do was jump on the extension manager’s IPC channel before it had a chance to connect.

    Once he was impersonating the extensions manager, Pinkie used two more bugs to finally break out of the sandbox. The first bug (117715) allowed him to specify a load path for an extension from the extension manager’s renderer, something only the browser should be allowed to do. The second bug (117736) was a failure to prompt for confirmation prior to installing an unpacked NPAPI plug-in extension. With these two bugs Pinkie was able to install and run his own NPAPI plug-in that executed outside the sandbox at full user privilege.

    So, that’s the long and impressive path Pinkie Pie took to crack Chrome. All the referenced bugs were fixed some time ago, but some are still restricted to ensure our users and Chromium embedders have a chance to update. However, we’ve included links so when we do make the bugs public, anyone can investigate in more detail.

    In an upcoming post, we’ll explain the details of Sergey Glazunov’s exploit, which relied on roughly 10 distinct bugs. While these issues are already fixed in Chrome, some of them impact a much broader array of products from a range of companies. So, we won’t be posting that part until we’re comfortable that all affected products have had an adequate time to push fixes to their users.

    Posted by Jorge Lucangeli Obes and Justin Schuh, Software Engineers

    [Gd] 1.6.6 SDK Released

    | More

    Google App Engine Blog: 1.6.6 SDK Released

    While the Search API was a feature that was just so exciting we couldn’t wait to share it, we still have our regularly scheduled release for May full of new offerings, fixes and refinements with a little something for everyone.

    Search API

    For the Search API, we’ve included a change that displays the current experimental quota limits in the Admin Console. We've also made several bug fixes and small naming changes in the API to improve consistency. 

    Service Refinements

    As a result of the Master/Slave datastore deprecation, new users will no longer be able to create new Master/Slave applications. We strongly suggest that developers move their existing Master/Slave applications to HRD.

    Feature Updates

    We are always looking for ways to remove our system limits so that developers can get the most out of the App Engine platform. With this release, apps that have billing enabled can now configure up to 100 cron jobs.

    Lastly, we will be prompting a small percentage of admin console users each week to participate in an optional user satisfaction survey.

    Of course, we can’t get to all the new things we have for you here, so don’t forget to read the full release notes for Python, Java, and Go. Stack Overflow for App Engine is an amazing way to get technical help from the community and members of the App Engine team, and we continue the lively discussion about App Engine over on our Google Group.

    - Posted by the Google App Engine Team

    Interested in working with the Google App Engine team? We are hiring solutions architects to help support our premier customers and engage with the community to broaden the impact of Google's cloud offerings.

    [Gd] Beta Channel Update

    | More

    Chrome Releases: Beta Channel Update

    The Beta channel has been updated to 20.0.1132.11 for Windows, Mac, Linux, and Chrome Frame. This build contains several bug and stability fixes. Full details about what changes are in this build are available in the SVN revision logInterested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug.

    Dharani Govindan
    Google Chrome

    Monday, May 21, 2012

    [Gd] MindMeister mind mapping and Google Drive

    | More

    Google Apps Developer Blog: MindMeister mind mapping and Google Drive

    Editor’s note: This is a guest post by Laura Bârlădeanu, lead programmer at MindMeister.
    -- Steve Bazyl

    MindMeister is a market innovator for providing collaborative online mind mapping solutions. Launched in May 2007, our site has since attracted hundreds of thousands of businesses, academic institutions and creative consumers who have mapped over 100 million ideas online. We were one of a few web applications invited to take part in the Google Drive launch earlier this year.


    The goal was to provide users with an intuitive integration between Google Drive and Mindmeister that would cover all the cases provided by the Google Drive guidelines at that time:

    • Create mind maps directly from Google Drive
    • Open mind map files from Google Drive using MindMeister
    • Create a mind map file on Google Drive from MindMeister

    Aside from these main integration points, we wanted to make use of the SDK and provide many useful Google Drive features, so we added a few more requirements to the list:

    • Export all the user’s maps as a backup .zip file on Google Drive
    • Import a file from Google Drive using the Google File Picker
    • Attach a file from Google Drive directly to a node in a mind map
    • Provide users the possibility to share mind maps with their Google contacts
    • Provide users with an application setting that would allow them to sync all their mind maps with Google Drive
    • Allow Google users opening the same file from Google Drive to collaborate in real time on the mind map directly in MindMeister
    • Enable users to login with their Google account without providing any extra information

    Authentication and authorization

    Google Drive applications are required to use OAuth 2.0 as an authorization mechanism, and are recommended to use OpenID Connect for login. The authorization scope for Drive files is added by default for all registered drive apps. Additionally, the application can require extra scopes that would fit its needs. For our requirements, we needed the following scopes:

    • (Drive)
    • (Contacts)
    • (User information)
    • (User email)

    However, we didn’t want the user to turn away from our application by being asked for too many scopes straight from the beginning. Instead, we defined sets of actions that required a subset of these scopes:

    • [‘drive’, ‘profile’, ‘email’] - any Google Drive action
    • [‘profile’, ‘email’] - login with a Google account
    • [‘contacts’, ‘profile’, ‘email’] - access the user’s Google contacts

    Whenever the user wanted to execute an action that would require more scopes than they initially provided, we redirected them to a Google authorization dialog that requested the extra scope. Upon authorization, we stored the individual refresh tokens for each combination of scopes in a separate model (UserAppTokens).

    Whenever the application needed the refresh token for a set of scopes (eg. for [‘profile’, ‘email’]) it would fetch the refresh token from the database which corresponded to a superset of the required scopes (eg. [‘drive’, ‘profile’, ‘email’] would fit for the required [‘profile’, ‘email’]). The access token would then be obtained from Google and stored in the session for future requests.


    The main challenge we encountered during design and implementation was dealing with the special cases of multiple users (Google users or internal users) editing on the same map which is a Google Drive file, as well as dealing with the special cases of the map being edited in multiple editors. We also had to find a solution for mapping the Google Drive user’s permissions (owner, reader, or writer) to the MindMeister’s existing permission mechanism.

    The MindMeister application is registered for opening four types of files: our own .mind format, MindManager’s .mmap format, Freemind’s .mm format, as well as .xmind. However, since these formats are not 100% compatible with each other, there is always a chance of losing more advanced features when opening a file in a format other than .mind. We wanted to provide the user with the possibility to chose whether the opened file would be saved in its original format, thus risking some features loss, or saving the file in MindMeister format. This option should be per user, per file and with the possibility to be remembered for future files.


    After analyzing the requirements and the use cases, we designed the following architecture:

    Out of sync maps and files

    Using the revision fields in both Map and DriveData we always know if the map has been edited on MindMeister’s side without it being synced with the corresponding file on Google Drive. On the other hand, the token field from DriveData represents the file’s MD5 checksum at the moment of the last update and is supplied via the Google Drive SDK. So if the file is edited externally using another application than MindMeister, we have a mechanism in place for detecting this issue and presenting the user with a few courses of action.

    Handling 3rd party formats

    Upon opening a file that has a different format than .mind, the user is prompted with an option dialog where they can chose if they want the file to be saved back in the same format or in MindMeister’s own format. These options are then remembered in the current session and the per map settings are stored in the extension (the original format) and save_extension (the format to save back in) fields present in the DriveData model.

    Handling user’s permissions

    A map on MindMeister can always be shared with other MindMeister users and the collaborators can have reading or writing access to the map. However, only some of these users will have a corresponding Google account with access to the MindMeister Google Drive application and furthermore, only some of them will have access to the same file on Google Drive with writing permission. This is why it is important for us to know which users can write back to the file and the solution for these access levels was achieved with the help of the permission field in the DriveDataRight model.


    Now more than two weeks on from the Google Drive launch and we can confidently say that our integration was successful, with more than 14,000 new users using Google login and with over 7,000 users that have enabled the Google Drive integration. All in all, the Google Drive SDK was very easy to use and well documented. The developer support, especially, was always there to help and our contacts were open to our suggestions.

    Laura Bârlădeanu

    Laura is the lead programmer at MindMeister, an online mind mapping tool built in HTML5 that features real-time collaboration.


    [Gd] Dev Channel Update

    | More

    Chrome Releases: Dev Channel Update

    The Dev channel has been updated to 21.0.1145.0 for Windows, Mac and Linux platforms


    • Updated V8 -
    • Allow certain unused renderer processes to exit before the tab is closed. (Issue: 126333)  
    • Fix password autofill to work again for Incognito windows (Issue: 117720)
    • Prevent an infinite loop inside SSLClientSocketNSS::OnSendComplete. This has been observed in Chrome OS, but could also happen on other platforms. (Issue: 127822)
    Known Issues
    • In bookmark bubble unable to edit the name and select the sub folder from drop down (Issue: 128612)
    More details about additional changes are available in the svn log of all revisions.

    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

    Karen Grunberg
    Google Chrome