Chromium Blog

Happening now: The Mobile Web State of the Union

Wednesday, May 17, 2017

Welcome to Google I/O 2017! Today at 4PM Pacific Daylight Time, Rahul Roy-chowdhury, VP Product Management for Chrome, will be on stage at Google I/O discussing The Mobile Web: State of the Union. Tune into the livestream below, and if you happen to be attending Google I/O, be sure to come to the Amphitheatre to see it live!

Posted by Ryan Schoen, Product Manager

Improving extension security with out-of-process iframes

Monday, May 8, 2017

Security is critical to Chrome, and many features protect Chrome users as they browse the web. Google Safe Browsing warns users away from websites known to be dangerous. Chrome’s sandbox and multi-process architecture provide additional layers of defense by helping block malware installation and reducing the severity of vulnerabilities. In Chrome 56, we've added yet another layer of defense by fully isolating Chrome extension privileges from web pages.

Chrome has always kept extensions and web pages in different processes where possible, but sometimes extensions host web content in iframes. For example, an extension's options page may include social network buttons or ads. Until recently, these web iframes ran inside the extension's process. This is usually safe because security checks inside that process do not allow web iframes to use extension APIs. However, in rare cases malicious web iframes could exploit bugs to bypass these checks and use the same privileged APIs that are available to extensions, like chrome.history.

Chrome now uses out-of-process iframes to ensure that extension-hosted web iframes are never put into their parent extension process. Even if an extension's web iframe finds a Chrome bug and takes over its own web process, that process won't have access to extension APIs.

With this launch, web iframes in extension pages now run in a separate process from the extension, adding an extra layer of protection to privileged APIs.

Introducing out-of-process iframes will greatly strengthen Chrome's security model, though building them required a large change to Chrome's architecture affecting systems like painting, input events, and navigation. This launch is just the first phase of our Site Isolation project, so stay tuned for even more security improvements that out-of-process iframes make possible.

Posted by Charlie Reis, Site Isolator

Chrome 59 Beta: Headless Chromium, native notifications on macOS, and service worker navigation preload

Tuesday, May 2, 2017

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows. Headless Chromium Headless Chromium allows running Chromium in an automated environment without a user interface or peripherals. This enables use cases such as automating unit tests with Selenium and converting a web page into a PDF.

Headless Chromium is powered by all the modern web platform features provided by Chromium and Blink. Support is now available on Mac and Linux, with a Windows implementation coming soon. Native notifications on macOS Chrome has historically included its own notification system for web and extension developers to send notifications to users. In response to macOS introducing its own rich notification system, many users have asked for the two systems to be integrated.

In Chrome 59, when developers send notifications via the Notifications API or chrome.notifications, they will be shown directly by the macOS native notification system. This change improves the user experience, but some low-usage API features are now discouraged since they result in a degraded experience on macOS, as documented in the migration guide.

Chrome notifications before and after integration with the native notification system.
Service worker navigation preload The Service Worker navigation preload API enables the browser to preload navigation requests while a service worker is starting up. These requests are started before executing the fetch event handler in the service worker intercepting the target URL. This gives the worker access to the preload response inside the fetch event handler, allowing the service worker to handle the navigation with minimal delay. Other features in this release

Developers can now use MediaError.message to obtain greater detail about a MediaError produced by <audio> or <video>.

WritableStreams are now available as part of the Streams API for processing streams of data, while providing a standard abstraction for writing streaming data to a sink with built-in backpressure and queuing.

The Streams API has been expanded with the ability to pipe between ReadableStreams and WritableStreams via the pipeTo() and pipeThrough() methods, allowing easier consumption of streaming data.

Developers can now use the getInstalledRelatedApps function to smartly consolidate push notifications between related web and native apps by suggesting when and on which platform to offer them.

The Image Capture API now allows sites to take higher resolution images than before, providing full control over camera settings such as zoom, ISO, and white balance.

To provide enhanced privacy, CSS stylesheets can now specify their own referrer policy via the HTTP header, rather than always inheriting the referrer policy of the document that originally referenced it.

To avoid over-prompting users, Chrome will now temporarily stop an origin from requesting a permission following the third dismissal of that permission request.

