Today we're announcing an update to the Chrome Web Store policy: extensions in the Chrome Web Store must have a single purpose that is narrow and easy-to-understand. While this has always been the intent of the Chrome extension system, not all extensions have lived up to this ideal. These multi-purpose extensions can crowd your browser UI and slow down your web browsing - sometimes significantly. We're making this policy change to fix these problems and give users more control over their browsing experience.

A simple and speedy browsing experience has been part of the core principles of Chrome since the beginning. Simplicity was important to us because browsers had become overly complex, with bulky user interfaces (commonly referred to in the industry as "chrome"). That detracted from the content of the page, which was the whole point of the browser. The name "Chrome" came from this principle as we wanted the browser to be about "content, not chrome."

One significant contributor to the excess of browser chrome at the time were extensions like the then-ubiquitous toolbar. When users installed more than one of these toolbars, the results could be overwhelming.

To keep with our principle of simplicity, we decided to take a different approach. Chrome extensions would be simple and single-purpose in nature, and each would only be allowed a single visible UI "surface" in Chrome, a single browser action or page action button. Toolbars wouldn't be supported by design, and users would have more control over which features they added to their browser.

Unfortunately, in some cases, we couldn't enforce these design goals technically. With content scripts, extension developers have full control over the page, so they can put up as much UI as they want, even going as far as to create toolbars in the page. Others used content scripts to create extensions with more subtle features bundled together that were harder to attribute to specific extensions. In many cases, the Chrome Web Store helped by showing poor reviews when users had noticed bad behavior from a particular extension, but in other cases the connection wasn't clear.

Even worse, when extensions were sideloaded locally on their computer (perhaps bundled as part of another piece of software they installed) the user wouldn't have the benefit of the information in the Chrome Web Store at all, so they might not realize they were agreeing to install an extension with unwanted functionality or poor reviews.

It is for these reasons that we've updated the Chrome Web Store policy to enforce our original single-purpose design goal for extensions. We realize that this will require significant changes for some existing extensions. Some may need to be split into multiple separate extensions. Developers may need to switch to a different approach to monetization, which we've recently made easier by adding payment options to extensions. Since these changes may take some time to implement, we're not going to start enforcing the policy for existing extensions in the Web Store until June 2014. For new extensions, the policy will go into effect immediately.

If you have any questions, please find us in our G+ community, on Stack Overflow, or our mailing list.

Update May 16, 2014: This will begin being enforced for previously grandfathered extensions (those which were in the Web Store prior to Dec 19, 2013) on July 15, 2014.

Posted by Erik Kay, Engineering Director

This week Ecma created a new technical committee named TC52 to publish a standard specification of the Dart language. We’re excited about this milestone in the evolution of Dart and the web.

Dart is ready for standardization. As of last month’s 1.0 SDK release, Dart is now officially stable and mature enough for production use. We’ll be collaborating with the broader web community via TC52 to responsibly evolve the language going forward.

The new standardization process is an important step towards a future where Dart runs natively in web browsers. Dart apps can be fast when compiled to JavaScript, but an embedded Dart VM enables even better performance.

We're thrilled to have a dedicated technical committee working on Dart. We also feel confident that Ecma—the home of standards such as JavaScript, Eiffel, and C#—is the right place to help guide the evolution of the Dart language. If you’d like to get involved, please join the committee.

Posted by Anders Sandholm, Product Manager and Standard Guy

Modern web apps are expected to render and perform on mobile perfectly. That means considering responsive design, 60 fps and connectivity early in the development cycle. With the Beta channel of Chrome for Android and desktop, we’ve made it easier to develop and debug mobile web apps through an improved viewport emulation and zero-config, screencast-enabled remote debugging.

While designing your app, you want to make sure it looks great on multiple screens. DevTools now enables you to go through the popular device screens without leaving the development environment. Just select a device from the Console drawer’s Emulation tab¹ and all the relevant viewport properties will be set for you. We'll run the page through the same mobile viewporting code used in mobile Chrome to get you accurate results. You also have full control of the emulation parameters, such as screen resolution, touch emulation, devicePixelRatio, user agent, sensors and many more.


But what if you need to test the actual web app's performance on a real device?

Chrome Beta – including ChromeOS – now supports native USB discovery of connected devices. Find them under Tools → Inspect Devices menu item, or visit the about:inspect page. There’s no configuration necessary and no need for the adb command line tool or extensions to see all instances of Chrome and WebView on the devices connected to your computer².

While connected over USB, you can screencast the full viewport content from the device to DevTools. The corresponding icon will be shown next to the Elements tab if the inspected device is able to screencast.


Keyboard and mouse events are also sent from DevTools to your device, so you don't even need to touch it while you're testing your apps.



