Planet Chromium

August 18, 2017

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 62.0.3188.4 for Windows and 62.0.3188.2 for Mac, and Linux.




A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.

Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at August 18, 2017 04:53 PM

Dev Channel Update for Chrome OS

The Dev channel has been updated to 61.0.3163.51 (Platform version: 9765.31.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.  A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser). 


Ketaki Deshpande
Google Chrome

by Ketaki Deshpande (noreply@blogger.com) at August 18, 2017 12:38 PM

Chrome for Android Update

Chrome for Android has been updated to version 60.0.3112.107; the update will be available in Google Play over the next few days.  A list of all Chromium changes in this build can be found here.  This release fixes a crash on startup bug, a bug related to copying text, and a rendering issue.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at August 18, 2017 09:15 AM

August 17, 2017

Google Chrome Releases

Stable Channel Update for Chrome OS

The Stable channel has been updated to 60.0.3112.101 (Platform version: 9592.82.0) for most Chrome OS devices (*). This build contains a number of bug fixes, security updates and feature enhancements. Systems will be receiving updates over the next several days. 

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser). 

Josafat Garcia
Google Chrome
(*) Except: Google Chromebook Pixel,(2015), Samsung Chromebook Plus, Dell Chromebook 13 3380, Acer Chromebook 14 for work (CP5-471), Acer Chromebook R13 (CB5-312T), Lenovo N23 Yoga/Flex 11 Chromebook, Acer Chromebook 15 (CB3-532), Samsung Chromebook 3, Acer Chromebook R11 ,  Asus Chromebook C202SA

by Josafat (noreply@blogger.com) at August 17, 2017 07:58 PM

August 16, 2017

Google Chrome Releases

Dev Channel update for Chrome OS

The Dev channel has been updated to 61.0.3163.47 (Platform version: 9765.29.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.  A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser). 


Ketaki Deshpande
Google Chrome

by Ketaki Deshpande (noreply@blogger.com) at August 16, 2017 05:05 PM

Beta Channel Update for Desktop

The beta channel has been updated to 61.0.3163.49 for Windows, Mac, and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at August 16, 2017 02:06 PM

August 15, 2017

Chromium Blog

Chrome 61 Beta: JavaScript modules, Payment Request API on desktop, Web Share API, and WebUSB

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.
JavaScript modules
Modules allow developers to declare a script's dependencies and are already popular in third-party build tools, which use them to bundle only the required scripts. This release adds native support for JavaScript modules via the new <script type=module> element.


Native support means the browser can fetch granular dependencies in parallel, taking advantage of caching, avoiding duplications across the page, and ensuring the script executes in the correct order, all without a build step.


Payment Request API on desktop

The Payment Request API is now available for Windows, Mac, Linux, and ChromeOS, following the announcement of Android support last year. Developers can now offer secure, seamless checkout experiences across platforms. To get started, “check out” our integration guide.
The PaymentRequest process throughout a transaction.

Web Share API

To allow users to easily share content on social networks, developers have had to manually integrate sharing buttons into their site for each social service. This often leads to users not being able to share with the services they actually use, in addition to bloated page sizes and security risks from including third-party code.


Sites can now use the new navigator.share API on Chrome for Android to trigger the native Android share dialog, allowing the user to easily share text or links with any of their installed native apps. In a future release, this API will also be able to share to installed web apps.


The navigator.share API allows the user to share content with a variety of native apps via the native Android share dialog.

WebUSB

Most hardware peripherals such as keyboards, mice, printers, and gamepads are supported by high-level web platform APIs. To use specialized educational, scientific, or industrial USB peripherals, users must find and install potentially unsafe drivers and software with system-level privileges.


Chrome now supports the WebUSB API, allowing web apps to communicate with peripherals given a user's consent. This enables all the functionality provided by these devices, while still preserving the security guarantees of the web.

