Today’s Chrome Beta channel release includes new Javascript ES6 features and improved workflows for debugging Service Workers and Web Animations. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

ES6 Template Literals

There are many pitfalls of working with strings on the modern web. The Javascript we know today lacks basic string formatting features, doesn’t support multi-line strings, and makes it difficult to protect users from XSS attacks when inserting user-generated content into pages.

Template Literals, introduced in this release, aims to solve these problems. Its basic form adds string formatting into Javascript by providing syntactic sugar for concatenating strings, variables, and the results of functions. Specifically, expressions can be embedded directly into strings when using the backtick operator (`).

var name = "John";
var message = `Hello, ${name}!`;  // Expected result: "Hello John!"

Any code contained within the braces and preceded by the dollar sign will automatically be evaluated and inserted into place.

var message = `1 + 1 = ${1 + 1}!`;  // Expected result: "1 + 1 = 2!"

Besides accepting multi-line strings, Template Literals also introduces the concept of tagged templates which are useful for escaping HTML to prevent XSS attacks and when internationalizing a site.

New features in Chrome Developer Tools

Chrome 36 added Web Animations, unifying several of the animation APIs on the web. This release makes visual debugging easier by allowing developers to slow down playback of their animations on the fly within DevTools.

In Chrome 40 we shipped Service Workers, enabling developers to make their sites load faster and work offline by intercepting network requests to deliver programmatic or cached responses. Until now, developers had to inspect their Service Worker’s cache manually by printing out its contents to the console, making debugging slow. Today’s Beta includes a new section in DevTools for viewing Service Worker caches which can be found by inspecting a Service Worker on chrome://serviceworker-internals.

Other updates in this release

  • ES6 Lexical Declarations cause variables declared with the 'let' keyword to be scoped to their containing block instead of being hoisted to the top of their containing function, giving developers more control over Javascript's tricky scoping rules.
  • The new CSS value image-rendering: pixelated allows scaled images to appear to be composed of very large pixels, trading smooth results for faster image scaling.
  • CSS Media Queries now support any-pointer and any-hover, which function similarly to pointer and hover but can be triggered by any input device, not only the primary one.
  • The Web Audio API now allows developers to temporarily suspend an AudioContext when it’s not in use, improving power consumption. StereoPannerNode is also now supported, enabling left-right panning of an incoming audio stream while maintaining equal power.
  • HTTPS sites that have certificate chains using SHA-1 that are valid past January 1st, 2017 will be treated as “affirmatively insecure” in Chrome UI from this release onwards as part of our plan to gradually sunset SHA-1.

As always, visit for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

`Posted by ${"Erik Arvidsson"}, Software Engineer`

The newest Chrome Beta channel release includes several new developer features to help you make richer, more compelling web content and apps, especially for mobile devices. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

Service Workers

This release adds service workers, a powerful new API that allows developers to make sites work offline by intercepting network requests to deliver programmatic or cached responses. Besides enabling a rich offline experience, developers can also use the API to achieve dramatic performance improvements by caching UI and other common resources between page loads.

A before and after comparison of a repeat visitor loading a site that uses Service Workers.

Unlike other web technologies, the lifetime of a service worker is independent of the page that installed it. This lays the foundation for a new class of web applications with rich background capabilities. For example, future APIs like Push and Background Sync could do their work even after the page is closed, provided the user has given permission.

This release includes two new APIs for use only within service workers. The Fetch API allows service workers to make network requests—including cross-origin—and return the responses to pages they control. The Cache API can save fetched responses and then return them directly the next time the same resource is requested, bypassing the latency-prone network and the eviction-prone HTTP cache.

These APIs are still under active development and we are committed to keeping our implementation in sync with the specifications as they evolve. This release supports a subset of the Cache API, but developers can use a polyfill for full compatibility. If you’re interested in more in-depth information, check out HTML5 Rocks or our collection of useful service worker “recipes.”

Other updates in this release
  • This release brings support for the new directives introduced in Content Security Policy (CSP) Level 2.
  • The new reportValidity method causes Chrome to draw the user’s attention to form fields with validation errors, saving developers from needing to implement this feature manually in JavaScript.
  • Chrome now supports the minlength attribute, a validation feature that allows developers to declare a lower bound on the number of characters a user can input.
  • Thanks to a collaboration with Intel's Open Source Technology Center, Chrome on Mac now uses HarfBuzz for text shaping which improves performance and rendering of non-Latin text, brings new optimizations, and unifies the font system across all platforms.
As always, visit for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

Posted by Dominic Cooney and Joshua Bell, Software Engineers at your service

Last September we announced our plan to remove NPAPI support from Chrome, a change that will improve Chrome’s security, speed, and stability as well as reduce complexity in the code base. Since our last update, NPAPI usage has continued its decline. Given this usage data, we will continue with our deprecation plan.

Monthly Plug-in Launch Percentage

Sept 13 May 14 Oct 14
Silverlight 15% 13.3% 11%
Google Talk 8.7% 8.7% 7%
Java 8.9% 7.2% 3.7%
Facebook 6% 4.2% 3.0%
Unity 9.1% 3.1% 1.9%
Google Earth 9.1% 0.1% 0.1%

Currently Chrome supports NPAPI plugins, but they are blocked by default unless the user chooses to allow them for specific sites (via the page action UI). A small number of the most popular plugins are whitelisted and allowed by default. In January 2015 we will remove the whitelist, meaning all plugins will be blocked by default.

In April 2015 NPAPI support will be disabled by default in Chrome and we will unpublish extensions requiring NPAPI plugins from the Chrome Web Store. Although plugin vendors are working hard to move to alternate technologies, a small number of users still rely on plugins that haven’t completed the transition yet. We will provide an override for advanced users (via chrome://flags/#enable-npapi) and enterprises (via Enterprise Policy) to temporarily re-enable NPAPI while they wait for mission-critical plugins to make the transition.

In September 2015 we will remove the override and NPAPI support will be permanently removed from Chrome. Installed extensions that require NPAPI plugins will no longer be able to load those plugins.

For more details on the timeline, including guidance for NPAPI plugin developers, see the NPAPI deprecation guide. With each step in this transition, we get closer to a safer, more mobile-friendly web.

Posted by Justin Schuh, Software Engineer and Plug-in Retirement Planner

[Cross-posted on the Google Research Blog and the Google Online Security Blog]

At Google, we are constantly trying to improve the techniques we use to protect our users' security and privacy. One such project, RAPPOR (Randomized Aggregatable Privacy-Preserving Ordinal Response), provides a new state-of-the-art, privacy-preserving way to learn software statistics that we can use to better safeguard our users’ security, find bugs, and improve the overall user experience.

Building on the concept of randomized response, RAPPOR enables learning statistics about the behavior of users’ software while guaranteeing client privacy. The guarantees of differential privacy, which are widely accepted as being the strongest form of privacy, have almost never been used in practice despite intense research in academia.  RAPPOR introduces a practical method to achieve those guarantees.

To understand RAPPOR, consider the following example. Let’s say you wanted to count how many of your online friends were dogs, while respecting the maxim that, on the Internet, nobody should know you’re a dog. To do this, you could ask each friend to answer the question “Are you a dog?” in the following way. Each friend should flip a coin in secret, and answer the question truthfully if the coin came up heads; but, if the coin came up tails, that friend should always say “Yes” regardless. Then you could get a good estimate of the true count from the greater-than-half fraction of your friends that answered “Yes”. However, you still wouldn’t know which of your friends was a dog: each answer “Yes” would most likely be due to that friend’s coin flip coming up tails.

RAPPOR builds on the above concept, allowing software to send reports that are effectively indistinguishable from the results of random coin flips and are free of any unique identifiers. However, by aggregating the reports we can learn the common statistics that are shared by many users. We’re currently testing the use of RAPPOR in Chrome, to learn statistics about how unwanted software is hijacking users’ settings.

We believe that RAPPOR has the potential to be applied for a number of different purposes, so we're making it freely available for all to use. We'll continue development of RAPPOR as a standalone open-source project so that anybody can inspect and test its reporting and analysis mechanisms, and help develop the technology. We’ve written up the technical details of RAPPOR in a report that will be published next week at the ACM Conference on Computer and Communications Security.

We’re encouraged by the feedback we’ve received so far from academics and other stakeholders, and we’re looking forward to additional comments from the community. We hope that everybody interested in preserving user privacy will review the technology and share their feedback at

Posted by Úlfar Erlingsson, Tech Lead Manager, Security Research

Every so often when reading a page written in a different language—especially Chinese, Korean, or Japanese (CJK) pages—you might see little boxes where letters should be, something that we call “tofu”. What's happened is that some of the characters are not supported by your computer. In July Google released Noto Sans CJK, the newest font in a family designed to cover 200+ languages in a harmonious way. As of Chrome OS 38, Noto is now the default sans serif and UI font for CJK languages.

Noto supports major living languages such as English, Russian, Greek, Arabic, and Hebrew, as well as widely supported languages such as Cherokee and Sinhala, and even ancient languages like Egyptian hieroglyphics and Imperial Aramaic. The ultimate goal is for Noto to support every character for every language in the world—which will make tofu a thing of the past.

Noto has many advanced features:
  • Pan-CJK: Simplified and Traditional Chinese, Japanese, and Korean, all in a single font.
  • Seven weights: Thin, Light, DemiLight, Regular, Medium, Bold, Black. ChromeOS has default support for Regular and Bold, with more coming soon.
  • Free and open source: Freely available for everyone under the Apache License, v2.0.
  • Comprehensive character coverage: Covers all the CJK Ideographs in the Unicode Basic Multilingual Plane and a few hundred Ideographs in Unicode Plane 2. Also covered are over twelve thousand Korean Hangul characters with full support for Old Hangul. The total number of glyphs in each font instance is exactly 65,536, the maximum number of glyphs allowed by the OpenType font specification. 
  • Region-appropriate glyph forms: CJK-shared ideographic characters follow region writing conventions to look appropriate to Chinese, Japanese, and Korean users. 
  • Harmony: Noto Sans CJK and all other members of the Noto family are visually compatible with Noto Sans for English, so that text mixing English with another language looks harmonious.

In ChromeOS, Noto is now the default “sans serif” font. Developers that want to use Noto on platforms other than ChromeOS can load them as web fonts from Google Fonts: Early Access.

Although Noto's Latin, Greek, and Cryllic (LGC) characters are designed to harmonize with the CJK characters, developers might still want to use more familiar fonts for the LGC text. To support that, Noto is available in different subsets including Japanese, Korean, Simplified Chinese, Traditional Chinese, and all of CJK. Developers can then use CSS's font fallback mechanism to specify a LGC font ahead of a Noto Sans subset.

For example, if you're targeting devices that don't have Noto installed, want to use Arial for LGC characters, and want to use Noto for Japanese characters, you can include the following in your stylesheet:
@import url(; 
 body {
font-family: Arial, 'Noto Sans Japanese', sans-serif;
Shipping Noto by default on ChromeOS is one step towards making “tofu” a thing of the past. You can learn more at the Noto homepage.

Jungshik Shin, Font Harmony Master

Today’s Chrome Beta channel release includes new tools to make web application development simpler and more powerful. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

JavaScript Generators

Writing asynchronous code in JavaScript can be less than straightforward. It often involves several nested functions and non-linear program execution, making it hard to develop, maintain and debug. This is such a common pain point for developers that they've given it a name: callback soup.

Starting today, Chrome Beta supports ES6 Generators. They allow developers to create iterators that pause their execution after yielding a value, and resume again when later invoked. This greatly simplifies the process of developing asynchronous code and reduces dependence on callback functions.

For additional information about Generators, read more about them or see them in action.

Web Animation Playback Control

Web Animations is a powerful new API that unifies all of the animation APIs on the web. We shipped basic support in May with Chrome 36. In this release we've added playback control, with methods such as play(), pause(),  and reverse(), and the ability to jump to a specific point in an animation's timeline. With our initial support, developers could create animations but not precisely control their playback. This next iteration enables animations that can react in real time to user input - as well as a variety of other creative uses.

Web Application Manifest

Previously when developers wanted to allow their web applications to be added to the home screen from Chrome for Android, they had to use a variety of <meta> and <link> tags to trigger this behavior and deliver relevant resources such as icons. Having this embedded in every page was not only repetitive, but was a waste of bandwidth and put extra bits on the critical path.

Starting in Chrome 39, Manifests provide a way to wrap metadata about a web application into a single file, reducing duplication. Developers seeking to enable "add to homescreen" can define a title, landing page, default orientation, and different icons depending on size and screen density. You can see how it works today, but stay tuned for more properties to be added in later releases.

Other updates in this release
  • The Beacon API enables developers to queue asynchronous network requests that will be sent, regardless of whether the user navigates to a new page
  • Scroll offsets (scrollTop, scrollLeft) now return high-precision fractional values in preparation for high-DPI support
  • XMLHttpRequest progress event properties position and totalSize are now deprecated in favor of the loaded and total properties
As always, visit for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

Posted by Mounir Lamouri, the Manifestation of a Software Engineer

[Cross-posted on the Google Online Security Blog]

We work hard to keep you safe online. In Chrome, for instance, we warn users against malware and phishing and offer rewards for finding security bugs. Due in part to our collaboration with the research community, we’ve squashed more than 700 Chrome security bugs and have rewarded more than $1.25 million through our bug reward program. But as Chrome has become more secure, it’s gotten even harder to find and exploit security bugs.

This is a good problem to have! In recognition of the extra effort it takes to uncover vulnerabilities in Chrome, we’re increasing our reward levels. We’re also making some changes to be more transparent with researchers reporting a bug.

First, we’re increasing our usual reward pricing range to $500-$15,000 per bug, up from a previous published maximum of $5,000. This is accompanied with a clear breakdown of likely reward amounts by bug type. As always, we reserve the right to reward above these levels for particularly great reports. (For example, last month we awarded $30,000 for a very impressive report.)

Second, we’ll pay at the higher end of the range when researchers can provide an exploit to demonstrate a specific attack path against our users. Researchers now have an option to submit the vulnerability first and follow up with an exploit later. We believe that this a win-win situation for security and researchers: we get to patch bugs earlier and our contributors get to lay claim to the bugs sooner, lowering the chances of submitting a duplicate report.

Third, Chrome reward recipients will be listed in the Google Hall of Fame, so you’ve got something to print out and hang on the fridge.

As a special treat, we’re going to back-pay valid submissions from July 1, 2014 at the increased reward levels we’re announcing today. Good times.

We’ve also answered some new FAQs on our rules page, including questions about our new Trusted Researcher program and a bit about our philosophy and alternative markets for zero-day bugs.

Happy bug hunting!

Posted by Tim Willis, Hacker Philanthropist, Chrome Security Team