Touch events are now aligned to requestAnimationFrame, ensuring that input is processed as part of the document lifecycle and creating a more efficient and adaptive input response.

The new worker-src Content Security Policy directive restricts which URLs may be loaded as a Worker, SharedWorker, or ServiceWorker.

The Presentation Receiver API is now available, enabling a web page to be presented and developers to interact with the presenting web page.

Deprecations and interoperability improvements

The <dialog> element has changed from display: inline to block by default to better align with the spec.

Following removal from the Media Queries spec, support for hover: on-demand and any-hover: on-demand media queries have been removed.

To better align with spec and help avoid race conditions, decodeAudioData now detaches the given ArrayBuffer before decoding, removing all content from the object and making it unable to be reused or examined.

To increase security, Chrome no longers supports requesting notification permission over HTTP.

The -internal-media-controls-cast-button CSS selector has been removed in favor of the Remote Playback API.

The -internal-media-controls-text-track-list* CSS selectors have been removed in favor of custom-built video controls.

The SVGTests.requiredFeatures attribute has been deprecated following its removal from the spec.

initDeviceMotionEvent() and initDeviceOrientationEvent() were removed in favor of DeviceOrientationEvent() and DeviceMotionEvent(), following a spec trend of moving away from initialization functions and toward constructors.

To preserve consistency across browsers, the sample property will now be included in a violation report (and associated SecurityPolicyViolationEvent object) if a report-sample expression is present in the violated directive.

To increase security, Chrome will now block requests for subresources that contain embedded credentials, and instead handle them as network errors.

To increase security, Chrome will now block requests from HTTP/HTTPS documents to ftp: URLs.

To preserve consistency across browsers, injecting JavaScript via AppleScript is longer supported in Chrome for Mac.

The ability to call Notification.requestPermission() from non-main frames has been deprecated to align the requirements for notification permission with requirements for push notifications, and ease friction for developers. 

Support for Shared Dictionary Compression (SDCH) has been disabled until a stable API has been standardized.

Posted by Sami Kyostila, Headless Honcho

Next steps toward more connection security

Thursday, April 27, 2017

began our questIncognito mode

Treatment of HTTP pages in Chrome 62Our planchange in Chrome 56

Treatment of HTTP pages with user-entered data in Chrome 62alleasier and cheaper than ever beforeset-up guidesPosted by Emily Schechter, Chrome Security Team

Real-world JavaScript performance

Wednesday, April 12, 2017

The V8 JavaScript engine is a cornerstone of fast browsing in Chrome. Over the course of the past year, the V8 team has developed a new method for measuring performance against snapshots of real web pages. Using insights from real-world measurements, the V8 team improved the speed of the average page load in Chrome by 10-20% over the course of the past year.

Historically, JavaScript engines such as V8 used benchmarks like Octane to improve the “peak” performance of JavaScript, or the performance of CPU-intensive script in hot loops. At the beginning of last year, the V8 team started to measure performance with higher fidelity by instrumenting snapshots of popular web pages such as Reddit, Twitter, Facebook, and Wikipedia. This analysis revealed that while peak performance benefits certain types of large web applications, browsing typical websites relies more on “startup” performance, or the speed it takes to start running script. Using insights gleaned from this real-world performance data, the V8 team implemented optimizations which improved mean page load between Chrome 49 and Chrome 56 by 10-20%, depending on CPU architecture.

The web page snapshots also enabled analysis of the differences between various benchmarks and real web workloads. Although no benchmark can be a representative proxy for all sites, the Speedometer benchmark is an approximation of many sites due to its inclusion of real web frameworks including React, Angular, Ember, and jQuery. This similarity can be seen in the startup optimizations above, which also yielded a 25-35% improvement in Chrome’s Speedometer score. Conversely, comparing page snapshots to Octane revealed that Octane was a poor approximation of most websites. Given the plateau of Octane scores across web browsers and the over-optimization of peak performance, we decided to retire the benchmark as a general-purpose measure of real-world JavaScript performance.

V8 performance optimizations improved Chrome's Speedometer score by 25-35% over the past year