Other features in this release

  • The Network Information API is now available on desktop as well as Android, enabling sites to access the underlying connection information of a device.
  • Developers can now specify scrolling smoothness via a new optional parameter in existing Scroll APIs or with the scroll-behavior CSS property.
  • The CSSOM View Smooth Scroll API brings native smooth scrolling to the platform through a the scroll-behavior: smooth CSS property or by using the window.scrollTo() DOM scroll method, eliminating the need to implement this behavior with JavaScript
  • CSS color values can now be 8- and 4-digit hex colors of the format #RRGGBBAA and #RGBA.
  • Sites can now access the relative positions of the screen content with the Visual Viewport API, exposing complex functionality like pinch-and-zoom in a more direct way.
  • The Device RAM API is now available, exposing the amount of RAM on a user’s device to sites to optimize overall performance of a web application.
  • When navigating from an installed web app to a site outside the initial web app’s scope, the new site now automatically loads in a Custom Chrome Tab.
  • For video using native controls, Chrome will now automatically expand video to fullscreen when a user rotates their device in an orientation that matches a video playing on the screen.
  • nextHopProtocol is now available in Resource Timing and Navigation Timing, providing access to the network protocol used to fetch a resource.  
  • Sites can now require embedded third-party content to enforce a given Content Security Policy via the new csp attribute on <iframe> elements.
  • The DOMTokenList interface now supports replace() to easily change all identical tokens to a new one, such as active to inactive on expiration.
  • To access a list of attribute names of an element, getAttributeNames() is now supported and gives developers a more direct mechanism than going through the attributes collection.
  • To increase security, sites will now automatically exit full screen if a JavaScript dialog opens.
  • Sites can now access an estimate for the disk space used by a given origin and quota in bytes via the Storage API’s new navigator.storage.estimate() function.
  • To improve the browser’s cache hit rate, URLSearchParams now supports sort() to list all stored name-value pairs.
  • The URLSearchParams constructor has been updated to accept any object as a parameter instead of only other URLSearchParams instances.
  • To prevent the use of mis-issued certificates from going unnoticed, sites can use the new Expect-CT HTTP header which will enable automated reporting and/or enforcement of Certificate Transparency requirements.
  • Chrome will no longer decode frames for videos using Media Source in background tabs.
  • "Non-Live" camera settings such as photo resolution, red eye reduction, and flash mode can now be retrieved with ImageCapture.getPhotoSettings().


Deprecations and interoperability improvements

  • To increase security, resources with URLs containing both \n and < characters will now be blocked.
  • To increase security, support for the Presentation API’s start function has been deprecated and removed for insecure contexts.
  • To increase consistency across on<event> attributes, onwheel attributes have been moved from Element to Window, Document, HTMLElement, and SVGElement.
  • To better follow spec and provide more granular control over the flow of referred content, Chrome now supports three new Referrer Policy values, same-origin, strict-origin, and strict-origin-when-cross-origin.
  • Following the change in spec, the maximum value for colSpan has been decreased from 8190 to 1000.

Posted by Domenic Denicola, Maverick Modulator

by Chrome Blog (noreply@blogger.com) at August 15, 2017 12:44 PM

August 14, 2017

Google Chrome Releases

Stable Channel Update for Desktop

The stable channel has been updated to 60.0.3112.101 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.

A list of changes is available in the log. Interested in switching release channels? Find out how.  If you find a new issue, please let us know by filing a bug.  The community help forum is also a great place to reach out for help or learn about common issues.


Richard Bustamante
Google Chrome

by Richard Bustamante (noreply@blogger.com) at August 14, 2017 02:34 PM

August 11, 2017

V8 JavaScript Engine

About that hash flooding vulnerability in Node.js…

Early July this year, Node.js released a security update for all currently maintained branches to address a hash flooding vulnerability. This intermediate fix comes at the cost of a significant startup performance regression. In the meantime, V8 has implemented a solution which avoids the performance penalty.

In this post, we want to give some background and history on the vulnerability and the eventual solution.

Hash flooding attack