Improved mobile emulation, USB debugging and screencast make it easier to develop, inspect and debug your mobile applications with DevTools. Have a look at Paul Irish’s talk from the Chrome Dev Summit 2013 for a hands-on demo of these features.

Posted by Pavel Feldman, Software Engineer and Viewport Teleporter

1 You need to check “Show 'Emulation' view in console drawer” in DevTool’s Settings→ Overrides to enable the emulation features
2 Windows users need to install the USB device drivers to enable device communication

The latest Chrome Beta channel release includes a slew of new developer features that make the web faster and safer for users. Unless otherwise noted, changes apply to desktop versions of Chrome and Chrome for Android.

Animated WebP

The animated WebP image format offers some important improvements as an alternative to animated GIF, including true alpha channel (8-bit) as compared to a binary (1-bit) alpha in GIFs. Also, each frame can be lossy or lossless as needed. Compare the animated WebP version (372 KB) of the picture below to the animated GIF version (870 KB). The WebP version is 57% smaller.

300ms tap delay removal on Chrome for Android

Starting this release, responsive mobile websites will get a performance boost in Chrome for Android because we’ve disabled double-tap zoom. Previously, to support double-tap zoom, Chrome had to delay every touch event sent to the webpage by 300ms to allow the user to tap a second time. Now mobile-friendly sites that are already formatted to automatically fit in the page width will receive click events instantly and can respond to user input more quickly.

NPAPI plug-ins blocked by default

As we announced a few months ago, all but a handful of Netscape Plugin Application Programming Interface (NPAPI) plug-ins will be blocked by default starting in today’s Beta. Check out the developer guide to learn more.

Vibration API

New in Chrome for Android, the Vibration API allows web developers to programmatically provide tactile feedback in the form of vibration. Use cases include improved accessibility and more engaging browser-based games.

Chrome Apps and Extensions APIs

• signedInDevices API allows you retrieve a list of the user’s signed-in devices.
• MediaGallery API now supports import of Picasa albums.
• The Identity API now provides events such as sign-in and sign-out.
• Websites in incognito tab can now connect to Apps with user consent.
• chrome.runtime API now optionally provides TLS channel ID to extensions or apps to allow for stronger security.

Visit chromestatus.com for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

Posted by Urvang Joshi, Software Engineer and Aspiring Animator

Four years ago we announced SPDY, an experimental protocol designed to make the web faster. It has matured quickly since then: it’s been adopted by Chrome, Opera, Firefox and Internet Explorer, dozens of server and middleware vendors, and many large sites. SPDY also became the foundation of the HTTP/2 protocol developed by the IETF, and is continuing to serve as an experimental ground for prototyping and testing new features for HTTP/2.

When we set out on this journey the objective was to make the web faster and we wanted to share our latest results. Of course, as with every aspect of performance, the numbers vary for each site, based on how it is constructed, the number of downloaded assets and dozens of other criteria. That said, we’ve observed significant performance improvements in latency—as measured by time from first request byte to onload event in the browser—across all of Google’s major web applications.



The above results were measured for Chrome version 29 and compare HTTPS vs. SPDY for each application across millions of real user sessions with various connectivity profiles. SPDY delivers significant latency savings for users with fast connections, at the median, and for the long tail users with high round-trip times.

In parallel with our contributions to the HTTP/2 standard, we continue to prototype further SPDY performance improvements through smarter compression, flow control, and prioritization. Our hope is that each of these will deliver better and faster SPDY and HTTP/2 protocols. We aren’t done yet—there are still many opportunities and ideas to explore to make the web faster!

Posted by Hasan Khalil, Roberto Peon, and Ilya Grigorik, SPeeDY Software Engineers

For the past few years, building multimedia web experiences for mobile devices has been difficult. Phones and tablets are less powerful than their counterparts, and mobile browsers have traditionally had limited API support. Despite these challenges, the mobile web is evolving rapidly. In the last few months alone, Chrome for Android gained support for WebGL, WebRTC, and Web Audio.

“A Journey through Middle-Earth”, our latest Chrome Experiment, demonstrates what’s now possible on the mobile web. Developed by North Kingdom in collaboration with Warner Bros. Pictures, New Line Cinema and Metro-Goldwyn-Mayer Pictures, the experiment uses the latest web technologies to deliver a multimedia experience designed specifically for tablets, phones, and touch-enabled desktops.



Clicking or tapping a location in the map reveals a second layer with horizontal parallax scrolling, again built just with HTML, CSS, and JavaScript. Eventually users reach an immersive WebGL-based 3D environment optimized for Android phones and tablets with high-end GPUs. These environments also use the Web Audio API for interactive audio.

