Efficient And Safe Allocations Everywhere!

Monday, April 12, 2021

In our constant work to improve performance, our engineers sometimes have to seek optimizations in places that most software developers don’t venture. In this post in our series, The Fast and the Curious, a team of senior engineers showed how they approached replacing the system-level memory allocator with an optimized version, yielding significant memory savings -- up to 22% on Windows.
PartitionAlloc is Chromium’s memory allocator, designed for lower fragmentation, higher speed, and stronger security and has been used extensively within Blink (Chromium’s rendering engine). In Chrome 89 the entire Chromium codebase transitioned to using PartitionAlloc everywhere (by intercepting and replacing malloc() and new) on Windows 64-bit and Android. Data from the field demonstrates up to 22% memory savings, and up to 9% improvement in responsiveness and scroll latency of Chrome.

Here's a closer look at memory usage in the browser process for Windows as the M89 release began rolling out in early March:

Background

Chrome is a multi-platform, multi-process, multi-threaded application, serving a wide range of needs, from small embedded WebViews on Android to spacecraft. Performance and memory footprint are of critical importance, requiring a tight integration between Chrome and its memory allocator. But heterogeneity across platforms can be prohibitive with each platform having a different implementation such as tcmalloc on Linux and Chrome OS, jemalloc or scudo on Android, and LFH on Windows.

When we started this project, our goals were to: 1) unify memory allocation across platforms, 2) target the lowest memory footprint without compromising security and performance, and 3) tailor the allocator to optimize the performance of Chrome. Thus we made the decision to use Chromium’s cross-platform allocator, to optimize memory usage for client rather than server workloads and to focus on meaningful end user activities, not micro-benchmarks that wouldn’t really matter in real world usage.

Allocator Security

PartitionAlloc was designed to support multiple independent partitions, i.e. non-overlapping regions of memory. We use these partitions throughout Blink to thwart some forms of type confusion attacks, such as ensuring strings are separated from layout objects. However, this approach only avoids collisions between types that are allocated from different partitions. Furthermore, PartitionAlloc buckets allocations by their sizes, to help avoid type confusion when potentially-colliding objects are of dissimilar size. These techniques work because PartitionAlloc doesn’t re-use address space. Once PartitionAlloc dedicates a region of address space to a certain partition and size bucket, it will always belong to that partition and size bucket.

Additionally, PartitionAlloc protects some of its metadata with guard pages (inaccessible ranges) around memory regions. Not all metadata is equal, however: free-list entries are stored within previously allocated regions, and thus surrounded by other allocations. To detect corrupted free-list entries and off-by-one overflows from client code, we encode and shadow them.
Finally, having our own allocator enables advanced security features like MiraclePtr and *Scan.

Architecture Details

Each partition in PartitionAlloc uses a single, central, slab-based allocator to conserve memory, with a minimal per-thread cache in front for scaling to multi-threaded workloads. This simplicity also pays performance dividends: we’ve extensively profiled and aggressively trimmed the allocator’s fast path, improving thread-local storage access, locks, reducing cache line fetches, and removing branches.

PartitionAlloc pre-reserves slabs of virtual address space. They are gradually backed by physical memory, as allocation requests arrive. Small and medium-sized allocations are grouped in geometrically-spaced, size-segregated buckets, e.g. [241; 256], [257; 288]. Each slab is split into regions (called “slot spans”) that satisfy allocations (“slots”) from only one particular bucket, thereby increasing cache locality while lowering fragmentation. Conversely, larger allocations don’t go through the bucket logic and are fulfilled using the operating system’s primitives directly (mmap() on POSIX systems, and VirtualAlloc() on Windows).

This central allocator is protected by a single per-partition lock. To mitigate the scalability problem arising from contention, we add a small, per-thread cache of small slots in front, yielding a three-tiered architecture:

The first layer (Per-thread cache) holds a small amount of slots belonging to smaller and more commonly used buckets. Because these slots are stored per-thread, they can be allocated without a lock and only requiring a faster thread-local storage lookup, improving cache locality in the process. The per-thread cache has been tailored to satisfy the majority of requests by allocating from and releasing memory to the second layer in batches, amortizing lock acquisition, and further improving locality while not trapping excess memory.

The second layer (Slot span free-lists) is invoked upon a per-thread cache miss. For each bucket size, PartitionAlloc knows a slot span with free slots associated with that size, and captures a slot from the free-list of that span. This is still a fast path, but slower than per-thread cache as it requires taking a lock. However, this section is only hit for larger allocations not supported by per-thread cache, or as a batch to fill the per-thread cache.

Finally, if there are no free slots in the bucket, the third layer (Slot span management) either carves out space from a slab for a new slot span, or allocates an entirely new slab from the operating system, which is a slow but very infrequent operation.

The overall performance and space-efficiency of the allocator hinges on the many tradeoffs across its layers such as how much to cache, how many buckets, and memory reclaiming policy. Please refer to PartitionAlloc to learn more about the design.

All in all, we hope you will enjoy the additional memory savings and performance improvements brought by PartitionAlloc, ensuring a safer, leaner, and faster Chrome for users on Earth and in outer space alike. Stay tuned for further improvements, and support of more platforms coming in the near future.

Posted by Benoît Lizé and Bartek Nowierski, Chrome Software Engineers

Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.
*The core metric measures jank -- delay handling user input -- every 30 seconds.

Don’t Copy That Surface

Monday, April 5, 2021

This post is part of a new series The Fast and the Curious we're bringing you of deeper dives into the careful trade-offs and complex engineering that goes into making Chrome fast and reliable. This debugging adventure by Chrome developer and blogger Bruce Dawson reduced CPU usage by about 3% when using a webcam - a real help for those of us relying on video calls.
Video conferencing took on elevated importance in 2020. I’m not on the Google Meet team but I do work on Chrome, so I fired up my favorite profiler during one of my daily meetings to see if I could find anything useful.