Hash tables are one of the most important data structures in computer science. They are widely used in V8, for example to store an object’s properties. On average, inserting a new entry is very efficient at O(1). However, hash collisions could lead to a worst case of O(n). That means that inserting n entries can take up to O(n²).

In Node.js, HTTP headers are represented as JavaScript objects. Pairs of header name and values are stored as object properties. With cleverly prepared HTTP requests, an attacker could perform a denial-of-service attack. A Node.js process would become unresponsive, being busy with worst-case hash table insertions.

This attack has been disclosed as early as December of 2011, and shown to affect a wide range of programming languages. How come it took this long for V8 and Node.js to finally address this issue?

In fact, very soon after the disclosure, V8 engineers worked with the Node.js community on a mitigation. From Node.js v0.11.8 onwards, this issue had been addressed. The fix introduced a so-called hash seed value. The hash seed is randomly chosen at startup and used to seed every hash value in a particular V8 instance. Without the knowledge of the hash seed, an attacker has a hard time to hit the worst-case, let alone come up with an attack that targets all Node.js instances.

This is part of the commit message of the fix:

This version only solves the issue for those that compile V8 themselves or those that do not use snapshots. A snapshot-based precompiled V8 will still have predictable string hash codes.

Startup snapshot

Startup snapshots are a mechanism in V8 to dramatically speed up both engine startup and creating new contexts (i.e. via the vm module in Node.js). Instead of setting up initial objects and internal data structures from scratch, V8 deserializes from an existing snapshot. An up-to-date build of V8 with snapshot starts up in less than 3ms, and requires a fraction of a millisecond to create a new context. Without the snapshot, startup takes more than 200ms, and a new context more than 10ms. This is a difference of two orders of magnitude.

We covered how any V8 embedder can take advantage of startup snapshots in previous posts.

A pre-built snapshot contains hash tables and other hash-value-based data structures. Once initialized from snapshot, the hash seed can no longer be changed without corrupting these data structures. A Node.js release that bundles the snapshot has a fixed hash seed, making the mitigation ineffective.

That is what the explicit warning in the commit message was about.

Almost fixed, but not quite

Fast-forward to 2015, a Node.js issue reports that creating a new context has regressed in performance. Unsurprisingly, this is because the startup snapshot has been disabled as part of the mitigation. But by that time not everyone participating in the discussion was aware of the reason.

As explained in this post, V8 uses a pseudo-random number generator to generate Math.random results. Every V8 context has its own copy of the random number generate state. This is to prevent Math.random results from being predictable across contexts.

The random number generator state is seeded from an external source right after the context is created. It does not matter whether the context is created from scratch, or deserialized from snapshot.

Somehow, the random number generator state has been confused with the hash seed. As result, a pre-built snapshot started being part of the official release since io.js v2.0.2.

Second attempt

It was not until May 2017, during some internal discussions between V8, Google’s Project Zero, and Google’s Cloud Platform, when we realized that Node.js was still vulnerable to hash flooding attacks.

The initial response came from our colleagues Ali and Myles from the team behind Google Cloud Platform's Node.js offerings. They worked with the Node.js community to disable startup snapshot by default, again. This time around, they also added a test case.

But we did not want to leave it at that. Disabling startup snapshot has significant performance impacts. Over the years, we have added many new language features and sophisticated optimizations to V8. Some of these additions made starting up from scratch even more expensive. Immediately after the security release, we started working on a long-term solution. The goal is to be able to re-enable startup snapshot without becoming vulnerable to hash flooding.

From proposed solutions, we chose and implemented the most pragmatic one. After deserializing from snapshot, we would choose a new hash seed. Affected data structures are then rehashed to ensure consistency.

As it turns out, in an ordinary startup snapshot few data structures are actually affected. And to our delight, rehashing hash tables have been made easy in V8 in the meantime. The overhead this adds is insignificant.

The patch to re-enable startup snapshot has been merged into Node.js. It is part of the recent Node.js v8.3.0 release.