The multi-device web is evolving rapidly, and we’re looking forward to more sites like “A Journey Through Middle-earth” that show the potential of the platform’s latest mobile features. For a deeper technical case study, check out North Kingdom’s new HTML5 Rocks article about using WebGL in Chrome for Android. We’re also planning to host a Google Developers Live session with the team in early December; circle +Google Chrome Developers for details.

Posted by Max Heinritz, Product Manager and (Tolkien) Troll Evader

*Update: you can now read North Kingdom's second HTML5 Rocks case study on building the rest of the HTML5 front-end for "A Journey through Middle-earth".

Today we’re releasing the Dart SDK 1.0, a cross-browser, open source toolkit for structured web applications. In the two years since we first announced Dart, we’ve been working closely with early adopters to mature the project and grow the community. This release marks Dart's transition to a production-ready option for web developers.

The Dart SDK 1.0 includes everything you need to write structured web applications: a simple yet powerful programming language, robust tools, and comprehensive core libraries. Together, these pieces can help make your development workflow simpler, faster, and more scalable as your projects grow from a few scripts to full-fledged web applications.

On the tools side, the SDK includes Dart Editor, a lightweight but powerful Dart development environment. We wanted to give developers the tools to manage a growing code base, so we added code completion, refactoring, jump to definition, a debugger, hints and warnings, and lots more. Dart also offers an instant edit/refresh cycle with Dartium, a custom version of Chromium with the native Dart VM. Outside the browser, the Dart VM can also be used for asynchronous server side computation.

For deployment, dart2js is a translator that allows your Dart code to run in modern browsers. The performance of generated JavaScript has improved dramatically since our initial release and is in many cases getting close to that of idiomatic JavaScript. In fact, the dart2js output of the DeltaBlue benchmark now runs even faster than idiomatic JavaScript. Similarly, dart2js output code size has been reduced substantially. The generated JavaScript for the game Pop, Pop, Win! is now 40% smaller than it was a year ago. Performance of the VM continues to improve as well; it’s now between 42% to 130% faster than idiomatic JavaScript running in V8, depending on the benchmark.

The Dart SDK also features the Pub package manager, with more than 500 packages from the community. Fan favorites include AngularDart and polymer.dart, which provide higher-level frameworks for building web apps. Dart developers can continue using their favorite JavaScript libraries with Dart-JavaScript interop.

Going forward, the Dart team will focus on improving Dartium, increasing Dart performance, and ensuring the platform remains rock solid. In particular, changes to core technologies will be backward-compatible for the foreseeable future.

Today’s release marks the first time Dart is officially production-ready, and we’re seeing teams like Blossom, Montage, Soundtrap, Mandrill, Google's internal CRM app and Google Elections, already successfully using Dart in production. In addition, companies like Adobe, drone.io, and JetBrains have started to add Dart support to their products.

To get started, head over to dartlang.org and join the conversation at our Dartisans community on Google+. We’re excited to see what you will build with the new stable Dart SDK 1.0.

Posted by Lars Bak, Software Engineer and Chief Dartisan

Native Client (NaCl) brings the performance and low-level control of native code to modern web browsers, without sacrificing the security benefits and portability of web applications. By helping developers directly leverage the power of the underlying CPU and GPU, NaCl enables web applications from photo editing and audio mixing, to 3D gaming and CAD modeling. Today, we’re launching Portable Native Client (PNaCl, pronounced pinnacle), which lets developers compile their code once to run on any hardware platform and embed their PNaCl application in any website.

Under the hood, PNaCl works by compiling native C and C++ code to an intermediate representation, rather than architecture-specific representations as in Native Client. The LLVM-style bytecode is wrapped into a portable executable, which can be hosted on a web server like any other website asset. When the site is accessed, Chrome fetches and translates the portable executable into an architecture-specific machine code optimized directly for the underlying device. This translation approach means developers don’t need to recompile their applications multiple times to run across x86, ARM or MIPS devices.


PNaCl unlocks the power of native performance for applications like Bullet physics simulators and Lua interpreters. For now PNaCl is Chrome only, but developers can make their PNaCl applications compatible with other browsers via pepper.js, which allows applications to use the Pepper API from JavaScript.

Portable Native Client provides a natively fast, secure option to meet the demands of a new generation of web applications. As always, we look forward to your questions and feedback on Stack Overflow or our discussion forum, and will host a Google Developers Live event on Thursday, November 14th to answer your questions. Visit gonacl.com for tutorials, documentation, and to get the SDK.

Posted by David Sehr, Summiting Engineer and Mountain Man

Developers of Chrome Apps and extensions have long been familiar with the developer-mode setting of the chrome://extensions tab in the Chrome browser. This tab provides shortcuts for loading unpacked apps and extensions, launching them, inspecting their pages, and more. Today, we are improving this experience by introducing the new Chrome Apps Developer Tool, available now in the Chrome Web Store, which adds some great new features and works as a standalone Chrome App itself:

In addition to a much cleaner and easier-to-use layout, the new tool provides all of the same functionality as the chrome://extensions tab while streamlining the developer workflow:

• Apps and extensions are now listed in separate tabs, reducing the potential for developer confusion and reinforcing the difference between the two item types. This also reduces the size of each list, making it faster to scroll through.
• Unpacked items and installed items are now listed separately, which makes it much easier to quickly see and access your works-in-progress.
• You can individually update specific apps and extensions with one click, instead of having to update all items at once like in the old tab.
• The common actions for each item, such as reload, launch, view permissions, pack, and uninstall, are located right next to that item for fast access.
• The list can now be live-filtered using the Search box at the top right of the page instead of having to use the regular “Find in page” feature of Chrome.

If you’re developing Chrome Apps or extensions and you have at least the latest version of Chrome Beta installed, get the new tool today and send us your feedback on our G+ Developers page or our developer forum.

Posted by Viet Hoa Dinh, Software Engineer and Tooling Taskmaster

Extensions are a great way to enhance the browsing experience; whether users want to quickly post to social networks or to stay up to date with their favorite sports teams. Many services bundle useful companion extensions, which causes Chrome to ask whether you want to install them (or not). However, bad actors have abused this mechanism, bypassing the prompt to silently install malicious extensions that override browser settings and alter the user experience in undesired ways, such as replacing the New Tab Page without approval. In fact, this is a leading cause of complaints from our Windows users.

Since these malicious extensions are not hosted on the Chrome Web Store, it’s difficult to limit the damage they can cause to our users. As part of our continuing security efforts, we’re announcing a stronger measure to protect Windows users: starting in January on the Windows stable and beta channels, we’ll require all extensions to be hosted in the Chrome Web Store. We’ll continue to support local extension installs during development as well as installs via Enterprise policy, and Chrome Apps will also continue to be supported normally.

If your extensions are currently hosted outside the Chrome Web Store you should migrate them as soon as possible. There will be no impact to your users, who will still be able to use your extension as if nothing changed. You could keep the extensions hidden from the Web Store listings if you like. And if you have a dedicated installation flow from your own website, you can make use of the existing inline installs feature.

Protecting our users is a key priority, and we believe this change will help those whose browser has been compromised by unwanted extensions. If you have questions, please get in touch with us on the Chromium extensions group.

Erik Kay, Engineering Director

We created the Octane Benchmark Suite to measure how JavaScript engines perform on tasks that matter to users as well as motivate our own performance work on the V8 JavaScript engine. Today we’re releasing version 2.0 of the suite including a new focus on reducing latency, new benchmarks that target use cases like asm.js and updates to existing benchmarks.


Traditional benchmarks simply measure how quickly JavaScript can be executed. Octane 2.0 additionally measures latency, which is another important aspect of performance that is concerned with the smoothness of execution. In modern JavaScript engines like V8, latency comes from two main sources: compiling JavaScript to machine instructions so it can run faster, and garbage collecting memory that is no longer used. These tasks are computationally intensive and if they run for too long can be visible to users as small hiccups and freezes of JavaScript programs. We've added a modified version of our Mandreel and Splay benchmarks to measure how well JavaScript engines can minimize these pauses.

We’ve also added two new performance tests that target important use cases. One new test is based on the Typescript compiler from Microsoft, a heavy and complex JavaScript application. Its execution stresses raw execution speed, code parsing and the memory subsystem. We've also included the zlib benchmark, an asm.js test from the Mozilla Emscripten suite. Both new benchmarks help measure an engine’s ability to deal with heavy and complex workloads, which are increasingly common in today's web applications.

Finally, we fixed three existing benchmarks to help ensure that they measure what they were intended to:

• Regexp: verify that regexp calculations give the correct results.
• GameBoy Emulator: code that was supposed to run in strict mode now actually runs in strict mode.
• CodeLoad: make sure the code loaded is different on every iteration.

Octane 2.0 represents one more step in our continuing quest to deliver the best possible performance for users. You can run Octane 2.0 in your browser or read the documentation for an in-depth look at the new benchmarks.

Posted by Hannes Payer, Software Engineer and Latency Buster

The Android 4.4, KitKat release contains a new WebView implementation built on Chromium open source technology.

The Chromium WebView is a complete overhaul of the Android WebView API. It means that the same rendering engine and software stack that powers Chrome is available for use by app developers targeting Android 4.4 KitKat, helping power games, social networks, news and blog readers, in-app ads, and of course complete web browsers. With it comes support for the latest HTML5 and CSS features and a dramatic upgrade of V8 for top-end JavaScript performance.