There is a lot going on during video conferencing, spread across multiple processes. With my usual dozens of tabs open there were 37 Chrome processes, with six of them actively participating in the video conference. In addition there were over 200 other processes running (87 copies of svchost.exe, for instance), with four of those involved in video conferencing. You may well wonder why it takes 10 processes to connect two people, so here is a list of the processes and their roles:

audiodg.exe - Windows Audio Device Graph Isolation, audio output
dwm.exe - Windows Desktop Window Manager, showing video
svchost.exe - Windows Camera Frame Server (webcam capture)
System - Windows system process, does miscellaneous tasks on behalf of processes
chrome.exe - browser process, the master control program
chrome.exe - renderer process, the Meet tab
chrome.exe - GPU process, in charge of rendering pages
chrome.exe - NetworkService utility process, talking to the network
chrome.exe - VideoCaptureService, talking to the Windows Camera Frame Server
chrome.exe - AudioService, controls audio input and output

These tasks are spread across different processes for security and stability. If one of them crashes it can be restarted without taking everything down. If one of them is compromised due to a security bug then it is isolated from the rest of the system and the damage may be contained.

This all makes good sense, but having this many processes involved can make performance-profiling challenging. It can be challenging to look through all of these processes to find areas of potential improvement. It is made more difficult by the fact that I know little about the Meet architecture.

Analyzing a profile

Video conferencing is CPU intensive - you have to record, compress, transmit, receive, decompress, and display both audio and video. The data below shows CPU samples recorded by Microsoft’s Event Tracing for Windows (ETW). This sampling profiler works by interrupting every running thread about 1,000 times a second and recording a call stack. I used Windows Performance Analyzer (WPA) to display the results. In the screenshot below I am looking at a 10-second period and over 16,000 samples (representing about 16 seconds of CPU time) were recorded across the 10 processes involved in video conferencing:

That’s a lot of samples to look through, but the call stacks are collated so that you can drill down on the busiest stacks. I didn’t find anything in the first Chrome process, but in the second one I did:

It doesn’t look like much, but I recognized immediately that the 124 samples in KiPageFault were worth investigating. Most of the CPU-intensive work in this trace was important and unavoidable work but I had a hunch that these samples represented avoidable work - something that I could fix. And, even though they represented just 0.75% of the samples I suspected that they indicated a somewhat greater cost.

I recognized their importance immediately because this is something that I have seen before. KiPageFault means that the processor touched some memory that had been allocated, but was not currently in the process. This could mean that the pages had been removed from the process to save memory, but in an active process on a machine with lots of memory, that didn’t make sense. What was more likely was that this represented recently allocated memory.

When a program allocates a small amount of memory, the local memory manager (sometimes called the “heap”) will usually have some available that it can give to the program. But if it doesn’t have an appropriate block of memory then it will ask the operating system (OS) for some. If a program allocates a large amount of memory (greater than a MB or so) then the heap will definitely ask for more memory. This is, in itself, a relatively cheap operation. The heap asks the OS for some memory, the OS says “sure”, then the OS makes note of the fact that it promised this memory, and that’s it. The OS does not, at that time, actually give the program any memory. This is the way of the world on Windows, Linux, Android and it is good but it can be confusing and surprising. If the process never touches the memory then the memory is never added to the process, but if the process does touch the memory then individual pages of zeroed memory are brought into the process. These are called demand-zero page faults because zeroed pages are “faulted” into the process on demand.

In other words, allocating a large block of memory is quite cheap, but doesn’t actually set up the promised memory. Then, when the program tries to use the memory and the CPU discovers that there is no memory at that address it triggers an exception, which wakes up the OS. The OS checks its records and realizes that it did in fact promise to put memory at that address so it then puts some there and restarts the program. This happens so quickly that if you’re not paying attention you will miss it, but it shows up when profiling as samples hitting in KiPageFault.

This bizarre dance happens again for every 4-KiB block in the allocation - 4 KiB is the size of the pages that the CPU and the OS work on.

The cost is small. Across this 10-second period only 124 samples - representing about 124 ms or 0.124 seconds - hit inside of KiPageFault. The total cost of the enclosing CopyImage_SSE4_1 function was about 240 ms, so the page faults accounted for more than half of this function, but barely a quarter of the cost of the OnSample function on line 15.

The total costs of these page faults is modest but they hint at many other costs:

If this memory is being allocated repeatedly (presumably every frame) then it must also be freed every frame. On line 26 we can see that the Release function which frees the memory uses another 64 samples.
When the pages are freed the operating system has to zero them (for security reasons) so that they are ready to be reused. This is done in the Windows System process - an almost entirely hidden cost. Sure enough when I looked in the System process I saw 138 samples in the MiZeroPageThread. I found that 87% of the KiPageFault samples in the entire system were in the CopyImage_SSE4_1 call so presumably 87% of the 138 samples in the MiZeroPageThread were due to this pattern.

I analyzed these hidden costs of memory allocation in a 2014 blog post. The basic memory architecture of Windows hasn’t changed since then so the hidden costs remain about the same.

In addition to CPU samples my ETW trace contained call stacks for every call to VirtualAlloc. This WPA screenshot shows a 10-second period where the OnSample function does 298 allocations that are each 1.320 MB, roughly 30 per second:

At this point we can estimate that the cost of these repeated allocations is 124 (faulting in) plus 64 (freeing) plus 124 (87% of the zeroing samples) for a total of 312 samples. This gets us up to 1.9% of the total CPU cost of video conferencing. Fixing this is not going to change the world, but this is a change worth doing.

But wait, there’s more!