Posted by Yang Guo, aka @hashseed

by Mathias Bynens (noreply@blogger.com) at August 11, 2017 11:42 AM

Google Chrome Releases

Chrome Beta for Android Update

Ladies and gentlemen, behold!  Chrome Beta 61 (61.0.3163.42) for Android has been released and is available in Google Play.  A partial list of the changes in this build is available in the Git log.  Details on new features will soon be available on the Chromium blog, and developers should check out our updates related to the web platform here.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at August 11, 2017 09:13 AM

Monica Dinculescu

Shadow DOM: fast and encapsulated styles

Shadow DOM is a fairly recent-ish spec that gives you DOM tree encapsulation – it’s one of the superhero lions in the Voltron of specs called “Web Components”. Web Components let you create reusable, self-contained components in JavaScript; the Shadow DOM bit makes sure that the CSS and markup you bundle with your implementation is encapsulated, hiding the implementation details of your element.

The idea of encapsulation isn’t new – most programming languages have a way to define “private” bits of code – variables or methods that are irrelevant to the user of that object and make the element work. Messing with them usually voids the contract and breaks the guarantee that the element will continue to work. In these languages you could, instead, use a global variable or method for everything. It’s not a question of whether it will work (it will), but whether it will work over time, in a large code base (it won’t). You know it won’t.

On the web, there’s two kinds of encapsulation we might want: style encapsulation (an element’s styles don’t leak outside) and DOM encapsulation (an element’s internal implementation isn’t visible). This post talks about style encapsulation; tune in soon for the second half of the story – the DOM encapsulation!

Whew, ok then. So then why is CSS encapsulation so hard? And what’s the fastest way to get it?


Tools to the rescue!

🙏 Before you set me on fire on Twitter, hear this: the next paragraph isn’t a criticism of CSS (which I think is the greatest tool for authoring styles) nor a criticism of the tools we use (which I think fill real gaps we have), but a criticism of the standards process itself.

I have a theory that developers will put up with too much when it comes to writing CSS. For a while there, CSS wasn’t moving forward, so people started using tools to get around that. We didn’t have variables or mixins, so we started using preprocessors. We didn’t have style encapsulation, so we started naming things “the right way” with BEM, so that we didn’t accidentally stomp over each other’s styles. We wanted to be able to author CSS from inside a JavaScript component, so we started using CSS-in-JS. We needed all these tools, because “the platform” (read: the browsers that be) wasn’t there, and building these tools showed that there was a need to move forward. For style encapsulation, Shadow DOM is the platform moving forward.

The unsatisfying part of the web is that you don’t have these problems when you build a one page site or app – you have control over your 17 shades of slightly different blue and your custom build pipeline. But when you have big projects, with weird architectures, targeting different platforms and written across different teams, you end up spending a lot of time just setting up infrastructure and build configurations, which kind of sucks.

Existing scoping approaches

So now that you (maybe) believe me that style encapsulation is a good thing, let’s talk about the bunch of ways in which you can get various degrees of it. They basically come in two flavours: encapsulation by convention or encapsulation with buy-in. Here they are (in my opinion), from least to most effective:

1. Better naming strategies

Name your stuff better” works if you have control over the things you are naming. But if you already do, then you probably don’t need style encapsulation in the first place. You can just…not…do the bad things and the stomping. The problem is that if you’re building a third party widget (say, a fancy date picker that everyone in the universe will have to use), or if you’re building something as part of a large team, you have to be very, very careful not to name it anything that anyone out there might ever call it. Not very scientific.

👍 It’s really easy and doesn’t need tools.

👎 It’s really hard if you don’t have tools to enforce it. And doesn’t really work.

2. <iframe>

Ugh, you know it works. Iframes are this special magical portal that teleports any piece of HTML into your piece of HTML, while keeping it wrapped in a safety bubble. But you can’t resize them easily. Or scroll nicely. Or pretend they’re not a teleported piece of code wrapped in a safety bubble. I didn’t even have to doctor this screenshot, it’s real life:

