Chromium Blog

A QUIC update on Google’s experimental transport

Friday, April 17, 2015

Last year we announced QUIC, a UDP-based transport protocol for the modern Internet. Over the last quarter, we’ve been increasing the amount of traffic to Google services that is served over QUIC and analyzing QUIC performance at scale. Results so far are positive, with the data showing that QUIC provides a real performance improvement over TCP thanks to QUIC's lower-latency connection establishment, improved congestion control, and better loss recovery.
For latency-sensitive services like web search, the largest gains come from zero-round-trip connection establishment. The standard way to do secure web browsing involves communicating over TCP + TLS, which requires 2 to 3 round trips with a server to establish a secure connection before the browser can request the actual web page. QUIC is designed so that if a client has talked to a given server before, it can can start sending data without any round trips, which makes web pages load faster. The data shows that 75% percent of connections can take advantage of QUIC’s zero-round-trip feature. Even on a well-optimized site like Google Search, where connections are often pre-established, we still see a 3% improvement in mean page load time with QUIC.

Another substantial gain for QUIC is improved congestion control and loss recovery. Packet sequence numbers are never reused when retransmitting a packet. This avoids ambiguity about which packets have been received and avoids dreaded retransmission timeouts. As a result, QUIC outshines TCP under poor network conditions, shaving a full second off the Google Search page load time for the slowest 1% of connections. These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC. This means less time spent staring at the spinner and more time watching videos.
Where do we go from here? Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic, eventually making it the default transport from Google clients — both Chrome and mobile apps — to Google servers. We plan to formally propose QUIC to the IETF as an Internet standard but we have some housekeeping to do first, like changing the wire format and updating our reference implementation from SPDY-over-QUIC to HTTP2-over-QUIC. In the coming months, we also plan to work on lowering handshake overhead to allow better server-side scalability, improving forward error correction and congestion control, and adding support for multipath connections.
If you want to follow along or play around, feel free to check out the code and experiment with it, or join proto-quic@chromium.org as we continue to improve the Internet, one packet at a time.
Posted by SYN, SYN-ACK and ACK (also known as Alyssa Wilk, Ryan Hamilton and Ian Swett)

Chrome 43 Beta: Web MIDI and upgrading legacy sites to HTTPS

Thursday, April 16, 2015

The newest Chrome Beta channel release includes Web MIDI support, new features to improve security and compatibility and a number of small changes to enable developers to build more powerful web applications. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux and Chrome OS. Connecting to MIDI devices from the web MIDI is a well-established communication protocol used by music devices such as synthesizers, DJ decks, and drum machines. In Chrome 43, users are able to use MIDI hardware to create music without installing any specialized software, as the Web MIDI API allows websites to communicate with connected MIDI devices such as a USB-MIDI drum machine plugged into an Android tablet.

Permissions API Until now, websites have been unable to determine the permission state of APIs such as Geolocation. Due to this, sites often attempt to use APIs immediately after page load without pre-existing permission, causing users to see confusing permission prompts with no context or explanation.
The new Permissions API allows developers to query and observe changes to their permission status for Geolocation, Push, Notifications and Web MIDI so they can ask for permission in context, improving the user experience. Moving DOM attributes to the prototype chain In Chrome 43, attributes defined on DOM objects have been moved to the prototype chain, as specified by Web IDL. This change allows developers to efficiently override or create methods on DOM Objects and improves compatibility with Firefox and Internet Explorer. As this subtle change may cause breakages in existing content, developers should use Chrome 43 to test their website to ensure their users don’t experience issues when this release rolls out to all users. Upgrading legacy sites to HTTPS Transitioning large collections of unmodifiable legacy web content to encrypted, authenticated HTTPS connections can be challenging as the content frequently includes links to insecure resources, triggering mixed content warnings. This release includes a new CSP directive, upgrade-insecure-resources, that causes Chrome to upgrade insecure resource requests to HTTPS before fetching them. This change allows developers to serve their hard-to-update legacy content via HTTPS more easily, improving security for their users. Other updates in this release

The Cache Storage API, previously only available in service workers, now provides developers full imperative control over their caching in the page context.