Chromium WebView is present on all devices running Android 4.4 and applications using WebView will transition to it automatically, no user intervention required. We’ve aimed to make the transition simple for developers too, while also paving the way to increased open web standards convergence. Most applications will continue to function unaltered, and we've prepared an Android 4.4 WebView migration guide to walk developers through the important changes.

With DevTools remote debugging support for WebView, developing and analyzing web content inside native Android applications is as easy as debugging a web page on desktop Chrome, offering a productivity boost to developers.


Best of all, it’s entirely open source, and is available in the Android 4.4 KitKat AOSP release built on a snapshot of the latest stable Chromium source tree. We're looking forward to working with the broader Chromium community to continue improving WebView. Watch dev.chromium.org/developers and the chromium-dev mailing list for future updates on getting involved in the Chromium WebView development. In the meantime, you can check out the Chromium WebView FAQ.

Happy developing from all of the Chromium WebView team!

Posted by Jonathan Dixon and Ben Murdoch, Ambassadors of Chocolate Treats

We recently announced the deprecation of NPAPI plug-in support in Chrome. One of the main use cases for NPAPI plugins in Chrome apps and extensions was to connect with native applications installed on the same computer. For example, a native password management application that a user has already installed on the system may want to connect with a Chrome extension to synchronize passwords. To support such use cases without the need for NPAPI, we’ve recently added the Native Messaging API.



To use this API, native applications must register a native messaging host that Chrome apps and extensions can connect to. This is done by installing a special manifest file that defines a name and path to the native messaging host binary, as well as set of app and extension IDs that can connect to it. Once a native messaging host manifest is installed, Chrome apps and extensions can connect to it using simple API:

var port = chrome.extension.connectNative(          "org.chromium.native_messaging_example");

The parameter passed to chrome.extension.connectNative() is the name used to identify the native messaging host. When a native messaging port is created Chrome starts the host in a separate process and communicates with it over the standard input and output streams. The app or extension can send and receive messages from the native application using this simple API:

// Register handler for incoming messages. 
port.onMessage.addListener(function(msg) { 
   console.log("Received " + msg); 
 });

 // Send a message. 
port.postMessage({text: "Hello!"})

It's also possible to send one-off messages without creating a port:

chrome.extension.sendNativeMessage( 
   "org.chromium.native_messaging_example", 
   {messageField: "field value"}, 
   function(response) {
      console.log("Received response" + response); 
   });

For details on how to create and register a native messaging host please refer to the API documentation and check out our sample application, which also includes a simple native messaging host.

The Native Messaging API is available on Windows, OS X and Linux starting from Chrome 29. To learn about other NPAPI alternatives, check out the NPAPI deprecation Chromium wiki page.

Posted by Sergey Ulanov, Software Engineer and Message Dispatcher

The developer updates in today’s Chrome Beta enable a seamless Android web app experience, smoother web payment flows, and portable native code in desktop Chrome. Unless otherwise noted, changes apply to desktop versions of Chrome and Chrome for Android.

Application shortcuts in Chrome for Android

Application shortcuts allow users to add website shortcuts to their Android home screen. Sites launched in this way will open in a normal Chrome for Android window, unless they include the mobile-web-app-capable meta tag. Those sites will instead open in a special fullscreen Chrome for Android window that doesn't display tabs, buttons, menus, or the Omnibox. Try adding a shortcut to weight.aerotwist.com to see this in action:



UPDATE, November 13th: Application shortcuts will now be launching in Chrome 32, not 31.

Payment requestAutocomplete() on Chrome for Android, Windows, Chrome OS

requestAutocomplete() makes it easier for users to fill out online forms by offering web developers programmatic access to the browser’s autocomplete information (with the user’s explicit permission).

For this first release, we’ve made it work for web payments. On sites with requestAutocomplete(), users will be able to either use their existing payment data stored with the browser or enter new details through a browser-provided interface. As a developer, you can continue processing payments with your existing payment processor.


This feature will be rolling out to Beta users in Android, Windows, and Chrome OS in the coming days. A Mac version will be included in a future release.

PNaCl on desktop versions of Chrome

Over the last few years, web applications have benefited tremendously from more powerful processors and faster browsers. For developers looking to improve performance even further, Portable Native Client (PNaCl) now offers the ability to execute native code in the browser. Developers can compile C/C++ code--even complex existing code bases--into a single executable that runs across all desktop versions of Chrome and Chrome OS, no user installation required. PNaCl combines the portability of the web with the performance of native code. For more information, check out gonacl.com.

New Chrome Apps APIs

With URL handlers for apps, Chrome App developers can now specify URLs to be handled by a Chrome App. For example, a document link on a website could open a document editor Chrome App. This gives users more seamless entry points into their favorite Chrome Apps.