google search suggestions for 'iframes are'

👍 It’s the most encapsulation and abstraction you will ever get on the web.

👎 It’s an iframe.

3. CSS modules

CSS Modules are another approach to faking style encapsulation. It’s basically a smart way of automating BEM, so that you don’t have to worry about choosing the unique class names – there’s a tool that does it for you! It works pretty well, since it prevents any potential name collisions you’ve had with BEM, but at the end of the day, it’s not actually style encapsulation. There’s nothing stopping you from styling any bit of the DOM tree, which means it’s not a very satisfactory answer if you’re in the business of vending, or using, robust third party components.

4. CSS-in-JS

CSS-in-JS is a new approach that lets you author CSS literally in JavaScript. Then, this JavaScript is basically transmogrified into a style, which means that that style is sort of encapsulated – it’s local to that element, and hard to stomp over. There’s several ways to do this, some better than others:

Directly setting the style as an attribute

someElement.style.marginLeft = ‘20px’

This is the worst of all the worlds because the CSS parser can do way fewer optimizations and caching than if you used class names, for example (see a benchmark).

Embedding CSS style strings in your JS output

Something like <div style=”...”> is still pretty terrible for performance. Browsers (or at least Chrome), do a looooooot of string conversions in this case, which means it at least doubles your memory footprint, because the same string has to live both in V8 and Blink. Here’s what happens behind the scenes:

  • Take the JS off the wire, in whatever encoding your page is in
  • Turn it into whatever encoding V8 prefers, for super optimal memory compactness
  • Scan the JavaScript string
  • Parse the JavaScript string
  • Turn it into an internal string for the DOM when you want to apply the styles
  • Potentially re-encode it if you’re unlucky
  • Take the internal string, pass it to Blink (string copies ahoy!)
  • Blink passes it to the CSS parser, which turns it into styles

Compiling out your CSS

Like, into a separate resource, and then applying styles via classes. This works really well, since you’ve used the browser as it wanted to be used. In comparison to the previous case, for a regular <style> in a CSS stylesheet, the browser has the same string and just passes it around:

  • Take the CSS off the wire into Blink
  • Tokenize it
  • Build a DOM tree with the string as a text node
  • Parse the text node
  • Pass it to the CSS parser, which turns it into styles

👍 Managing a giant amount of styles is nice. Style encapsulation is nice. It works extremely well if you’re using a framework that works well with this.

👎 There’s a million ways to do this, and it’s really overwhelming if you are new to it. This approach tends to also be married to a framework, which makes sharing components hard -- both the user and the author of a component need to agree on both the framework and the css-in-js style, which isn’t always possible.

4. Shadow DOM

This is a cheap move: you know this article is about the Shadow DOM, and I left it until the end because I obviously think it’s the best. Shadow DOM was literally built to solve the problem of style and DOM encapsulation. It does the same thing that <input> and <video> elements have been doing for years (hiding their dirty laundry) but in a way that browsers can optimize around.

The reason for that is that browsers have a special style resolver for Shadow DOM trees. Apart from being regular CSS that the browser already knows how to optimize, the CSS inside shadow DOM trees only applies inside that element. This means that changing a class name or style inside of a shadow root won’t affect everything outside it. Since you don’t have to consider the rest of the world, this means style resolution and application is much faster.

The same argument can be made for element authors – since you know that everything inside of your element can’t leak outside, the implementation is much simpler. You don’t have to think about the rest of the world. You only have to consider your element’s public API, and its implementation.

Before you complain that using a Shadow DOM and Web Components means that it absolutely requires JavaScript: this is true. But if you’re in a big team, building the kind of big app where you’re looking to style encapsulation as a solution for your CSS bowl of spaghetti, I’m pretty sure you’re already using JavaScript. And the community has been exploring solutions to server-side rendering Shadow DOM anyway. Tradeoffs be tradeoffs, and this seems like an easy one.