We are locking this buffer so that we can look at the contents, but it turns out we don’t actually want the lock call to copy the buffer at all. We just want the lock call to describe the buffer to us so that we can look at it in place. Therefore the entire cost of the MFCopyImage call is waste! That’s another 116 samples. In addition, in the CMF2DMediaBuffer::Unlock call on line 26 there is another call to CMF2DMediaBuffer::ContiguousCopyFrom. That’s because the Unlock call assumes that we might have modified the copy of the buffer, so it copies it back. So the 101 samples there are all waste as well!

If we can examine this buffer without the alloc/copy/copy/free dance then we can save 312 samples plus 116 samples (the rest of the copying cost) plus 101 samples (the copying-it-back cost) for a total saving of 3.2%. This is getting better all the time.

Note that sampled data is only statistically valid, and the actual percentages vary significantly depending on the computer and the exact workload. But, the point remains - it is a non-dramatic but worthwhile change to investigate.

Despite spending years in the video-game business my knowledge of these graphics-buffer locking and unlocking APIs is weak. I ended up relying on the wisdom of my Twitter followers to come to the conclusion that the copying was entirely avoidable, and to get a rough pattern for how it could be fixed. After filing an overly verbose bug I delegated the task of actually fixing it. The fix landed in M85 and was deemed important enough that it was then backported to M84.

You’d have to be paying very close attention to see the difference - spread across a Chrome process and the system process - but I hope that this helped some computers run a bit cooler and last longer on their batteries. And, while this inefficiency was found by profiling Google Meet, the improvement actually benefits any product that uses the webcam inside Chrome (and other Chromium-based browsers).

Verification

After the fix landed I compared two 10-second ETW traces from Chrome Canary before and after the change, each taken with no other programs running except a single Chrome tab running the Google Meet pre-meeting page. In both cases I looked at a 10-second period of time in the profiler. This showed:

CPU time in OnSample:

Before: 458 ms (432 ms of which were in Lock/Unlock/KiPageFault)
After: 27 ms

Allocations:

Before: 30 allocations per second of 1.32 MB (one per frame, running at 30 fps - a higher framerate would mean more allocations), totalling 396 MB over 10 seconds
After: 0 allocations

CPU time in the System process's MiZeroPageThread:

Before: 36 ms
After: 0 ms

These measurements showed - in three different ways - that the performance problem was fixed. The memory copying in OnSample was gone, the repeated allocations were gone, and the system process was doing less work. Mission accomplished, bug closed.

A safer default for navigation: HTTPS

Tuesday, March 23, 2021

Starting in version 90, Chrome’s address bar will use https:// by default, improving privacy and even loading speed for users visiting websites that support HTTPS. Chrome users who navigate to websites by manually typing a URL often don’t include “http://” or “https://”. For example, users often type “example.com” instead of “https://example.com” in the address bar. In this case, if it was a user’s first visit to a website, Chrome would previously choose http:// as the default protocol¹. This was a practical default in the past, when much of the web did not support HTTPS.Chrome will now default to HTTPS for most typed navigations that don’t specify a protocol². HTTPS is the more secure and most widely used scheme in Chrome on all major platforms. In addition to being a clear security and privacy improvement, this change improves the initial loading speed of sites that support HTTPS, since Chrome will connect directly to the HTTPS endpoint without needing to be redirected from http:// to https://. For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails (including when there are certificate errors, such as name mismatch or untrusted self-signed certificate, or connection errors, such as DNS resolution failure). This change is rolling out initially on Chrome Desktop and Chrome for Android in version 90, with a release for Chrome on iOS following soon after.

HTTPS protects users by encrypting traffic sent over the network, so that sensitive information users enter on websites cannot be intercepted or modified by attackers or eavesdroppers. Chrome is invested in ensuring that HTTPS is the default protocol for the web, and this change is one more step towards ensuring Chrome always uses secure connections by default. ¹ One notable exception to this is any site in the HSTS preload list, which Chrome will always default to HTTPS.
² IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP. Posted by Shweta Panditrao and Mustafa Emre Acer, Chrome team

Mitigating Side-Channel Attacks

Friday, March 12, 2021

The web platform relies on the origin as a fundamental security boundary, and browsers do a pretty good job at preventing explicit leakage of data from one origin to another. Attacks like Spectre, however, show that we still have work to do to mitigate implicit data leakage. The side-channels exploited through these attacks prove that attackers can read any data which enters a process hosting that attackers' code. These attacks are quite practical today, and pose a real risk to users.Our goal must be to ensure that sensitive data doesn't unexpectedly enter an attacker's process. Browsers shoulder a large chunk of this responsibility: Chromium's Site Isolation can separate the sites you visit into distinct OS-level processes, cross-origin read blocking prevents attackers from loading a subset of otherwise-vulnerable cross-origin resources, and APIs that substantially increase attackers' bandwidth (like SharedArrayBuffer) are being locked to cross-origin isolated contexts. This last mechanism, however, points in the direction of work that browsers can't do on their own.Web developers know their applications intimately, and can make informed decisions about each page's and resource's risk of exposure. To defend users' data against exfiltration, web developers must step in, evaluate resources they host, and instruct browsers to isolate those resources accordingly. At a high-level, this defense consists of:

Deciding when to respond to requests by examining incoming headers, paying special attention to the Origin header on the one hand, and various Sec-Fetch- prefixed headers on the other.

Restricting attackers' ability to load resources as a subresource by setting a cross-origin resource policy of same-origin (opening up to same-site or cross-origin only when necessary).

Restricting attackers' ability to frame resources as a document by opting into framing protections via X-Frame-Options: SAMEORIGIN or CSP’s more granular frame-ancestors directive: for example, frame-ancestors 'self' https://trusted.embedder.