Going forward, we plan to ship more JavaScript performance improvements for new patterns of script appearing on the web, including modern libraries, frameworks, and ES2015+ language features. By measuring real-world websites rather than traditional benchmarks, we can better optimize JavaScript patterns that matter most to users and developers. Stay tuned for updates about our new engine architecture, designed for real-world performance.

Posted by Seth Thompson, V8 Track Commentator

Scroll anchoring for web developers

Tuesday, April 11, 2017

One of the strengths of the web is progressive loading, which means that there is no install step and users can start consuming content almost immediately while the site keeps loading. But progressive loading can also result in annoyances, such as an unexpected page jump when offscreen content loads and pushes down what’s currently on the screen. This can be even worse on mobile devices, since smaller screens mean more content is offscreen and page jumps are more likely.

Since its early days, Chrome has taken a stand against bad or abusive content. For instance, Safe Browsing warns users before they visit malicious websites, and visual indicators on tabs allow our users to quickly track down the source of unexpected noise. Similar to other features designed to protect our users from bad experiences, starting in version 56 Chrome prevents these unexpected page jumps with a new feature called scroll anchoring. This feature works by locking the scroll position on an on-screen element to keep our users in the same spot even as offscreen content continues to load.

Side by side comparison of a web page with scroll anchoring disabled (left) and enabled (right).

Due to the expressiveness of the web, there might be some content for which scroll anchoring is either unwanted or misbehaving. For this reason, this feature ships alongside the ”overflow-anchor” CSS property to override the functionality. To further minimize potential issues, scroll anchoring is disabled on complex interactive layouts via suppression triggers, and on back/forward navigations to allow for scroll restoration.

Today, scroll anchoring is preventing about three page jumps per page-view, but with your help it could be even better. Get involved by participating in the scroll anchoring Web Platform Incubator Community Group, submitting feedback via g.co/reportbadreflow, and designing your websites or services with a no-reflow mindset.

Posted by Steve Kobes, “The Unbouncer”

Chrome 58 Beta: IndexedDB 2.0, an improvement to iframe navigation, and immersive full screen for PWAs

Tuesday, March 21, 2017

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows. IndexedDB 2.0 The IndexedDB 2.0 standard is now fully supported in Chrome, making it simpler to work with large data sets in the browser. IDB 2.0 features new schema management, bulk action methods, and more standardized handling of failures.

The structure of a site’s database has large performance impacts and can be difficult to change. To simplify updates, object stores and indexes can now be renamed in-place after a refactoring. Sites can also use more natural keys without worrying about a performance penalty thanks to binary keys, which allow compact representations for custom keys.
Data retrieval is easier with the getKey() and openKeyCursor() methods, which also provide better performance when only a database key is needed. The new continuePrimaryKey() cursor method makes it easier to divide large data access across transactions and page loads without worrying about duplicate primary keys. The getAll() and getAllKeys() methods allow bulk recovery of entire datasets without the need for a cursor. An improvement to iframe navigation

Third-party content, such as advertising, that automatically redirects the page can annoy users and create security issues. Because of this, developers are able to put third-party content inside sandboxed iframes to prevent this behavior. However, in some cases this type of content needs to navigate the top-level page when clicked, like a standard advertisement.

To address this, Chrome 58 now supports the new iframe sandbox keyword allow-top-navigation-by-user-activation. This keyword gives sandboxed iframes the ability to navigate the top-level page when triggered by user interaction, while still blocking auto-redirects. Immersive full screen for PWAs When Progressive Web Apps (PWAs) are launched from the Android Home screen, they launch in a standalone app-like mode that hides the omnibox. This helps create an engaging user experience, and frees up screen space for content. However, for even more immersive experiences like games, video players, or other rich content, other mobile UI elements such as the system bars can still be a distraction.
Now PWAs can provide a fully immersive experience by setting display: fullscreen in their web app manifest, which hides non-app UI when the site is launched from the home screen.

A PWA launched from the home screen (left), launched from the home screen in standalone mode (middle), and launched from the home screen in fullscreen mode (right). Other features in this release

Workers and SharedWorkers can now be created using data: URLs, making development with Workers more secure by giving them an opaque origin.