👍 We’ve been complaining that nothing in CSS was helping with style encapsulation and this is literally the platform’s answer to that problem.

👎 Because it’s a new spec, it’s suffering from some growing pains. On older browsers you need a polyfill. If you want reusable elements that are also highly customizable, this style encapsulation might get in the way right now. Thankfully, good people are already working on that. Custom properties are a new spec meant to address this, and the new proposal for theming custom elements is now an editor's draft!


The zen of web development is a small page – reusable components, not a lot of code, no wheels reinvented. Encapsulated styles are better for you as a developer (code can be simpler), and better for you as a platform (code can be faster). And without external tools or iframe nightmares, the only way to get this is Shadow DOM.

August 11, 2017 12:00 AM

August 09, 2017

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 61.0.3163.39 for Windows, Mac, and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at August 09, 2017 02:06 PM

Chrome for Android Update

Chrome for Android has been updated to version 60.0.3112.97; the update will be available in Google Play over the next few days.  A list of all Chromium changes in this build can be found here.  This build fixes a few crash & rendering issues.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at August 09, 2017 11:19 AM

August 08, 2017

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 61.0.3163.38 (Platform version: 9765.21.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.  A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser). 


Ketaki Deshpande
Google Chrome

by Ketaki Deshpande (noreply@blogger.com) at August 08, 2017 07:20 PM

Dev Channel Update for Desktop

The dev channel has been updated to 62.0.3178.0 for Windows, Mac, and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.

Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at August 08, 2017 03:07 PM

August 04, 2017

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 62.0.3175.3 for Windows, 62.0.3175.4 for Mac and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.

Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at August 04, 2017 02:04 PM

Beta Channel Update for Desktop

The Chrome team is excited to announce the promotion of Chrome 61 to the beta channel for Windows, Mac and Linux. Chrome 61.0.3163.31 contains our usual under-the-hood performance and stability tweaks, but there are also some cool new features to explore - please head to the Chromium blog to learn more!


A full list of changes in this build is available in the log.  Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at August 04, 2017 01:15 PM

Dev Channel Update for Chrome OS

The Dev channel has been updated to 61.0.3163.30 (Platform version: 9765.16.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.  A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser). 


Ketaki Deshpande
Google Chrome

by Ketaki Deshpande (noreply@blogger.com) at August 04, 2017 11:57 AM

August 03, 2017

V8 JavaScript Engine

V8 Release 6.1

Every six weeks, we create a new branch of V8 as part of our release process. Each version is branched from V8’s git master immediately before a Chrome Beta milestone. Today we’re pleased to announce our newest branch, V8 version 6.1, which is in beta until its release in coordination with Chrome 61 Stable in several weeks. V8 v6.1 is filled with all sorts of developer-facing goodies. We’d like to give you a preview of some of the highlights in anticipation of the release.

Performance improvements

Visiting all the elements of the Maps and Sets — either via iteration or the Map.prototype.forEach / Set.prototype.forEach methods — became significantly faster, with a raw performance improvement of up to 11× since V8 version 6.0. Check the dedicated blog post for additional information.
In addition to that, work continued on the performance of other language features. For example, the Object.prototype.isPrototypeOf method, which is important for constructor-less code using mostly object literals and Object.create instead of classes and constructor functions, is now always as fast and often faster than using the instanceof operator.
Function calls and constructor invocations with variable number of arguments also got significantly faster. Calls made with Reflect.apply and Reflect.construct received an up to 17× performance boost in the latest version.


Array.prototype.forEach is now inlined in TurboFan and optimized for all major non-holey elements kinds.

Binary size reduction

The V8 team has completely removed the deprecated Crankshaft compiler, giving a significant reduction in binary size. Alongside the removal of the builtins generator, this reduces the deployed binary size of V8 by over 700 KB, depending on the exact platform.

asm.js is now validated and compiled to WebAssembly