Restricting attackers' ability to reference your application's windows by setting a cross-origin opener policy. In the best case, you can default to a restrictive same-origin value, opening up to same-origin-allow-popups or unsafe-none only if necessary.

Preventing MIME-type confusion attacks and increasing the robustness of passive defenses like cross-origin read blocking by setting correct Content-Type headers, and globally asserting X-Content-Type-Options: nosniff.

Together, these various defenses help all browsers offer some degree of process-level protection for users' data, whether or not Site Isolation is available.To find out more about employing these defenses, check out Post-Spectre Web Development. It includes practical examples that explain in more detail how the security primitives discussed above apply to resources you might have on your sites.These are useful steps you can take today to protect your origin against implicit data leaks. Looking forward, we hope to help the web shift to safer defaults which protect users against these attacks without requiring developer action.Posted by Mike West, on behalf of Chrome's web platform security team

Chrome 90 Beta: AV1 Encoder for WebRTC, New Origin Trials, and More

Thursday, March 11, 2021

Better compression efficiency than other types of video encoding, reducing bandwidth consumption and improve visual quality

Enabling video for users on very low bandwidth networks (offering video at 30kbps and lower)

Significant screen sharing efficiency improvements over VP9 and other codecs.

This is an important addition to WebRTC especially since it recently became an official W3C and IETF standard.Origin TrialsThis version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Chrome Origin Trials dashboard. To learn more about origin trials in Chrome, visit the Origin Trials Guide for Web Developers. Microsoft Edge runs its own origin trials separate from Chrome. To learn more, see the Microsoft Edge Origin Trials Developer Console. New Origin TrialsgetCurrentBrowsingContextMedia()The mediaDevices.getCurrentBrowsingContextMedia() method allows capturing a MediaStream with the current tab's video (and potentially audio), similar to getDisplayMedia(). Unlike getDisplayMedia(), calling this new method will eventually present the user with a simple accept/reject dialog box. If the user accepts, the current tab is captured. However, this will require some additional security measures which are still being finalized. Until then, or if the call is made with these measures absent, a dialog is displayed to the user that allows the selection of any source, but highlights the option of the current tab (whereas normally getDisplayMedia highlights the option of entire-screen).MediaStreamTrack Insertable Streams (a.k.a. Breakout Box)An API for manipulating raw media carried by MediaStreamTracks such as the output of a camera, microphone, screen capture, or the decoder part of a codec and the input to the decoder part of a codec. It uses WebCodecs interfaces to represent raw media frames and exposes them using streams, similar to the way the WebRTC Insertable Streams API exposes encoded data from RTCPeerConnections. This is intended to support use cases such as:

Funny Hats: Refers to manipulation of media either before encoding and after decoding to provide effects such as background removal, funny hats, voice effects.

Machine Learning: Refers to applications such as real-time object identification/annotation.

This origin trial is expected to run through Chrome 92.Subresource Loading with Web BundlesSubresource loading with Web Bundles provides a new approach to loading a large number of resources efficiently using a format that allows multiple resources to be bundled., e.g. Web Bundles.The output of JavaScript bundlers (e.g. webpack) doesn't interact well with browsers. They are good tools but:

Their output can't interact with the HTTP cache at any finer grain than the bundle itself (not solved with this origin trial). This can make them incompatible with new requirements like dynamic bundling (e.g. small edit with tree shaking could invalidate everything).

They force compilation and execution to wait until all bytes have arrived. Ideally loading multiple subresources should be able to utilize full streaming and parallelization, but that's not possible if all resources are bundled as one javascript. (This origin trial allows compilation to proceed in parallel. For JavaScript modules, execution still needs to wait for the entire tree due to the current deterministic execution model).

They can require non-JS resources like stylesheets and images to be encoded as JS strings, which forces them to be parsed twice and can increase their size. This origin trial allows those resources to be loaded in their original form.

This origin trial also allows a bundle to include the source for an opaque-origin iframe as urn:uuid: resources. The scheme for these resources is expected to change in Chrome 91.This origin trial is expected to run through Chrome 92.WebAssembly Exception HandlingWebAssembly now provides exception handling support. Exception handling allows code to break control flow when an exception is thrown. The exception can be any that is known by the WebAssembly module, or it may be an unknown exception that was thrown by a called imported function. This origin trial is expected to run through Chrome 94.Completed Origin TrialsThe following features, previously in a Chrome origin trial, are now enabled by default.WebXR AR Lighting EstimationLighting estimation allows sites to query for estimates of the environmental lighting conditions within WebXR sessions. This exposes both spherical harmonics representing the ambient lighting, as well as a cubemap texture representing "reflections". Adding Lighting Estimation can make your models feel more natural and like they "fit" better with the user's environment.Other Features in this ReleaseCSSaspect-ratio InterpolationThe aspect-ratio property allows for automatically computing the other dimension if only one of width or height is specified on any element. This property was originally launched as non-interpolable (meaning that it would snap to the target value) when animated. This feature provides smooth interpolation from one aspect ratio to another.Custom State Pseudo ClassesCustom elements now expose their states via the state CSS pseudo class. Built-in elements have states that can change over time depending on user interaction and other factors, which are exposed to web authors through pseudo classes. For example, some form controls have the "invalid" state, which is exposed through the :invalid pseudo class. Since custom elements also have states it makes sense to expose their states in a manner similar to built-in elements.Implement 'auto' value for appearance and -webkit-appearanceThe default values of CSS property appearance and -webkit-appearance for the following form controls are changed to 'auto'.

<input type=color> and <select>

Android only: <input type=date>, <input type=datetime-local>, <input type=month>, <input type=time>, and <input type=week>