The autocapitalize property is now supported on input and textarea elements, allowing sites to suggest default capitalization for text typed with on-screen keyboards.

Developers can now programmatically trigger copy and cut actions using document.execCommand('copy') and document.execCommand('cut') in response to a user gesture, eliminating the need to use Flash-based workarounds.

The Fetch API now allows developers to directly operate on and incrementally release the bytes of streamed network responses, in contrast to the equivalent XMLHttpRequest functionality that requires developers keep the entire in-progress stream response in memory.

showModalDialog was disabled by default in Chrome 37 and in accordance with the public deprecation timeline, this release removes the Enterprise Policy setting created to temporarily re-enable it.

Chrome OS now fires devicemotion events on pages at a regular interval, allowing developers to track the device’s acceleration in the same way they do on Chrome for Android, Windows, Mac, and Linux.

The Web Audio API now allows developers to selectively disconnect specific connections to an AudioNode or AudioParam, avoiding the audio artifacts caused by disconnecting all inputs and then manually re-connecting those that should have been retained.

Developers using the Web Audio API can now also explicitly close an AudioContext, releasing all allocated system audio resources instead of depending on unpredictable garbage collection.

The nonstandard WebSocket.URL and EventSource.URL were removed in favor of their standard counterparts WebSocket.url and EventSource.url.

CSS animations can now be used without the -webkit prefix.

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 Takashi Toyoshima, Software Engineer and MIDI Music Maker

New JavaScript techniques for rapid page loads

Wednesday, March 18, 2015

Posted by Marja Hölttä and Daniel Vogelheim, Resident Loader Coders
Speed has always been one of Chrome's primary missions, ever since it was included as one of the founding principles in 2008. But speed is about more than just traditional Javascript benchmarks. Ideally every part of a user's interaction with a browser is fast, starting with loading web pages. Chrome is introducing two techniques called script streaming and code caching designed to reduce that painful waiting time spent staring at a white screen, especially on mobile devices.
Script streaming optimizes the parsing of JavaScript files. Previous versions of Chrome would download a script in full before beginning to parse it, which is a straightforward approach but doesn't fully utilize the CPU while waiting for the download to complete. Starting in version 41, Chrome parses async and deferred scripts on a separate thread as soon as the download has begun. This means that parsing can complete just milliseconds after the download has finished, and results in pages loading as much as 10% faster. It's particularly effective on large scripts and slow network connections.

Code caching is another new technique that helps speed up page loading, specifically on repeated visits to the same page. Normally, the V8 engine compiles the page’s JavaScript on every visit, turning it into instructions that a processor understands. This compiled code is then discarded once a user navigates away from the page as compiled code is highly dependent on the state and context of the machine at compilation time. Chrome 42 introduces an advanced technique of storing a local copy of the compiled code, so that when the user returns to the page the downloading, parsing, and compiling steps can all be skipped. Across all page loads, this allows Chrome to avoid about 40% of compile time and saves precious battery on mobile devices.These are two examples of ways Chrome is improving page load time, but page load time is just one way to think about the performance of the browser. Stay tuned for more ways the Chromium project is pushing forward all aspects of performance on the web.

Chrome 42 Beta: Push Notifications, Promoting Add to Home Screen and ES6 Classes

Thursday, March 12, 2015

Posted by John Mellor and Michael van Ouwerkerk, 'appiest Software Engineers in London
The newest Chrome Beta channel release includes support for ES6 Classes and several new features that allow developers to create more immersive web applications. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux and Chrome OS. Push Notifications This release includes two new APIs that together allow sites to push native notifications to their users even after the page is closed—provided the user has granted explicit permission. After the user has granted permission, a developer can use the new Push API to remotely wake up their service worker using Google Cloud Messaging. Once awake, the service worker may run JavaScript for a short period but in this release it is required at minimum to show a user-visible notification. Each notification includes a ‘Site Settings’ button, allowing users to easily disable notifications for a site.

Promoting Add to Home Screen Chrome 32 introduced the ability for Android users to add home screen shortcuts to their favorite websites via a menu item. In this release, users who frequently visit a high-quality web app will see a banner that allows them to add the site to their home screen in one tap.