If V8 encounters asm.js code it now tries to validate it. Valid asm.js code is then transpiled to WebAssembly. According to V8’s performance evaluations, this generally boosts throughput performance. Due to the added validation step, isolated regressions in startup performance might happen.

Please note that this feature was switched on by default on the Chromium side only. If you are an embedder and want to leverage the asm.js validator, enable the flag --validate-asm.

WebAssembly

When debugging WebAssembly, it is now possible to display local variables in DevTools when a breakpoint in WebAssembly code is hit.


V8 API
Please check out our summary of API changes. This document is regularly updated a few weeks after each major release.


Developers with an active V8 checkout can use git checkout -b 6.1 -t branch-heads/6.1 to experiment with the new features in V8 v6.1. Alternatively you can subscribe to Chrome’s Beta channel and try the new features out yourself soon.

Posted by the V8 team

by Mathias Bynens (noreply@blogger.com) at August 03, 2017 04:48 PM

August 02, 2017

Google Chrome Releases

Stable Channel Update for Desktop

The stable channel has been updated to 60.0.3112.90 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.


A list of changes is available in the log. Interested in switching release channels? Find out how.  If you find a new issue, please let us know by filing a bug.  The community help forum is also a great place to reach out for help or learn about common issues.


Richard Bustamante
Google Chrome

by Richard Bustamante (noreply@blogger.com) at August 02, 2017 02:40 PM

Stable Channel Update for Desktop

The Chrome team is delighted to announce the promotion of Chrome 60 to the stable channel for Windows, Mac and Linux. This will roll out over the coming days/weeks.


Chrome 60.0.3112.78 contains a number of fixes and improvements -- a list of changes is available in the log. Watch out for upcoming Chrome and Chromium blog posts about new features and big efforts delivered in 60.

Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.

This update includes 40 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.

[$10000][728887] High CVE-2017-5091: Use after free in IndexedDB. Reported by Ned Williamson on 2017-06-02
[$5000][733549] High CVE-2017-5092: Use after free in PPAPI. Reported by Yu Zhou, Yuan Deng of Ant-financial Light-Year Security Lab (蚂蚁金服巴斯光年安全实验室) on 2017-06-15
[$3000][550017] High CVE-2017-5093: UI spoofing in Blink. Reported by Luan Herrera on 2015-10-31
[$1000][702946] High CVE-2017-5094: Type confusion in extensions. Reported by Anonymous on 2017-03-19
[$1000][732661] High CVE-2017-5095: Out-of-bounds write in PDFium. Reported by Anonymous on 2017-06-13
[$TBD][714442] High CVE-2017-5096: User information leak via Android intents. Reported by Takeshi Terada on 2017-04-23
[$TBD][740789] High CVE-2017-5097: Out-of-bounds read in Skia. Reported by Anonymous on 2017-07-11
[$TBD][740803] High CVE-2017-5098: Use after free in V8. Reported by Jihoon Kim on 2017-07-11
[$N/A][733548] High CVE-2017-5099: Out-of-bounds write in PPAPI. Reported by Yuan Deng, Yu Zhou of Ant-financial Light-Year Security Lab (蚂蚁金服巴斯光年安全实验室) on 2017-06-15
[$2000][718292] Medium CVE-2017-5100: Use after free in Chrome Apps. Reported by Anonymous on 2017-05-04
[$1000][681740] Medium CVE-2017-5101: URL spoofing in OmniBox. Reported by Luan Herrera on 2017-01-17
[$1000][727678] Medium CVE-2017-5102: Uninitialized use in Skia. Reported by Anonymous on 2017-05-30
[$500][726199] Medium CVE-2017-5103: Uninitialized use in Skia. Reported by Anonymous on 2017-05-25
[$500][729105] Medium CVE-2017-5104: UI spoofing in browser. Reported by Khalil Zhani on 2017-06-02
[$N/A][742407] Medium CVE-2017-6991: Pointer disclosure in SQLite. Reported by Chaitin Security Research Lab (@ChaitinTech) working with Trend Micro's Zero Day Initiative
[$1000][729979] Low CVE-2017-5105: URL spoofing in OmniBox. Reported by Rayyan Bijoora on 2017-06-06
[$TBD][714628] Medium CVE-2017-5106: URL spoofing in OmniBox. Reported by Jack Zac on 2017-04-24
[$N/A][686253] Low CVE-2017-5107: User information leak via SVG. Reported by David Kohlbrenner of UC San Diego on 2017-01-27
[$N/A][695830] Low CVE-2017-5108: Type confusion in PDFium. Reported by Guang Gong of Alpha Team, Qihoo 360 on 2017-02-24
[$N/A][710400] Low CVE-2017-5109: UI spoofing in browser. Reported by José María Acuña Morgado on 2017-04-11
[$N/A][717476] Low CVE-2017-5110: UI spoofing in payments dialog. Reported by xisigr of Tencent's Xuanwu Lab on 2017-05-02