Note that the default rendering of these controls are not changed.overflow: clip PropertyThe clip value for overflow results in a box's content being clipped to the box's overflow clip edge. In addition, no scrolling interface is provided, and the content cannot be scrolled by the user or programmatically. Additionally the box is not considered a scroll container, and does not start a new formatting context. As a result, this value has better performance than overflow: hidden.overflow-clip-margin PropertyThe overflow-clip-margin property enables specifying how far outside the bounds an element is allowed to paint before being clipped. It also allows the developer to expand the clip border. This is particularly useful for cases where there is ink overflow that should be visible.Permissions-Policy HeaderThe Permissions-Policy HTTP header replaces the existing Feature-Policy header for controlling delegation of permissions and powerful features. The header allows sites to more tightly restrict which origins can be granted access to features.The Feature Policy API, introduced in Chrome 74, was recently renamed to "Permissions Policy", and the HTTP header has been renamed along with it. At the same time, the community has settled on a new syntax, based on structured field values for HTTP.Protect application/x-protobuffer via Cross-Origin-Read-Blocking Protect application/x-protobuffer from speculative execution attacks by adding it to the list of never sniffed MIME types used by Cross-Origin-Read-Blocking. application/x-protobuf is already protected as a never sniffed mime type. application/x-protobuffer is another commonly used MIME type that is defined as an "ALT_CONTENT_TYPE" by the protobuf library. Seeking Past the End of a File in the File System Access APIWhen data is passed to FileSystemWritableFileStream.write() that would extend past the end of the file, the file is now extended by writing 0x00 (NUL). This enables creating sparse files and greatly simplifies saving content to a file when the data to be written is received out of order.
Without this functionality, applications that receive file contents out of order (for example, BiTtorrent downloads) would have to manually resize the file either ahead of time or when needed during writing.StaticRange ConstructorCurrently, Range is the only constructible range type available to web authors. However, Range objects are "live" and maintaining them can be expensive. For every tree change, all affected Range objects need to be updated. The new StaticRange objects are not live and represent a lightweight range type that is not subject to the same maintenance cost as Range. Making StaticRange constructible allows web authors to use them for ranges that do not need to be updated on every DOM tree change.Support Specifying Width and Height on <source> Elements for <picture>The <source> element now supports width and height properties when used inside a <picture> element. This allows Chrome to compute an aspect ratio for <picture> elements. This matches similar behavior for <img>, <canvas> and <video> elements.WebAudio: OscillatorOptions.periodicWave is Not NullableIt is no longer possible to set periodicWave to null when creating a new OscillatorNode object. This value is set on the options object passed to the OscillatorNode() constructor. The WebAudio spec doesn't allow setting this value to null. Chrome now matches both the spec and Firefox. JavaScriptThis version of Chrome incorporates version 9.0 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent features in the V8 release notes.Relative Indexing Method for Array, String, and TypedArraysArray, String, and TypedArray now support the at() method, which supports relative indexing with negative numbers. For example, the code below returns the last item in the given array.let arr = [1,2,3,4]; arr.at(-1); Deprecations, and RemovalsThis version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.Remove Content Security Policy Directive 'plugin-types'The 'plugin-types' directive allows developers to restrict which types of plugin can be loaded via <embed> or <object> html elements. This allowed developers to block Flash in their pages. Since Flash support has been discontinued, there is no longer any need for this policy directive.Remove WebRTC RTP Data ChannelsChrome has removed support for the non-standard RTP data channels in WebRTC. Users should use the standard SCTP-based data channels instead.Return Empty for navigator.plugins and navigator.mimeTypesChrome now returns empty for navigator.plugins and navigator.mimeTypes. With the removal of Flash, there is no longer the need to return anything for these properties.

Advanced memory management and more performance improvements in M89

Thursday, March 11, 2021

Boosting performance while adding features, functionality, and improving security, requires deep and continuous investment. Today’s post is the first in a series this year that will go into more technical detail about Chrome's ongoing efforts around performance. In this release, we’ve dug deep into the core of Chrome, upgrading how we allocate and discard memory, and even how we build, package, and run Chrome, to make today’s Chrome even faster and more memory efficient.

Improving memory managementIn Chrome M89, we’re seeing significant memory savings on Windows--up to 22% in the browser process, 8% in the renderer, and 3% in the GPU. Even more than that, we’ve improved browser responsiveness by up to 9%. We’ve achieved this by using PartitionAlloc, our own advanced memory allocator, which is optimized for low allocation latency, space efficiency, and security. For some time now, PartitionAlloc has been used extensively within Blink, our renderer codebase. Starting in M89, we’ve upgraded Chrome on Android and 64-bit Windows to use PartitionAlloc everywhere (by intercepting malloc).
In addition to improving how we allocate memory, Chrome is now smarter about using (and discarding) memory. Chrome now reclaims up to 100MiB per tab, which is more than 20% on some popular sites, by discarding memory that the foreground tab is not actively using, such as big images you’ve scrolled off screen. Chrome is also shrinking its memory footprint in background tabs on macOS, something we’ve been doing on other platforms for a while. We’re seeing up to 8% memory savings, which is more than 1GiB in some cases!
Finally, with more data from the field on tab throttling, we’re seeing up to 65% improvement on Apple Energy Impact score for tabs in the background, keeping your Mac cooler and those fans quiet.