Directory access for Apps allows Chrome Apps to access and write to user-approved folders. This feature can be used to share files between a Chrome App and a native app. For example, a Chrome App code editor could modify files managed by a native Git client. Check out the demo to see it in action.

Other new features in this release

• SCTP for WebRTC Data Channel allows P2P data transfers between browsers to be either best effort, reliable, or semi reliable, opening up use cases such as gaming.
• Alpha channel support for WebM video enables transparency masking (a.k.a. green screen effects) in WebM videos.
• Speech recognition with the JavaScript Web Speech API is now supported on Chrome for Android.
• window.devicePixelRatio now takes full-page zoom (but not pinch zoom) into account.
• Support for { alpha: false } in getContext('2d') lets you create an opaque canvas. This is similar to existing WebGL functionality and can improve the rendering performance of your app.
• The Media Source API has been unprefixed and is now supported on Chrome for Android. It allows JavaScript to generate media streams for playback, addressing use cases like adaptive streaming and time shifting live streams.
• 2D canvas now supports the "ellipse" method.
• Support for several Mutation Events has been removed. Consider using MutationObserver instead.

Visit chromestatus.com for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates. We hope you enjoy this Beta release as much as we’ve enjoyed working on it!

Posted by Dan Alcantara, Software Engineer and Screen Real Estate Agent

The Netscape Plug-in API (NPAPI) ushered in an early era of web innovation by offering the first standard mechanism to extend the browser. In fact, many modern web platform features—including video and audio support—first saw mainstream deployment through NPAPI-based plug-ins.

But the web has evolved. Today’s browsers are speedier, safer, and more capable than their ancestors. Meanwhile, NPAPI’s 90s-era architecture has become a leading cause of hangs, crashes, security incidents, and code complexity. Because of this, Chrome will be phasing out NPAPI support over the coming year.

We feel the web is ready for this transition. NPAPI isn’t supported on mobile devices, and Mozilla plans to make all plug-ins except the current version of Flash click-to-play by default. Based on anonymous Chrome usage data, we estimate that only six NPAPI plug-ins were used by more than 5% of users in the last month. Still, we appreciate that it will take time to transition away from NPAPI, so we will be rolling out this change in stages.

Starting in January 2014, Chrome will block webpage-instantiated NPAPI plug-ins by default on the Stable channel. To avoid disruption to users, we will temporarily whitelist the most popular NPAPI plug-ins that are not already blocked for security reasons. These are:

1. Silverlight (launched by 15% of Chrome users last month)
2. Unity (9.1%)
3. Google Earth (9.1%)
4. Java (8.9%) *
5. Google Talk (8.7%)
6. Facebook Video (6.0%)

* Already blocked by default for security reasons. 

In the short term, end users and enterprise administrators will be able to whitelist specific plug-ins. Eventually, however, NPAPI support will be completely removed from Chrome. We expect this to happen before the end of 2014, but the exact timing will depend on usage and user feedback. Note that the built-in Flash plug-in and PDF viewer will be unaffected because they don’t use NPAPI.

The Chrome Web Store will also be phasing out NPAPI support. Starting today, no new Apps or Extensions containing NPAPI-based plug-ins will be allowed in the Web Store. Developers will be able to update their existing NPAPI-based Apps and Extensions until May 2014, when updates will be blocked. Also in May, listings for NPAPI-based Apps and Extensions will be removed from the Web Store home page, search results, and category pages. In September 2014, all existing NPAPI-based Apps and Extensions will be unpublished. Existing installations will continue to work until Chrome fully removes support for NPAPI.

There are several alternatives to NPAPI. In cases where standard web technologies are not yet sufficient, developers and administrators can use NaCl, Apps, Native Messaging API, and Legacy Browser Support to transition from NPAPI. Moving forward, our goal is to evolve the standards-based web platform to cover the use cases once served by NPAPI. 

UPDATES

• November 2013: For more details about NPAPI deprecation, see the NPAPI Deprecation Developer Guide.
• April 2014: NPAPI support was removed from Chrome for Linux in release 35.
• April 2014: Developers will be able to update Apps and Extensions that use NPAPI until their listings are unpublished in September. This deviation from the original schedule is to allow for security updates.
• July 2014: Chrome 37 has switched to a harder-to-bypass blocking UI for NPAPI. 

Justin Schuh, Security Engineer and Plug-in Retirement Planner

Chrome Apps now bring the best of productivity, games and more to your desktop. The Chrome App Launcher is available for Windows and Chrome OS, and today we're unveiling the launcher for Mac OS X on the Chrome Developer Channel.

The launcher provides an easy way to find and launch your Chrome Apps, while at the same time integrating closely with the operating system so that your Chrome Apps behave and feel just like regular native ones. For example, on Macs you can find your Chrome Apps in the launcher, Applications folder, in the Dock and when you do a Spotlight search—just like any other Mac app that you already use.