We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.

As usual, our ongoing internal security work was responsible for a wide range of fixes:
  • [748565] Various fixes from internal audits, fuzzing and other initiatives



Interested in switching release channels? Find out how.  If you find a new issue, please let us know by filing a bug.  The community help forum is also a great place to reach out for help or learn about common issues.


Richard Bustamante
Google Chrome

by Richard Bustamante (noreply@blogger.com) at August 02, 2017 01:59 PM

Dev Channel Update for Chrome OS

The Dev channel has been updated to 61.0.3163.20 (Platform version: 9765.13.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.  A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser). 


Ketaki Deshpande
Google Chrome

by Ketaki Deshpande (noreply@blogger.com) at August 02, 2017 12:25 PM

Stable Channel Update for Chrome OS

The Stable channel has been updated to 60.0.3112.80 (Platform version: 9592.71.0) for most Chrome OS devices (*). This build contains a number of bug fixes, security updates and feature enhancements. Systems will be receiving updates over the next several days. Some highlights of these changes are: 
  • Improved support for Auto updates over cellular networks
  • Location and Timezone selection enhancements using cell tower information
  • GPU Rasterization support
  • Device wide support for EAP-TLS Networks

Security Fixes:
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.

  • [740776] Critical CVE-2017-9417: Fix BroadPwn security bug.


If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser). 

Josafat Garcia
Google Chrome
(*) Except: Google Chromebook Pixel, ASUS Chromebook Flip C302, HP Chromebook 13 G1, Samsung Chromebook Plus, Dell Chromebook 13 3380, Chromebook 14 for work (CP5-471), Acer Chromebook R13 (CB5-312T), Lenovo N23 Yoga/Flex 11 Chromebook, Samsung Chromebook 2 11", AOpen Chromebox Mini, AOpen Chromebase Mini, AOpen Chromebox Commercial, Lenovo Thinkpad 11e Chromebook , Acer Chromebook 15 (CB3-532), Samsung Chromebook 3, Acer Chromebook R11 , Chromebook 11 Model 3180, ASUS Chromebook C202SA

by Josafat (noreply@blogger.com) at August 02, 2017 10:16 AM

August 01, 2017

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 61.0.3163.13 (Platform version: 9765.7.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.  A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser). 


Ketaki Deshpande
Google Chrome

by Ketaki Deshpande (noreply@blogger.com) at August 01, 2017 04:36 PM

Chrome for Android Update

Good news, everyone!  Chrome 60 (60.0.3112.78) for Android has been released and will be available on Google Play over the course of the next few weeks.  This release contains performance and stability fixes, as well as a new feature:
  • Clear browsing data more easily
A list of the changes in this build is available in the Git log.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Alex Mineer
Google Chrome

by Alex Mineer (noreply@blogger.com) at August 01, 2017 04:24 PM

Dev Channel Update for Desktop

The dev channel has been updated to 61.0.3163.25/.26 for Windows, 61.0.3163.25 for Mac and Linux.


A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at August 01, 2017 01:33 PM