Build, packaging, and runtime improvementsFocusing on Chrome for Android, we have a uniquely challenging job of building a great browser for every single variant of Android device. In this release we’re taking advantage of some packaging and runtime optimizations to deliver better performance in the Chrome that is in your pocket.
Some new Play and Android capabilities allowed us to repackage Chrome on Android, and we’re seeing fewer crashes due to resource exhaustion, a 5% improvement in memory usage, 7.5% faster startup times, and up to 2% faster page loads. Android App Bundles allow the Play Store to generate optimized APKs for each user’s device configuration, and allows packaging code and resources in split APKs, which are installed alongside the base APK. And an Android O feature, isolatedSplits, allows these feature splits to be loaded on demand, reducing Chrome’s overall startup cost.
For those of you who picked up the latest Android devices (Android Q+ and 8GB+ of RAM), we’ve rebuilt Chrome as a 64-bit binary, giving you a more stable Chrome that is up to 8.5% faster to load pages and 28% smoother when it comes to scrolling and input latency.
Finally, we’ve built a way for Chrome on Android to start up 13% faster: Freeze-Dried Tabs. Chrome now saves a lightweight version of your tabs that are similar in size to a screenshot, but support scrolling, zooming, and tapping on links. We use these Freeze-Dried Tabs at startup while the actual tab loads in the background, getting you to your pages faster. See it in action below:

Our teams are always working hard to bring you the fastest and most powerful browser on every one of your devices. We’re very excited to bring you these performance improvements and have much more to come, so stay tuned.
Posted by Mark Chang, Chrome Product Manager
Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.

Speeding up Chrome's release cycle

Thursday, March 4, 2021

For more than a decade, Chrome has shipped a new milestone every 6 weeks, delivering security, stability, speed and simplicity to our users and the web. As we have improved our testing and release processes for Chrome, and deployed bi-weekly security updates to improve our patch gap, it became clear that we could shorten our release cycle and deliver new features more quickly. Because of this, we are excited to announce that Chrome is planning to move to releasing a new milestone every 4 weeks, starting with Chrome 94 in Q3 of 2021.

Additionally, we will add a new Extended Stable option, with milestone updates every 8 weeks. Extended Stable will be available to enterprise administrators and Chromium embedders who need additional time to manage updates. Security updates on Extended Stable will be released every two weeks to fix important issues, but those updates won’t contain new features or all security fixes that the 4 week option will receive.

For users on Chrome OS, we also plan to support multiple stable release options. We’ll have more to share with Chrome OS administrators in the coming months about the choices you’ll have for milestone updates to your managed devices.

We have updated the documentation for our new release schedule, and we welcome feedback from Chromium contributors at branches@chromium.org. We’ve also published a preliminary update to our release calendar that we’ll keep up to date as we get closer to launching our new release schedule.

We’re excited to continue evolving Chrome, and providing the best in security, stability, speed and simplicity to our users, even more rapidly in the future!

Alex Mineer, Technical Program Manager, Chrome Operations

Heads Up: Restriction on SharedArrayBuffers are coming in M91

Wednesday, February 17, 2021

Starting in Chrome 91 (May, 2021), cross-origin isolation will be required on all platforms in order to access APIs like SharedArrayBuffer and performance.measureUserAgentSpecificMemory(). This brings our desktop platforms in line with Android, which shipped this restriction in Chrome 88.In order to continue using these APIs, ensure that your pages are cross-origin isolated by serving the page with the following headers:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Be aware, once you do this, your page will not be able to load cross-origin content unless the resource explicitly allows it via a Cross-Origin-Resource-Policy header or CORS headers (Access-Control-Allow-* and so forth).For more detailed adoption instructions and considerations, take a look at the web.dev guide to enable cross-origin isolation.Posted by Lutz Vahl, Technical Program Manager

Chrome 89 Beta: Advanced Hardware Interactions, Web Sharing on Desktop, and More

Thursday, January 28, 2021

Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 89 is beta as of January 28, 2021.WebHID APIThere is a long tail of human interface devices (HIDs) that are too new, too old, or too uncommon to be accessible by systems' device drivers. The WebHID API solves this by providing a way to implement device-specific logic in JavaScript. A human interface device is one that takes input from or provides output to humans. Examples of devices include keyboards, pointing devices (mice, touchscreens, etc.), and gamepads.The inability to access uncommon or unusual HID devices is particularly painful, for example, when it comes to gamepad support. Gamepad inputs and outputs are not well standardized and web browsers often require custom logic for specific devices. This is unsustainable and results in poor support for the long tail of older and uncommon devices.With its origin trial over, WebHID is enabled by default in Chrome 89 on desktop. To learn how to use it, check out Connecting to uncommon HID devices, and see demos in Human interface devices on the web: a few quick examples.Web NFCNFC stands for Near Field Communications, a short-range wireless technology for transmitting small amounts of data, usually between a specialized NFC device and a reader. If you've scanned a badge to enter a building, you may have used NFC. Web NFC allows a web app to read from and write to NFC tags. This opens new use cases to the web, including providing information about museum exhibits, inventory management, providing information in a conference badge, and many others. In Chrome 89 on Android, Web NFC is enabled by default.

Web NFC cards demo at Chrome Dev SummitWith NFC reading and writing are simple operations. You'll need a little instruction for constructing and interpreting payloads, but it's not complicated. Fortunately, we have an article, Interact with NFC devices on the web. Check it out. We have some samples you can play with. Here's a taste:Writing a string to an NFC tag:

if ("NDEFReader" in window) {
  const ndef = new NDEFReader();
  await ndef.write("Hello world!");
}

Scanning messages from NFC tags:

if ("NDEFReader" in window) {
  const ndef = new NDEFReader();
  await ndef.scan();
  ndef.onreading = ({ message }) => {
    console.log(`Records read from a NFC tag: ${message.records.length}`);
  };
}