Sites that wish to take advantage of this new feature must meet eligibility criteria that ensure that users have a good experience when launching sites from the home screen, even when offline. The criteria will evolve over time based on feedback from users and developers, but today they require sites to provide a Web App Manifest, serve all content using HTTPS, and at least partially work offline using a service worker. ES6 Classes Developers often find it hard to adapt to JavaScript’s prototype-based inheritance and although many libraries have introduced their own patterns for emulating classes, the language hasn't yet provided a single, uniform way of describing them.
ES6 classes solve this by providing JavaScript a clean, standardized syntax for classes. This new syntax is available in Chrome 42 for JavaScript written in strict mode. 'use strict';
class Polygon { constructor(height, width) { this.name = 'Polygon'; this.height = height; this.width = width; }
sayName() { log('Hi, I am a ', this.name + '.'); } }
let p = new Polygon(300, 400); Other updates in this release

DevTools now allows developers to visually edit cubic beziers directly from the styles pane, making it easier to understand and modify animations.

The Fetch API is now available in the window context, shared workers, and dedicated workers, providing a new promise-based standard for AJAX requests.

The startRendering method of an OfflineAudioContext instance now returns a promise that resolves when the audio has finished rendering, making it easier to design web apps that work with the Web Audio API.

AudioBufferSourceNode.buffer can no longer be set more than once, protecting developers from the lack of control over when the new source starts.

Chrome OS now supports screen.orientation and fires the DeviceOrientationEvent when the device’s orientation changes significantly, allowing orientation-aware websites to operate correctly on Chrome OS devices.

This release includes an updated and unprefixed implementation of Encrypted Media Extensions, which allows media sites to discover and interact with digital rights management systems..

A new content setting allows users to automatically pause non-primary plugin content to save power. Developers can turn it on to test how it interacts with their content.

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

Freezing Chrome for Ice Cream Sandwich

Tuesday, March 3, 2015

Posted by Aurimas Lutikas, Software Engineer
FAQ's

Pwnium V: the never-ending* Pwnium

Tuesday, February 24, 2015

[Cross-posted on the Google Online Security Blog]Posted by
Pwnium competitione millionCanSecWest

Removing barriers to entry: At Pwnium competitions, a security researcher would need to have a bug chain in March, pre-register, have a physical presence at the competition location and hopefully get a good timeslot. Under the new scheme, security researchers can submit their bugs year-round through the Chrome Vulnerability Reward Program (VRP) whenever they find them.

Removing the incentive for bug hoarding: If a security researcher was to discover a Pwnium-quality bug chain today, it’s highly likely that they would wait until the contest to report it to get a cash reward. This is a bad scenario for all parties. It’s bad for us because the bug doesn’t get fixed immediately and our users are left at risk. It’s bad for them as they run the real risk of a bug collision. By allowing security researchers to submit bugs all year-round, collisions are significantly less likely and security researchers aren’t duplicating their efforts on the same bugs.

Our researchers want this: On top of all of these reasons, we asked our handful of participants if they wanted an option to report all year. They did, so we’re delivering.

Chrome VRPFAQ Chrome VRP page

Beta Channel for the Android WebView

Friday, February 13, 2015

[Cross-posted on the Android Blog]
Many Android apps use a WebView for displaying HTML content. In Android 5.0 Lollipop, Google has the ability to update WebView independently of the Android platform. Beginning today, developers can use a new beta channel to test the latest version of WebView and provide feedback. WebView updates bring numerous bug fixes, new web platform APIs and updates from Chromium. If you’re making use of the WebView in your app, becoming a beta channel tester will give you an early start with new APIs as well as the chance to test your app before the WebView rolls out to your users. The first version offered in the beta channel will be based on Chrome 40 and you can find a full list of changes on the chromium blog entry. To become a beta tester, join the community which will enable you to sign up for the Beta program; you’ll then be able to install the beta version of the WebView via the Play Store. If you find any bugs, please file them on the Chromium issue tracker.
Posted by Richard Coles - Software Engineer, Google London