To get the launcher, just install a Chrome App from the Chrome Web Store, such as this text editor or note-taking app. The first time you install an app, the launcher will show up as an icon in the Dock. Chrome Packaged Apps for the Mac are available in the dev channel of Chrome and will be launched to stable channel soon.

In the meantime, you can build your own packaged app, upload it to the Chrome Web Store and give all of your users access to it via a direct link. Have questions about this or any other Chrome Apps features? We always welcome your feedback on Stack Overflow, our G+ Developers page, or our developer forum.

Posted by Joe Marini, Chrome Developer Advocate and Apps Aficionado

When you’re searching for information, speed matters. We’re always thinking about how to shave milliseconds from every search you do, throughout our products. Last year, we started testing a feature in Chrome to make searching from a new tab faster and simpler. If you use Chrome’s Developer or Beta installs, you may have already seen this in action. Many thanks for your feedback, which has helped us continue to hone the look and feel, and improve average time from query to answer — meaning you can find what you’re looking for even more quickly than before.


Posted by Anantica Singh, Product Manager

Today we launched Chrome 30 on the Beta channel. This release introduces several new developer features for Chrome Apps and Chrome for Android Beta.

WebGL in Chrome for Android

WebGL is a JavaScript API for rendering interactive 3D graphics and 2D graphics. It is now enabled by default in Chrome for Android Beta running on devices with high-end mobile GPUs (this includes Nexus 4 and Nexus 7). Try it out with this racer WebGL demo and others:

DeviceMotion Events in Chrome for Android

This release introduces the device motion part of the Device Orientation API in Chrome for Android Beta. DeviceMotion events provide you information about device acceleration and rotation rates. Check out isthisanearthquake.com to see them in action.

Media Source Extension in Chrome for Android

The MediaSource API allows JavaScript to generate media streams for playback, which enables use cases such as adaptive streaming and time-shifting live streams. It is now enabled by default in Chrome for Android running on Jellybean or higher. This API is especially useful for streaming to mobile devices, where connectivity is often constrained and unpredictable. Play with it on this demo page.

Chrome Apps APIs

Chrome Apps support a few new APIs in this release, including webview.request, media gallery write support, and downloads. Chrome App developers can also now use Chrome Web Store managed in-app payments.

Other platform features in this release

Unless otherwise noted, the changes described below apply to desktop versions of Chrome and Chrome for Android:

• Support for the WebRTC Device Enumeration API allows users to change their microphones and/or camera on the fly without having to restart the WebRTC call.
• DevTools now supports CSS source maps (also known as preprocessors).
• Chrome will now match the behavior of IE and not honor the Refresh header or tags when the URL to be refreshed to has a javascript: scheme. This is done to close down one more XSS vector against poorly constructed sites.
• Two new experimental features landed behind a flag on Chrome for Android: Web Speech API (recognition) and the Vibration API.

Visit chromestatus.com for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

Posted by Sami Kyöstilä, Software Engineer and Mobile Pixel Wrangler

[Cross-posted from the Google Online Security Blog]

One of Google’s core security principles is to engage the community, to better protect our users and build relationships with security researchers. We had this principle in mind as we launched our Chromium and Google Web Vulnerability Reward Programs. We didn’t know what to expect, but in the three years since launch, we’ve rewarded (and fixed!) more than 2,000 security bug reports and also received recognition for setting leading standards for response time.

The collective creativity of the wider security community has surpassed all expectations, and their expertise has helped make Chrome even safer for hundreds of millions of users around the world. Today we’re delighted to announce we’ve now paid out in excess of $2,000,000 (USD) across Google’s security reward initiatives. Broken down, this total includes more than $1,000,000 (USD) for the Chromium VRP / Pwnium rewards, and in excess of $1,000,000 (USD) for the Google Web VRP rewards.

Today, the Chromium program is raising reward levels significantly. In a nutshell, bugs previously rewarded at the $1,000 level will now be considered for reward at up to $5,000. In many cases, this will be a 5x increase in reward level! We’ll issue higher rewards for bugs we believe present a more significant threat to user safety, and when the researcher provides an accurate analysis of exploitability and severity. We will continue to pay previously announced bonuses on top, such as those for providing a patch or finding an issue in a critical piece of open source software.

Interested Chromium researchers should familiarize themselves with our documentation on how to report a security bug well and how we determine higher reward eligibility.

These Chromium reward level increases follow on from similar increases under the Google Web program. With all these new levels, we’re excited to march towards the new milestones and a more secure web.

Posted by Chris Evans and and Adam Mein, Master of Coin

After just one short year and over half a million visitors to the Web Lab exhibition in the Science Museum in London, the lab will close it doors to the public this coming Sunday evening.