Web Serial APIA serial port is a bidirectional communication interface that allows sending and receiving data byte by byte. The Web Serial API brings this capability to websites, letting them control devices such as microcontrollers and 3D printers.In educational, hobbyist, and industrial settings, peripheral devices are already controlled through web pages. In all such cases device control requires installation of adapters and drivers. The Web Serial API improves the user experience by enabling direct communication between a website and a peripheral. Its origin trial is over and the Web Serial API is now enabled on desktop. A demo is available on GitHub. For information about using it, see Read to and write from a serial port. Web Sharing on DesktopTo allow users to easily share content on social networks, developers have manually integrated 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 third-party code. On the receiving end, only platform apps could register to be share targets and receive shares from other apps. Chrome for Android started adding these features between Chrome 61 and 75. In Chrome 89, web sharing is available on Windows and ChromeOS, while registering as a share target is supported on ChromeOS. On these platforms, sites can now use navigator.share() on desktop to trigger a share dialog box. And an entry to the web app manifest allows a PWA to act as a share target. For information on web sharing, see Integrate with the OS sharing UI with the Web Share API. To learn to configure a PWA as a share target, see Receiving shared data with the Web Share Target API.Origin TrialsThere are no new origin trials in this version of Chrome. To register for current origin trials, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.Other features in this releaseAVIF Image DecodeChrome now supports decoding AVIF content natively using existing AV1 decoders on Android and WebView. (Desktop support was added in Chrome 85.) AVIF is a next generation image format standardized by the Alliance for Open Media. There are three primary motivations for supporting AVIF:

Reducing bandwidth consumption to load pages faster and reduce overall data consumption. AVIF offers significant file size reduction for images compared with JPEG or WebP.

Adding HDR color support. AVIF is a path to HDR image support for the web. JPEG is limited in practice to 8-bit color depth. With displays increasingly capable of higher brightness, color bit depth, and color gamuts, web stakeholders are increasingly interested in preserving image data that is lost with JPEG.

Supporting ecosystem interest. Companies with a large web presence have expressed an interest in shipping AVIF images on the web.

Cross-origin opener policy reporting APIA new reporting API helps developers deploy cross-origin opener policy. In addition to reporting breakages when COOP is enforced, the API provides a report-only mode for COOP. The report-only mode for COOP will not enforce COOP, but it will report potential breakages that would have happened had we enforced COOP. Developers can inspect the reporting API with Chrome DevTools.Display override in web app manifestsThe new display_override field for the web app manifest allows developers to specify an explicit fallback chain for the display field. The following example specifies a "minimal-ui", falling back to "standalone".

{
  "display": "standalone",
  "display_override": ["minimal-ui"],
}

This API is intended for advanced use cases and display modes, and its capabilities are limited. You can learn more in its Chrome Status entry.Expose ReadableStreamDefaultController interfaceChrome now exposes the ReadableStreamDefaultController interface on the global object, as with the other ReadableStream-related classes. This eliminates a previous limitation where instances had to be created inside stream constructors.performance.measureUserAgentSpecificMemory() The feature adds a performance.measureUserAgentSpecificMemory() function which estimates the memory usage of the web page. The method is gated behind COOP/COEP thus the web site needs to be cross-origin isolated to use it.Potentially trustworthy data: urls To conform to current web standards, Chrome now treats all data: urls as potentially trustworthy.
For background, It's often necessary to evaluate whether a URL is secure in order to only enable certain features when minimum standards of authentication and confidentiality are met. For that purpose, web standards rely on the definition of "potentially trustworthy URL", which includes URLs with the "data" scheme in the latest version of the Secure Contexts specification. Blink previously only treated some data: URLs as potential trustworthy. Streams API: Byte StreamsThe streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. For streams representing bytes, Chrome now supports an extended version of the readable stream to handle bytes efficiently, specifically by minimizing copies.
Byte streams allow for Bring Your Own Buffer (BYOB) readers to be acquired. The default implementation can give a range of different outputs such as strings or array buffers in the case of web sockets, whereas byte streams guarantee byte output. Furthermore, being able to have BYOB readers has stability benefits. This is because if a buffer detaches, there's now a guarantee that the same buffer won't be written to twice, hence avoiding race conditions. BYOB readers also do not need to garbage collect for every read, because buffers are reused.Support for full 'filter' property syntax on SVG elementsChrome now allows the full syntax of the 'filter' property to be used on SVG elements which previously only supported single url() references. This lets filter functions such as blur(), sepia() and grayscale() apply to both SVG elements and non-SVG elements. It makes the platform support for 'filter' more uniform and allows for easier application of some "canned" effects. Without this feature developers need to use a full SVG <filter> element definition even for basic filters such as grayscale() or blur().WebAuthentication API: ResidentKeyRequirement and credProps extensionChrome now supports two new features related to the Web Authentication API. The AuthenticatorSelectionCriteria.residentKey property specifies for web authentication credential registration whether a client-side discoverable credential should be created. The Web Authentication credProps extension indicates to the relying party whether a created credential is client-side discoverable. "Client-side discoverable credentials" are a type of WebAuthn credential that can be challenged by a relying party without needing to provide the credential ID in the WebAuthn API request. Browsers display a list of all discoverable credentials from a given authenticator (either external security key or built-in) and let the user choose one to sign in with.CSS::target-text pseudo-elementAdds a highlight pseudo element to allow authors to style scroll-to-text fragments differently from the default user agent highlighting.flow-relative Corner Rounding propertiesFlow-relative corner rounding properties now allow control of corners using logical mappings rather than physical properties. Additionally, this allows authors to set different corner border radii depending on the direction and writing mode of the page.This brings Chrome in line with the CSS Logical Properties and Values spec. The following logical properties have been added:

border-start-start-radius

border-start-end-radius

border-end-start-radius

border-end-end-radius

