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.




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.

• Developers can use the theme-color meta tag to customize their toolbar color in the app switcher on Android Lollipop.

As always, visit chromestatus.com/features 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 rappor-discuss@googlegroups.com.

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(http://fonts.googleapis.com/earlyaccess/notosansjapanese.css); 

 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 chromestatus.com/features 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

In January, we told you about Chrome Apps for Mobile, a project based on Apache Cordova to run your Chrome Apps on both Android and iOS. The project provides a native application wrapper around your Chrome App, allowing you to distribute it via the Google Play Store and the Apple App Store. Cordova plugins give your App access to a wide range of APIs, including many of the core Chrome APIs. The newest version of Chrome Apps for Mobile includes Chrome APIs for identity, Google Cloud Messaging (GCM) and rich notifications, as well as an improved developer workflow and modern WebView capabilities extended to older versions of Android.

The developer workflow for Chrome Apps for Mobile is now significantly faster and simpler with the new live deploy feature. With live deploy, you can instantly preview the Chrome App you’re editing, running right on your Android or iOS device. When you make a change to the code, you will be able to see it straight away. Live deploy is available in both Chrome Dev Editor (CDE) and the Chrome Apps for Mobile command line tool.

Chrome Apps are at their best when they leverage the powerful functionality and performance of the latest Chromium WebView. The introduction of an updated WebView into Android KitKat paved the way for advanced features such as WebRTC, WebAudio and Accelerated 2D Canvas, and we will continue to see improvements with each new Android release. However, now you have a way to leverage the latest Chromium WebView on any device running Android versions back to Ice Cream Sandwich by bundling your Chrome App with an embeddable Chromium WebView, provided by the Crosswalk open source project.

To show Crosswalk in action, we have taken the Topeka Polymer Web App released at I/O and packaged it as a Chrome App for Mobile, available for you to try out on Android.


The Topeka Android app uses an embedded Crosswalk WebView to achieve smooth performance even on older versions of Android, enabling a full fidelity material design UI with fluid animations and no polyfills. Crosswalk is now readily available through the Chrome Apps for Mobile tooling and should be used with an understanding of its advantages and tradeoffs.

Using Chrome Apps, you can now build performant and capable applications that target desktop, Android, and iOS devices. To get started, take a look at our documentation. As always, we welcome your feedback on Stack Overflow and our G+ Developers page.

Posted by Michal Mocny, Chrome Apps for Mobile Engineer and Mobile Magic Maker

We all develop websites on our desktop and laptop machines, so we tend to initially develop for the desktop experience. But that's increasingly out of sync with our users who, more and more, consume the web on mobile. To deliver a great experience for the web, we need to accurately experience it on mobile. Chrome DevTools has had mobile emulation features for awhile, but it's still too disconnected from real device conditions and requires too much trial and error. Chrome 38 Beta includes a new Device Mode that puts you one click away from emulating mobile devices, inspecting media queries, and emulating flaky network conditions.

Every media query gets represented visually, so you can correlate your breakpoints with the viewport. Clicking one resizes the viewport, making it easier to iterate on your associated styles. If you want to edit the media queries themselves, right-click and jump to the line of CSS where it's defined.

Lastly, device emulation needs to accurately represent the connectivity of your mobile users. For example, a 3G connection significantly limits the experience of your website compared to your speedy office WiFi. The DevTools can now help you emulate the network conditions (both throughput and latency) of connectivity like EDGE, 3G, 4G – and even go offline.

The SHA-1 cryptographic hash algorithm has been known to be considerably weaker than it was designed to be since at least 2005 — 9 years ago. Collision attacks against SHA-1 are too affordable for us to consider it safe for the public web PKI. We can only expect that attacks will get cheaper.

That’s why Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.

SHA-1's use on the Internet has been deprecated since 2011, when the CA/Browser Forum, an industry group of leading web browsers and certificate authorities (CAs) working together to establish basic security requirements for SSL certificates, published their Baseline Requirements for SSL. These Requirements recommended that all CAs transition away from SHA-1 as soon as possible, and followed similar events in other industries and sectors, such as NIST deprecating SHA-1 for government use in 2010.

We have seen this type of weakness turn into a practical attack before, with the MD5 hash algorithm. We need to ensure that by the time an attack against SHA-1 is demonstrated publicly, the web has already moved away from it. Unfortunately, this can be quite challenging. For example, when Chrome disabled MD5, a number of enterprises, schools, and small businesses were affected when their proxy software — from leading vendors — continued to use the insecure algorithms, and were left scrambling for updates. Users who used personal firewall software were also affected.

We plan to surface, in the HTTPS security indicator in Chrome, the fact that SHA-1 does not meet its design guarantee. We are taking a measured approach, gradually ratcheting down the security indicator and gradually moving the timetable up (keep in mind that we release stable versions of Chrome about 6 – 8 weeks after their branch point):

Chrome 39 (Branch point 26 September 2014)

Sites with end-entity (“leaf”) certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

The current visual display for “secure, but with minor errors” is a lock with a yellow triangle, and is used to highlight other deprecated and insecure practices, such as passive mixed content.



Chrome 40 (Branch point 7 November 2014; Stable after holiday season)

Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.

The current visual display for “neutral, lacking security” is a blank page icon, and is used in other situations, such as HTTP.



Chrome 41 (Branch point in Q1 2015)

Sites with end-entity certificates that expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Subresources from such domain will be treated as “active mixed content”.

The current visual display for “affirmatively insecure” is a lock with a red X, and a red strike-through text treatment in the URL scheme.



Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

In April we released chrome.gcm, an API that allows Chrome apps and extensions to use the Google Cloud Messaging (GCM) service to interact with their server-side components via push messaging. Since the new API offers significant improvements and has been used for push messaging in Chrome apps and extensions since May 2014, we are now deprecating the legacy chrome.pushMessaging API.

Developers will start to see a deprecation message in the console if they use chrome.pushMessaging, and no new Chrome apps and extensions will be accepted to the Chrome Web Store if they use the deprecated API. Beginning in mid-January 2015, Chrome apps and extensions that continue to use chrome.pushMessaging will be delisted in the Chrome Web Store. When upgraded to use chrome.gcm, these apps will once again be discoverable via searching and browsing the Web Store. In early March, the chrome.pushMessaging API will be removed and all Chrome apps and extensions that continue to reference it will be automatically disabled. They can be enabled once again when upgraded to use chrome.gcm.

For a high level overview of how an app or extension can leverage chrome.gcm, check out our Google I/O Bytes video. Learn how to upgrade your Chrome apps and extensions by consulting the chrome.gcm API documentation and following this tutorial. Lastly, subscribe to the GCM for Chrome Feedback group to ask questions, get help, and learn more about the transition.

Posted by Jake Leichtling and Filip Gorski, Product Manager and Software Engineer

Today’s Chrome Beta channel release includes a ton of new primitives and APIs to simplify development and give developers more control over their web applications. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.

New HTML element: <picture>

This release adds support for the new <picture> element thanks to the hard work of community contributor Yoav Weiss, who was able to dedicate his time to implementing this feature in multiple rendering engines because of a successful crowdfunding campaign that raised 50% more than its funding goal.

The <picture> element takes the concept of responsive design, previously solved by sending duplicate resources to the client, and bakes an elegant solution right into the web platform. It allows developers to list multiple versions of images that may be appropriate for the browser to display based on screen size, pixel density, or other factors.

On the heels of Tuesday’s release of 64-bit Chrome for Windows, all Mac Chrome users on the beta channel will be updated to a new 64-bit version of Chrome 38. Previously, Chrome was a 32-bit app on Macs. While doubling the number of bits won’t make things twice as good, it does allow us to make a number of speed and security improvements.

64-bit Chrome has become faster as a result of having access to a superior instruction set, more registers, and a more efficient function calling convention. Improved opportunities for ASLR enhance this version’s security. Another major benefit of this change comes from the fact that most programs on a modern Mac are already 64-bit apps. In cases where Chrome was the last remaining 32-bit app, there were launch-time and memory-footprint penalties as 32-bit copies of all of the system libraries needed to be loaded to support Chrome. Now that Chrome’s a 64-bit app too, we expect you’ll find that it launches more quickly and that overall system memory use decreases.

Because of this change, Chrome for Mac will no longer support 32-bit NPAPI plugins, although their 64-bit counterparts are supported. Users shouldn’t notice any changes, because most major plugins are available in both 32-bit and 64-bit form, and many major websites have been switching from NPAPI towards more modern HTML5 APIs. This is also a good time to remind everyone that NPAPI support will be removed from Chrome later this year.

Nearly every Mac user has a computer capable of running this 64-bit version, so we’re automatically updating all Mac Chrome beta channel users. Those few users with first-generation Intel Macs will miss out on the fun, but as we bid them farewell, we’ll remind them that they’ll still be able to run the latest version on the stable channel, Chrome 37.

You can check to see if the Chrome you’re running is a 64-bit version by checking Chrome’s About page (chrome://help) and looking next to the version number. If it says “64-bit” there, that’s a sure sign that you’re running one of these new builds. We hope that this is the only visible difference that you’ll find between the old 32-bit and new 64-bit versions, but in case you find anything amiss during the beta period, please let us know.

Posted by Mark Mentovai, Software Engineer and Register Doubler

64-bit Chrome offers many benefits for speed, stability and security. Our measurements have shown that the native 64-bit version of Chrome has improved speed on many of our graphics and media benchmarks. For example, the VP9 codec that’s used in High Definition YouTube videos shows a 15% improvement in decoding performance. Stability measurements from people opted into our Canary, Dev and Beta 64-bit channels confirm that 64-bit rendering engines are almost twice as stable as 32-bit engines when handling typical web content. Finally, on 64-bit, our defense in depth security mitigations such as Partition Alloc are able to far more effectively defend against vulnerabilities that rely on controlling the memory layout of objects.

At this point 64-bit will remain opt-in, so to take advantage of the improvements click on the new “Windows 64-bit” link on the Chrome download page. Currently, the only significant known issue is the lack of 32-bit NPAPI plugin support. The 32-bit channel will remain fully supported for the foreseeable future and we will continue to support 32-bit plugins until NPAPI is removed from Chrome.

We encourage you to give 64-bit Chrome a try. We’re looking forward to hearing your feedback so we can continue to make Chrome the fastest, most secure and stable browser.

Posted by Will Harris, Software Engineer and Embiggener of Bits

Today’s Chrome Beta channel release includes a slew of new developer features to help you make richer, faster and 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.

DirectWrite on Windows

Chrome 37 adds support for DirectWrite, an API on Windows for clear, high-quality text rendering even on high DPI displays. Before DirectWrite, Chrome used the Graphics Device Interface (GDI) to render text. GDI dates back to the mid-80's and reflects the engineering tradeoffs of that time, particularly for slower, lower-resolution machines. The switch to DirectWrite has been a top user request for years, and required extensive re-architecting and streamlining of Chrome's font rendering engine.

Some users should begin seeing better-looking fonts and increased rendering performance as we roll out DirectWrite, with no changes required by web developers. Assuming everything goes smoothly, all users will experience the improvements by the Chrome 37 stable release.

Compare the below screenshots, taken with and without DirectWrite enabled.

New HTML element: <dialog>

In this release we're also adding support for the <dialog> HTML5 element, which enables developers to create styled dialog boxes in their web applications and control them via a JavaScript API. For more details, check out some code samples and see <dialog> in action. The <dialog> element is a better-designed alternative to showModalDialog(), which is now disabled as we recently announced.

Other updates in this release

• The Web Cryptography JavaScript API is enabled by default starting in Chrome 37, allowing developers to perform cryptographic operations such as hashing, signature generation/verification, and encryption.
• Subpixel font scaling is now supported, which enables smooth animations of text between font sizes.  
• TouchEvent co-ordinates are now doubles instead of longs, enabling higher-fidelity touch interactions on high-DPI displays.
• CSS cursor values "zoom-in" and "zoom-out" are now unprefixed.
• The number of cores on a physical machine can now be accessed by navigator.hardwareConcurrency.
• The user's preferred languages are now accessible by navigator.languages, and the languagechange event is fired when this is updated.
• The CSS Shapes Module allows developers to define non-rectangular text wrapping boundaries around floated elements.
• NPAPI deprecation continues according to our previously-announced plan with a harder-to-bypass blocking UI. 
• The default monospace font on Windows is now Consolas instead of Courier New.
• Cross-origin fonts are now blocked unless the response includes the appropriate CORS headers.

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

Posted by Emil A Eklund, Software Engineer and Senior Blog DirectWriter

The web platform has evolved organically over the past two decades, slowly growing new capabilities and APIs. Many features that are added are great ideas that enable web developers to make even better applications. But some APIs turn out, in retrospect, to be mistakes. Over time, the platform accretes more bad APIs, which makes it harder to add new browser features, confuses web developers, and even introduces security bugs. showModalDialog is a bad API that we deprecated earlier this year, and in Chrome 37 we will disable support for it by default.

showModalDialog was first introduced in Internet Explorer 4 and although it was never formally standardized, over time most other browsers added support for it. It allows applications to show a dialog of HTML content that freezes all other content while showing. showModalDialog is not a commonly used API: based on our usage counters, less than 0.006% of pages use it.

Unfortunately, showModalDialog's unique ability to freeze content is now widely regarded as a mis-feature in terms of user experience, code complexity, and security. From a usability perspective, showModalDialog rudely demands that you interact with it by freezing all of your other tabs—even ones from other sites. showModalDialog also requires complex and hard-to-maintain code scattered throughout the codebase. This complexity complicates the behavior of new web features like Mutation Observers, Object.observe, and Promises. It also makes showModalDialog a source of a disproportionate number of bugs, including serious security vulnerabilities. It is for these reasons that we decided to turn off showModalDialog by default in the next version of Chrome.

Although very few sites use showModalDialog, the small minority that do—disproportionately enterprise sites—have come to rely heavily on it. In order to give these sites more time to update, we have added a temporary Enterprise Policy setting to re-enable showModalDialog. In May 2015 this setting will be removed and showModalDialog will be completely removed from Chromium. Affected sites should begin work to update their sites as soon as possible.

Although it can be difficult, sometimes the only way to go forward is to leave the past behind. Removing bad APIs will help us make the web a more consistent and capable platform for both developers and users.

Posted by Adam Barth, Software Engineer

In 2010, we created packaged apps to fill a missing link between extensions and hosted apps. They look the same as a hosted app to the user, but under the covers, they are more like traditional extensions. Over time, we realized that a clearer separation between the Chrome browser and apps was necessary, both for security reasons and to conform to user expectations. We launched the next generation of Chrome Apps, a new version of packaged apps, last year to address those issues, and today we're announcing the deprecation of legacy packaged apps.

Starting today, no new legacy packaged apps can be published in the Chrome Web Store. In December, all existing legacy packaged app listings will be removed from the Chrome Web Store’s search and browse functions. Existing legacy packaged apps can be updated until Chrome stops loading them in June of 2015. Nothing will change for hosted apps or new packaged apps.

Updated 04/09/2015: The legacy packaged app deprecation schedule has been revised. In August, all existing legacy packaged app listings will be removed from the Chrome Web Store’s search and browse functions. Existing legacy packaged apps can be updated until Chrome stops loading them in February of 2016.

Developers are strongly encouraged to migrate their legacy packaged apps to either Chrome Apps or extensions. To get started, check out our migration tutorial, and contact us on the chromium-apps forum or our G+ page with any questions.

Updated 03/22/2016: The legacy packaged app deprecation schedule has been revised. Existing legacy packaged app listings will be removed from the Chrome Web Store's search and browse functions in late 2016. Chrome will stop loading these apps soon thereafter.

Posted by Amanda Bishop, Product Manager

[Cross-posted from the Google Developers Blog]

Last summer, we launched Chromecast, a small, affordable device that lets you cast online video, music and anything from the web to your TV. Today at Google I/O, we announced Android TV, the newest form factor to the Android platform, and a way to extend the reach of Google Cast to more devices, like televisions, set-top boxes and consoles.

Check out Coming to a Screen Near You for some details on everything we’re doing to make your TV the place to be.

For developers though--sorry, you don’t get to unwind in front of the TV. We need you to get to work and help us create the best possible TV experience, with all of the new features announced at I/O today.

Get started with Android TV
In addition to Google Cast apps that send content to the TV, you can now build immersive native apps and console-style games on Android TV devices. These native apps work with TV remotes and gamepads, even if you don’t have your phone handy. The Android L Developer Preview SDK includes the new Leanback support library that allows you to design smoother, simpler, living room apps.

And this is just the beginning. In the fall, new APIs will allow you to cast directly to these apps, so users can control the app with the phone, the remote, or even their Android Wear watch. You’ll also start seeing Android TV set-top boxes, consoles and televisions from Sony, TP Vision, Sharp, Asus, Razer and more.

Help more users find your Google Cast app
We want to help users more easily find your content, so we’ve improved the Google Cast SDK developer console to let you upload your app icon, app name, and app category for Android, iOS and Chrome. These changes will help your app get discovered on chromecast.com/apps and on Google Play.

Additional capabilities have also been added to the Google Cast SDK. These include: Media Player Library enhancements, bringing easier integration with MPEG-DASH Smooth Streaming, and HLS. We’ve also added WebAudio & WebGL support, made the Cast Companion Library available, and added enhanced Closed Caption support. And coming soon, we will add support for queuing and ID delegation.

Ready to get started? Visit developer.android.com/tv and developers.google.com/cast for the SDKs, style guides, tutorials, sample code, and the API references. You can also request an ADT-1 devkit to bootstrap your Android TV development.

By Dave Burke and Majd Bakar, Engineering Directors and TV Junkies

The web is a rich computing platform with unparalleled reach. In recent years, mobile devices have brought the web to billions of new users and introduced many new device capabilities, screen sizes, input methods, and more. To help developers navigate this brave new world, we built Web Fundamentals, a curated source for modern best practices. Today, we’re making it even easier to build multi-device experiences with the Beta release of the Web Starter Kit.
Web Fundamentals' guidelines are intended to be fundamental to the platform: useful no matter which framework you choose or which browser your users run. We have articles about responsive layouts, forms, touch, media, performance, device capabilities, and setting up a development workflow. Articles cover both coding and design. For example, the article on layout design patterns explains both the usability tradeoffs between different layout options and how to implement them. The performance section complements PageSpeed Insights, an auditing tool that encourages instant (<1 second) mobile web sites.

Designed to help you apply Web Fundamentals' best practices in new projects, Web Starter Kit is a lightweight boilerplate with templates and tooling. Web Starter Kit gives you responsive layout, a visual style guide, and optional workflow features like performance optimization so you can keep your pages lean and fast.


Both Web Fundamentals and the Web Starter Kit are actively developed and curated by a team of developers from Google and several open-source contributors. Our source code is available on GitHub, and we welcome contributions and feedback. Looking ahead, we’ll be adding new content and working with the web development community to refine our advice. Please file an issue or submit a pull request to help us capture web development best practices.

We look forward to a more modern, multi-device web!

Posted by Paul Kinlan, Developer Advocate and Web Fundamentalist

Extensions are a great way to enhance the browsing experience. However, some extensions ask for broad permissions that allow access to sensitive data such as browser cookies or history. Last year, we introduced the Chrome Apps & Extensions Developer Tool, which provides an improved developer experience for debugging apps and extensions. The newest version of the tool, available today, lets power users audit any app or extension and get visibility into the precise actions that it's performing.

Once you’ve installed the Chrome Apps & Extensions Developer Tool, it will start locally auditing your extensions and apps as you use them. For each app or extension, you can see historical activity over the past few days as well as real-time activity by clicking the “Behavior” link. The tool highlights activities that involve your information, such as reading website cookies or modifying web sites, in a privacy section. You can also search for URLs to see if an extension has modified any matching pages. If you’re debugging an app or extension, you can use the “Realtime” tab to watch the stream of API calls as an extension or app runs. This can help you track down glitches or identify unnecessary API calls.

Whether you’re a Chrome power user or a developer testing an extension, the Chrome Apps & Extensions Developer Tool can give you the information you need to understand how apps and extensions affect your browsing.

Posted by Adrienne Porter Felt, Software Engineer and Extension Tinkerer

Today we’re announcing the addition of 64-bit support to Chrome, with two brand new 64-bit Dev and Canary channels for Windows 7 and 8 users, giving a faster and more secure browsing experience. To try it out, download the 64-bit installer from our Canary or Dev download pages. The new version replaces the existing version while preserving all your settings and bookmarks, so there’s no need to uninstall a current installation of Chrome.

The majority of our users on Windows 7 or higher now have systems capable of running 64-bit applications, and this version of Chrome can take full advantage of these newer capabilities. This includes several improvements that align perfectly with Chrome’s core principles of speed, security and stability:

• Speed: 64-bit allows us to take advantage of the latest processor and compiler optimizations, a more modern instruction set, and a calling convention that allows more function parameters to be passed quickly by registers. As a result, speed is improved, especially in graphics and multimedia content, where we see an average 25% improvement in performance.

• Security: With Chrome able to take advantage of the latest OS features such as High Entropy ASLR on Windows 8, security is improved on 64-bit platforms as well. Those extra bits also help us better defend against exploitation techniques such as JIT spraying, and improve the effectiveness of our existing security defense features like heap partitioning.

• Stability: Finally, we’ve observed a marked increase in stability for 64-bit Chrome over 32-bit Chrome. In particular, crash rates for the the renderer process (i.e. web content process) are almost half that of 32-bit Chrome.

We encourage all our users, especially developers, to give the new 64-bit Chrome a spin, and we’re looking forward to hearing your feedback so we can make 64-bit Chrome work great and bring its benefits to our Beta and Stable channel users.

Posted by Will Harris, Software Engineer and Stretcher of Pointers

Last September, we announced our plan to remove NPAPI support from Chrome by the end of 2014. This change will improve Chrome’s security, speed, and stability as well as reduce complexity in the code base. Over the last few quarters, we’ve been encouraged to see an overall 12.9% drop in per-user instantiations of NPAPI plug-ins and declining usage of the most popular NPAPI plug-ins:

Deprecation has proceeded as scheduled. As of September 23rd, 2013, the Chrome Web Store no longer accepts NPAPI-based Apps and Extensions. Webpage-instantiated NPAPI plug-ins have been blocked by default since January 2014 using the infobar UI. NPAPI support was removed from Linux in Chrome 35.

To further prepare users and developers for complete removal, we’ll be making two more updates in the coming weeks. Starting today, the Chrome Web Store will no longer show NPAPI-based Apps and Extension on the home page, search results, and category pages. In Chrome 37, webpage-instantiated NPAPI plug-ins will be blocked using the harder-to-bypass page-action blocking UI.

Most use cases that previously required NPAPI are now supported by JavaScript-based open web technologies. For the few applications that need low-level APIs, threads, and machine-optimized code, Native Client offers the ability to run sandboxed native code in Chrome. To help ease the transition from NPAPI, NaCl recently exposed two new Pepper APIs for media playback and processing. The MediaStreams API enables low latency multimedia playback, and the Hardware Decode API enables efficient video decoding.

For more information, please see the developer NPAPI deprecation guide. We look forward to the transition to a safer, more mobile-friendly web.

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

Today’s 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.

element.animate()

The forthcoming Web Animations JavaScript API lets you animate web content from script. The element.animate() function included in today’s Beta is the first part of the API to ship in Chrome: it makes it possible to create simple CSS Animations using JavaScript. This means that animations can be dynamically generated without paying a CSS style recalculation cost. Animations created in this way are also cancelable and provide guaranteed end events (in contrast, CSS Transitions only generate events if they cause a style change). Here's an example of how you'd use it:

elem.animate([
    {transform: 'translateX(0px)'},
    {transform: 'translateX(100px)'}
], 3000);

HTML Imports

HTML Imports, part of the Web Components standards umbrella, offer a way to include HTML documents in other HTML documents using <link rel="import">:

<head>
  <link rel="import" href="/path/to/imports/stuff.html">
</head>

An HTML Import can contain CSS, JavaScript, HTML, or anything else an .html file can include. This means they provide a convention for bundling related HTML/CSS/JS (even other HTML Imports) into a single package, making them a fantastic tool for delivering Web Components to users.

Data-binding with Object.observe()

Object.observe() lets you observe changes to JavaScript objects. You can define a callback that observes multiple objects and will receive all changes to any objects in a single asynchronous call. This is especially useful for framework authors implementing data-binding.

// Let's say we have a model with data
var model = {};

// Which we then observe
Object.observe(model, function(changes) {

    // This asynchronous callback runs and aggregates changes
    changes.forEach(function(change) {

        // Letting us know what changed
        console.log(change.type, change.name, change.oldValue);
    });

});

Other updates in this release

• Chrome no longer sends touchcancel on touch scroll, improving compatibility with other browsers and making it possible to add touch UI effects like pull-to-refresh without re-implementing scrolling and fling physics in JavaScript.
• Some CSS properties such as scrollTop and offsetHeight will now return fractional values in browser-zoom situations.
• The new WOFF 2.0 Web Font compression format offers a 30% average gain over WOFF 1.0 (up to 50%+ in some cases).
• DevTools now faithfully emulates touch with mouse, allowing you to test touch interactions on Chrome for Android using the mobile emulation feature of DevTools.
• Unprefixed CSS Transforms enables rich web content by allowing elements to be transformed in two-dimensional or three-dimensional space.
• The will-change property allows developers to give a hint about which properties are about to change, which can help reduce delays at the beginning of animations in some cases.

As always, visit chromestatus.com/features for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates!
Posted by Shane Stephens and Doug Stockwell, Animated Software Engineers

In 2009, we developed ThreadSanitizer (aka TSan), a runtime data race detector based on binary translation. The tool helped find thousands of threading errors in various projects, including almost 180 bugs in Chromium. In 2010, we started experimenting with compiler-based instrumentation instead of binary translation, and once the approach had proven itself, our team redesigned ThreadSanitizer from scratch, focusing on compile-time instrumentation for greater speed and accuracy.

The new tool, ThreadSanitizer v2, is now part of both LLVM and GCC. Not only is it able to detect data races in C++ and Go code, but it is also able to report synchronization issues like deadlocks, unjoined threads, destroying locked mutexes, use of async-signal unsafe code in signal handlers, and others.

ThreadSanitizer v2 recognizes atomic operations, so it produces far more accurate reports and can also find bugs in lock-free algorithms, which are hard to detect otherwise. For example, it has helped us find incorrect synchronization in LazyInstance, incorrect lock-free queue implementation, and issues with concurrent sweeping in V8.

The new version is up to 20 times faster than the old ThreadSanitizer, which makes it possible to use it for heavyweight browser tests. Thanks to this, we’ve found several bugs in code that wasn’t covered by smaller unit tests, like races on the WebKit strings, garbage collection in Blink, a use-after-free in Blink, a handful of reports in WebRTC and many more. This has also improved bug reproducibility: the more times the test is repeated, the higher the chance to reproduce a flaky bug.

Over the last half-year almost 100 bugs were detected by the new tool, and we’re actively working on more. Our future plans include extensive use of TSan on ClusterFuzz and adding regular testing for various Chromium subprojects to catch new regressions quickly.

The ThreadSanitizer page contains all of the information necessary to start using the tool in your project. The tool is easy to use and can be integrated with any buildsystem: just add a single compile-time flag and run the program to see the error reports. For Chromium developers there’s a special page with instructions on dev.chromium.org.

Posted by Alexander Potapenko, Software Engineer and Synchronization Lookout

Today’s Chrome Beta channel release includes a slew of 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.

More developer control over touch and zoom input

The touch-action CSS property offers developers a declarative mechanism to selectively disable touch scrolling, pinch-zooming, or double-tap-zooming on parts of their web content. Use cases include precise control over the dreaded 300ms click delay on mobile, reliable side-swipe UIs, and high-fidelity polyfills of Pointer Events. It’s also a prerequisite for future optimizations to enable scrolling and zooming that never block on the main thread. Update May 20th: touch-action has been delayed until Chrome 36.

Also new in this release, web content on desktop computers will now receive mouse scroll wheel events with the ctrlKey modifier set. There are many sites that want to do something more appropriate for the user than trigger browser zoom. For example, when a user holds control and scrolls over a map in Google Maps, they almost certainly want to zoom in on the map, not invoke browser zoom to zoom the page. This change will enable such a use case.

New JavaScript functionality

Chrome 35 includes support for a number of new JavaScript features defined in the ECMAScript 6 standard. Together, they will help JavaScript developers write application logic that is easier to read, more powerful, and more memory efficient.

A Promise represents a value that may not be available yet but will be known at some point in future. With Promises, you can write cleaner asynchronous code. WeakMaps and WeakSets allow you to create efficient, garbage-collected data structures. In both, references to objects are held weakly: if there is no other reference to an object stored in the WeakSet, it can be garbage collected. This helps avoid memory leaks.

Object.observe lets you observe changes to JavaScript objects. Your callback can observe multiple objects and will receive all changes to any objects in a single asynchronous call. This is especially useful for framework authors implementing data-binding.

Update April 29th: Object.observe has been pushed back to Chrome 36.

Unprefixed Shadow DOM

Shadow DOM is one of several new API primitives landing under the Web Components umbrella. It brings reliable composition of user interface elements to the web platform and allow developers to:

1. Scope their HTML markup, CSS, hiding the implementation details of complex components.
2. Build their own first-class elements and APIs just like the <video> or <audio>, when combined with Custom Elements

With Shadow DOM, web frameworks can stop worrying about their widgets inadvertently breaking pages by using conflicting CSS selectors, class or id names, and start relying on DOM as the interoperable way of building components.

Numerous improvements and changes have been made to the specification since the days of the prefixed implementation of Shadow DOM made available in Chrome 25, so if you were already using the prefixed Shadow DOM API please take a look at the latest documentation as well as the up-to-date HTML5 Rocks articles and look for deprecation warnings.

Other new features in this release

• CSS Font Loading can be used to dynamically load font resources. It gives developers more control over the user experience on pages that use Web Fonts. For instance, you can ask Chrome to start downloading the web fonts you'll need on demand and be notified when they become available.
• The SVG 'paint-order' property offers a way to control the order in which fill, stroke and markers are painted.
• The unprefixed version of the Web Audio API.

Removed features

Web platform feature deprecation and removal are important for the health of the web. Removing features allows browser vendors like Chromium to simplify our codebases, minimize security attack surfaces, and, most importantly, evolve the web API surface to address the needs of today’s users and developers.

Features removed in this release include HTMLVideoElement-specific prefixed fullscreen API, TextTrackCue constructor, <isindex>, Legacy Web Notifications, document.createAttributeNS, support for NPAPI on Linux, and Attr.isId, ownerElement, prefix setter. If you’d like to hear more about these changes or participant in discussions, please chime in our mailing list and look for "Intent to Remove" or “Intent to Deprecate” threads.

Recently deprecated features

The most prominent recently deprecated feature is window.showModalDialog, which will be removed in our next release, Chrome 36. Please read Opera’s explanation of the change to learn more. Other deprecated features include Element.setAttributeNodeNS, overflowchanged Event, HTMLSourceElement.media, MediaError.MEDIA_ERR_ENCRYPTED, Prefixed media source extensions, and webkitRequestAnimationFrame. Support for these features will be completely removed from Chrome in a future release.

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

Posted by Rick Byers, Software Engineer and Touch API Tamer