Today, with the help of our friends at Tellart and B-Reel, we are open sourcing the two most popular and interactive experiments of the Chrome Web Lab: Universal Orchestra and Sketchbots.

Web Lab was hosted both physically in the museum and virtually online. We learned a lot about building physical exhibits that interact with App Engine and use the latest web technology in Chrome to let users control real hardware. Now that we've open sourced the code, we're excited to show you how we did it.

The Orchestra

The Orchestra was made up of eight custom-built robotic instruments that let you make music with others from anywhere in the world. Now, you can use the same code that was deployed in the exhibit and host your own miniature Orchestra. All you'll need is an Arduino and the plans for a new dinky replica we created especially for this open source project.  We have even integrated WebRTC so you can form your own band from anywhere in the world.  Don’t worry if you're not a hardware expert because we have a full software version too.


The Sketchbot

The Sketchbot was an electronic arm that received over 5,000 commands per second to etch an outline of your face in the sand. The Open Source project includes the code and the hardware designs to build a replica of the Web Lab.  For developers like me who are soldering iron challenged, we have also included instructions and code to build a BergCloud LittlePrinter and a pure software only version.



If you’ve got the maker itch and want to build a Web Lab replica, integrate hardware that we had never envisaged, or are just curious about how we made the Web Lab, you can grab the code from Github.
Be sure to share what you do with the code in our G+ Community.

Paul Kinlan - Chrome Developer Advocate, Open Sourcerer and Wannabe Maker.

The Chrome Web Store has become the home for many different apps, extensions, websites, and themes from a wide variety of publishers.  Until now, the Chrome Web Store was only able to associate a single email address with a publisher’s account, which made it challenging to give more than one person access to the account to manage the inventory. That’s why today we’re introducing Group Publishing, a new feature intended to simplify the management of multiple people accessing an organization’s CWS account.

Many organizations have multiple items that they need to manage—updates need to be published, testers need to be assigned, promotional images need to be rotated, marketing text needs to be tweaked, and so on. With the addition of this much-requested feature, an organization can simply create a Google Group and designate it as the account owner, then add and remove people from the Group as needed.

On the developer dashboard page, click the link to either associate an existing group as the Group Publisher, or create a new one:



Members of a given group can add, edit, and otherwise work with the store items and overall account-related properties that the particular group has responsibility for.

With the new Group Publishing capability, an organization’s engineering, marketing and product management teams can now collaborate much more effectively to better manage their Chrome Web Store presence. Have questions about this or any other Chrome Web Store Feature? We always welcome your feedback on our G+ Developers page or our developer forum.

Wei Zheng, Software Engineer and Google Group Maestro

With Chrome DevTools our goal is to make your experience as a web developer as productive as possible. In the most recent version of Chrome we've added three major new features that will improve your authoring experience more than ever before.

Workspaces allows you to live-edit source files within DevTools with bidirectional disk persistence. CSS preprocessor mapping supports Sass file live-editing in the DevTools, allowing you to instantly see your changes. Finally snippets lets you create, edit, save and execute custom JavaScript snippets.

Workspaces

Within Workspaces you can load complete local filesystem folders (including back-end files such as scripts and build/deployment files) into the DevTools editor and map these to network resources. This enables you to author and tweak your scripts and styles, instantly see those changes reflected in the browser and have them transparently persist to disk—no more switching back and forth between browser and editor. The editor now supports syntax highlighting for a number of languages including PHP, Python, Java, CSS, HTML and of course JavaScript.



CSS preprocessor mapping

CSS preprocessors like Sass make it easier to organize your CSS, but until now tweaking your styles required switching to another program and refreshing Chrome. CSS preprocessor mapping enables live-editing of these sources directly within the Sources panel. To see it in action, just map the .scss file, then Ctrl-click on a property or value to jump to the variable, mixin or function that defined it. Support for other pre-processors such as Less, Stylus and Compass is in the works. Refer to the improved DevTools css-preprocessor documentation for more details and setup instructions.

Snippets

There are times when you want to be able to save smaller scripts, bookmarklets and utilities so that you always have them available while debugging in the browser. Snippets is a new DevTools feature that makes it possible. It allows you to create, store and run JavaScript within the Sources tab. It gives you a multi-line console with syntax-highlight and persistence, making it convenient for prototyping code that is more than a one-liner. There's also a community-curated repository of snippets for developers that contains useful snippets such as color pickers, CSS prettyfiers, logging helpers and much more.

Today’s new features should help make web developers even more productive with DevTools. Please follow us on Google+ at Google Chrome Developers or on Twitter at @ChromiumDev and send feedback at crbug.comhttps://code.google.com/p/chromium/issues/list.

Posted by Vsevolod Vlasov, DevTools Software Engineer and Workspace Ninja