Forced colors propertyThe forced-colors media feature detects whether the user agent is enforcing a user-chosen limited color palette on the page.Forced colors adjust propertyThe forced-color-adjust property allows authors to opt particular elements out of forced colors mode, restoring full control over the colors to CSS.JavaScriptThis version of Chrome incorporates version 8.9 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent features in the V8 release notes.Top-level awaitChrome now allows the await keyword at the top level within JavaScript modules. This allows more seamless integration of asynchronous calls into the module loading process. Today this is accomplished by wrapping modules in async functions, but this pushes complexity into dependent modules and exposes implementation details.Developer NotesImage Orientation with EXIFEXIF information is now always used to orient cross-origin images. That is, setting image-orientation: none in CSS has no effect on non-secure-origin images. The spec discussion behind the change is available in a CSS working group draft.Deprecations and RemovalsThis version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.Remove prefixed events for <link rel=prerender>The legacy prefixed events (webkitprerenderstart, webkitprerenderstop, webkitprerenderload, and webkitprerenderdomcontentloaded) dispatched on <link rel=prerender> are now removed from Chrome.Stop cloning sessionStorage for windows opened with noopenerWhen a window is opened with noopener, Chrome will no longer clone the sessionStorage of its opener; it will instead start an empty sessionStorage namespace. This brings Chrome in conformance with the HTML specification.

Privacy Sandbox in 2021: Testing a more private web

Monday, January 25, 2021

A year ago we announced our intention to phase out third-party cookies and replace them with new browser features that are fundamentally more private. Since then, we've been working closely with the broader web community, including W3C, to design and implement new privacy-preserving technology, while also preserving the vitality and sustainability of the open web.

Today more than 30 different proposals have been offered by Chrome and others, including many that we believe are key to rendering third-party cookies obsolete. Early test results are also looking promising (see below)!

We are excited to continue testing this foundational tech with the active involvement of ecosystem partners and industry forums – all to move the web forward, together. What follows are key updates since our announcements last January and October.

Early results, and new proposals ready for testing
Five different Privacy Sandbox proposals are available for testing now – or will be very soon – in key areas like fraud detection, the tailoring of content, first-party treatment of a company’s owned and related domains, ads measurement, and a private-by-default way to request browser info. In fact, early testing of the Federated Learning of Cohorts (FloC) algorithm shows that new privacy-preserving ad solutions can be similarly effective to cookie-based approaches. This is great news for users, publishers, and advertisers – all of whom are critical for the future of the web – so we’re excited to carry this work forward.

Another important area of focus is user-facing controls. In particular, it’s clear that people will want to tune whether content is tailored to them (or not) – in addition to keeping their private info private. With the Chrome 90 release in April, we’ll be releasing the first controls for the Privacy Sandbox (first, a simple on/off), and we plan to expand on these controls in future Chrome releases, as more proposals reach the origin trial stage, and we receive more feedback from end users and industry. You can find a full update on all trials on our blog.

Involvement across the ecosystem
It’s great to see companies like Salesforce, White Ops, and Yahoo! JAPAN, starting (or preparing) to test initial solutions like Trust Tokens, First Party Sets, and Conversion Measurement. In fact, all developers have access to public Chrome experiments, and the latest guidance can be found on web.dev, so please do test and share feedback. This type of engagement helps ensure that the various APIs work as expected in real-world scenarios, so the more ecosystem participation, the better!

Building better. Together.
One of the things that makes the web so great is that it’s by and for all of us; this is a special quality amongst today’s platforms, and is definitely worth celebrating! It also creates complexity and trade-offs that we have to manage thoughtfully – and collectively – as we introduce new technology. That’s why we continue to engage in industry forums like the W3C, and are in active discussions with independent authorities – including privacy regulators and the UK’s Competition and Markets Authority – to help identify and shape the best approach for online privacy, and the industry and world as a whole.

So here’s to the users, and coders, and advertisers, and content creators (and so many others) who’ve made, and continue to make the platform what it is today. And here’s to coming together, in service of a more private web.

Posted by Justin Schuh - Director, Chrome Engineering

Better content sharing with Custom Tabs

Friday, January 22, 2021

Custom TabsAction Button

A default Action Button that shares the URL is added to the top bar when the application doesn’t provide one.

What do I need to do to enable the new default share action button in?

Nothing! The default Action Button will be automatically added to the application, as long as the application doesn’t set its own. Since this change will happen in the browser, it will be automatically applied to all apps using Custom Tabs.
Please note: this is a change in Chrome’s behavior and we hope other browsers will add similar functionality.

How can I opt-out from the share icon showing in my App?

Starting with androidx.browser version 1.3.0, developers can use the setShareState() method from the CustomTabsIntent.Builder to disable the default share:

val customTabsIntent = CustomTabsIntent.Builder()

.setShareState(CustomTabsIntent.SHARE_STATE_OFF)

.build();

As part of this change, the addDefaultShareMenuItem() and setDefaultShareMenuItemEnabled() methods from CustomTabsIntent.Builder have been deprecated and developers should use setShareState() instead.

If your application uses Custom Tabs, we’d like to hear your feedback, and you can reach out to us using this form.

Posted by André Bandarra, Developer Relations Engineer and Chirag Desai, Product Manager

Limiting Private API availability in Chromium

Friday, January 15, 2021

During a recent audit, we discovered that some third-party Chromium based browsers were able to integrate Google features, such as Chrome sync and Click to Call, that are only intended for Google’s use. This meant that a small fraction of users could sign into their Google Account and store their personal Chrome sync data, such as bookmarks, not just with Google Chrome, but also with some third-party Chromium based browsers. We are limiting access to our private Chrome APIs starting on March 15, 2021.

For users who accessed Google features (like Chrome sync) through a third-party Chromium based browser, their data will continue to be available in their Google Account, and data that they have stored locally will continue to be available locally. As always, users can view and manage their data on the My Google Activity page. They can also download their data from the Google Takeout page, and/or delete it here.

Guidance for vendors of third-party Chromium based products is available on the Chromium wiki.

Posted by Jochen Eisinger, Engineering Director, Google Chrome

Chromium Blog