PointerEvents.getCoalescedEvents() allows developers to access all input events since the last time a PointerEvent was delivered, making it easier for drawing apps to create smoother curves using a precise history of points.

Developers can now customize Chrome’s native media controls such as the download, fullscreen and remoteplayback buttons using the new ControlsList API.

On Chrome for Android, sites installed using the improved Add to Homescreen flow will be allowed to autoplay audio and video served from origins included in the manifest’s scope without restrictions.

On Chrome for Android, videos using the autoplay attribute will be paused when offscreen and resumed when back in view to preserve consistency across browsers.

Sites can now access the approximate range of colors supported by Chrome and output devices using the color-gamut Media Query.

Instead of manually resetting multiple layout properties like float and clear, sites can now add a new block-formatting context using display: flow-root.

To improve JavaScript parsing time, SVGPoint, SVGRect, and SVGMatrix have been transferred to new interfaces outside of Geometry.

Using removeRange(), a new Selection API function, developers can now programmatically remove a specified text Range.

The PointerEvent.tangentialPressure and PointerEvent.twist attributes are now supported on Chrome for Mac to provide more information to stylus devices and painting apps.

To simplify developer experience, trailing commas are now allowed in JavaScript for formal parameter and argument lists.

The WebAudio API’s new playback AudioContextLatencyCategory enables the developer to easily make conscious tradeoffs between latency, power, and CPU efficiency.

Deprecations and interoperability improvements

Apple-interchange-newline, Apple-converted-space, Apple-paste-as-quotation, Apple-style-span, and Apple-tab-span have been deprecated as they are non-standard CSS classes.

usemap attributes now use case-sensitive matching rather than compatibility caseless to better align with spec.

Sites must now use HTTPS when requesting notification permissions or creating non-persistent local notifications with the Notifications API, in accordance with Chrome's policy around powerful features.

To better align with spec, cancelBubble is now considered an alias to stopPropagation() when set to true, and does not do anything when set to false.

The VTTRegion interface functions, addRegion() and removeRegion(), have been removed from the WebVTT spec and are therefore being removed from Chrome.

Top-level navigations to data: URLs have been deprecated to further protect users from spoofing and phishing attempts.

An instance of HTMLEmbedElement or HTMLObjectElement can no longer be called as a function, since the legacy caller has been removed.

Pre-standard ChaCha20-Poly1305 ciphers have been removed following the standardization of these algorithms at the IETF as RFC 7539 and RFC 7905, and the subsequent shipping of the standard versions in Chrome 41.

To improve interoperability, Selection.addRange() now ignores an additional range if it overlaps with an existing range, rather than merging the two ranges.

Encrypted Media Extensions transmitted over non-secure origins has been deprecated per Chrome's policy around powerful features and in compliance with the spec.

The AudioBuffer constructor now accepts the sampleRate member of an AudioBufferOptions dictionary instead of a context argument, simplifying the interface and emphasizing that AudioBuffers can be shared between AudioContexts.

The synchronous FileReaderSync API has been deprecated in service workers, as the service worker spec requires all types of synchronous requests to be initiated outside of a service worker.

The abbr and acronym elements now have a dotted underline by default to align with the HTML standard.

The motion-path, motion-offset, and motion-rotation CSS properties have been removed in favor of the new versions: offset-path, offset-distance, offset-rotate.

When accessing Selection API properties like selectionDirection, selectionStart, and selectionEnd, Chrome will now return null when it would have thrown an InvalidStateError DOMException.

Rather than silently clamping offset values that were too large, the Selection API’s setBaseAndExtent() now throws an IndexSizeError DOMException to better align with spec.

Rather than silently failing for DocumentType node inputs, the Selection API’s setBaseAndExtent(), extend(), and collapse() now throw InvalidNodeTypeError DOMException to better align with spec.

To better align with spec, getRangeAt() now always returns a new Range with position normalization.

The AudioSourceNode interface has been removed as it was not part of the WebAudio spec.

The webkitdropzone attribute has been removed as it was not widely adopted.

Posted by Victor Costan, IndexedDB Interloper