Chrome 107 Beta
Thursday, September 29, 2022
Announcing the Launch of the Chrome Root Program
Monday, September 19, 2022
In 2020, we announced we were in the early phases of establishing the Chrome Root Program and launching the Chrome Root Store.
The Chrome Root Program ultimately determines which website certificates are trusted by default in Chrome, and enables more consistent and reliable website certificate validation across platforms.
This post shares an update on our progress and how these changes help us better protect Chrome’s users.
Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes on behalf of its users are secure and private. Certificates are responsible for binding a domain name to a public key, which Chrome uses to encrypt data sent to and from the corresponding website.
As part of establishing a secure connection to a website, Chrome verifies that a recognized entity known as a “Certification Authority” (CA) issued its certificate. Certificates issued by a CA not recognized by Chrome or a user’s local settings can cause users to see warnings and error pages.
Root stores, sometimes called “trust stores”, tell operating systems and applications what certification authorities to trust. The Chrome Root Store contains the set of root CA certificates Chrome trusts by default.
A root program is a governance structure that establishes the requirements and security review functions needed to manage the corresponding root store. Members of the Chrome Security Team are responsible for the Chrome Root Program. Our program policy, which establishes the minimum requirements for CAs to be included in the Chrome Root Store, is publicly available here.
Historically, Chrome integrated with the root store and certificate verification process provided by the platform on which it was running. Standardizing the set of CAs trusted by Chrome across platforms through the transition to the Chrome Root Store, coupled with a consistent certificate verification experience through the use of the Chrome Certificate Verifier, will result in more consistent user and developer experiences.
Launching the Chrome Root Program also represents our ongoing commitment to participating in and improving the Web PKI ecosystem. Innovations like ACME have made it easier than ever for website owners to obtain HTTPS certificates. Technologies like Certificate Transparency promote increased accountability and transparency, further improving security for Chrome’s users. These enhancements, only made possible through community collaboration, make the web a safer place. However, there’s still more work to be done.
We want to work alongside CA owners to define and operationalize the next generation of the Web PKI. Our vision for the future includes modern, reliable, highly agile, purpose-driven PKIs that promote automation, simplicity, and security - and we formed the Chrome Root Program and corresponding policy to achieve these goals.
A “rollout” is a gradual launch of a new feature. Sometimes, to ensure it goes smoothly, we don’t enable a new feature for all of our users at once. Instead, we start with a small percentage of users and increase that percentage over time to ensure we minimize unanticipated compatibility issues. The Chrome Root Store and Certificate Verifier began rolling out on Windows and macOS in Chrome 105, with other platforms to follow.
We expect the transition to the Chrome Root Store and Certificate Verifier to be seamless for most users, enterprises, and CA owners.
The Chrome Certificate Verifier considers locally-managed certificates during the certificate verification process. This means if an enterprise distributes a root CA certificate as trusted to its users (for example, by a Windows Group Policy Object), it will be considered trusted in Chrome.
Troubleshooting procedures and other frequently asked questions are available here.
While we don’t know exactly what the future of the Web PKI will look like, we remain focused on promoting changes that increase speed, security, stability, and simplicity throughout the ecosystem.
With that in mind, the Chrome team continues to explore introducing future root program policy requirements related to the following initiatives:
Encouraging modern infrastructures and agility
Focusing on simplicity
Promoting automation
Reducing mis-issuance
Increasing accountability and ecosystem integrity
Streamlining and improving domain validation practices
Preparing for a “post-quantum” world
We look forward to continuing our collaboration with members of the CA/Browser Forum and other Web PKI ecosystem participants to make the Internet a safer place.
Posted by Ryan Dickson, Chris Clements, Emily Stark from Chrome Security
Speeding up Chrome on Android Startup with Freeze Dried Tabs
Thursday, September 15, 2022
We believe that "good enough" is never enough when it comes to pushing the performance of Chrome. Today’s The Fast and the Curious post explores how we sped up the startup times of Chrome on Android by more than 20% by providing an interactive freeze-dried preview of a tab on startup. Read on to see how the screenshot falls short, and freeze-drying your tabs makes for a better browser.
Rendering web content can be computationally intensive and can feel slow at times compared to a native application. A lot of work needs to be done to dynamically load resources over the network, run JavaScript, render CSS, fonts, etc. On mobile devices this is particularly challenging and Chrome can often only keep a handful of web pages loaded at a time due to the memory constraints of the device.
This leads to the question of whether there is a lighter-weight way to represent web content when the situation calls for it—for example, in transitional UI like the tab switcher or during startup when a lot of warm-up work is occurring. The de-facto option for this is a screenshot which is visually accurate and allows a user to see at a glance what they are opening. However, a screenshot is also more limited than a web page as it is constrained to whatever was last visible and is entirely static.
What if we could make these transitional glimpses of web content more useful, interactable and engaging while waiting for the real page to be ready?
Chrome App cold startup on Android is expensive. To start drawing a web page at the median takes 3.4s from launch (First Contentful Paint /FCP). This can feel slow compared to other apps and is due to all the work needed to process a page’s HTML, CSS, JS and Fonts.
What if, instead, we showed an interactive snapshot of the page at startup?
We call this snapshot a Freeze Dried Tab as it removes a number of features from a live web page, but provides enough content and interactivity to be more helpful than a static screenshot. The key elements we felt that a screenshot lacked were the ability to navigate through links and scroll through a page’s content beyond what is shown in the viewport (including iframes).
A Freeze Dried Tab provides all these capabilities and more. It is faster to start than a live web page and provides enough capabilities to get started with the content until the full page is ready. Once the page is loaded, we then transition to it automatically and seamlessly!
Testing has shown that by using a Freeze Dried Tab we can speed up the median time taken to draw all the content of the page to just 2.8s from launch (~20% faster compared to starting to draw normally). Since all the content is there and there’s often no layout shift, it feels even faster!
The distribution shift in startup time caused by Freeze Dried Tabs.
Data source for all statistics: Real-world data anonymously aggregated from Chrome clients [1]
To Freeze Dry a web page we capture the visual state of the page as a set of vector graphics along with any hyperlinks. We can then “reconstitute” (play back) these vector graphics in a lighter-weight fashion by simply rastering the vector graphics. This reduces the rendering cost of showing a full web page (including the content outside the viewport) and still supports hyperlinks.
This format provides a number of benefits over a screenshot, but is still not as fully featured as a web page. This is why we believe they are an ideal candidate for transitional views where loading the live page might take some time, but we want to have a more interactive view than a screenshot.
*Values are estimates from an emulated Pixel 2 XL running Android P.
1Utility process is 30 MB overhead with on average ~10 MB of content and 20 MB of bitmaps
Building this technology was an interesting and challenging experience. In particular, aggregating content from iframes, supporting subframe scrolling, and handling all the geometry is a complicated process.
However, the most interesting challenges came from performance!
During capture of the page, saving the content is mostly straightforward; geometry from the DOM with CSS styling is easily converted into vector graphics which are small and easy to store.
Storing images from the page in this format is also straightforward, although high-resolution images are both large (0.1-10 MB) and slow to compress O(100 ms) + MBs of memory overhead. For this reason, images are usually stored without modification in their default encoding; however, sometimes particularly large images might get dropped.
Fonts are files describing how to draw each glyph they contain. These files are particularly large for fonts from languages with a large number of characters such as Chinese or which are composed of images such as emoji. A single English-language font is often around 100 kB in size, and fonts for emoji can easily be several MB. Pages often embed multiple fonts and these fonts are not saved on the local system, so we need to save them as part of the captured data. In early testing, we tried to store every font used in the page to ensure visual fidelity. However, some pages were as large as 100 MB when stored in this manner. This was simply unacceptable from a performance and storage point of view.
To overcome this challenge we turned to font subsetting. Subsetting strips every unused glyph from a font file. This reduces the data in a font to only what is required by the page. As such, that 100 MB page was reduced to just 400 kB, < 1% of the original size!
Keeping playback performance within a reasonable bound was also a challenge. The vector graphics are rasterized into a bitmap for display; however, at 32-bits per pixel, on a modern phone screen just a single viewport of content is easily larger than 10 MB. To mitigate the memory overhead of these bitmaps, we generate them dynamically as a user scrolls.
More details: the page’s contents are divided into tiles which are smaller than a single viewport. We generate bitmaps for all tiles currently in the viewport and those for a region around the viewport are prefetched to keep scrolling smooth. Experimentation with compressing the out-of-viewport bitmaps until they were in view showed potential memory savings from 10 MB down to just 100 kB. However, after gathering more performance data it was determined that the compression resulted in a significant increase in browser jankiness and for example [FID] due to the additional CPU overhead. Consequently, this behavior was removed in favor of smaller tiles and more proactive discarding of out-of-viewport bitmaps.
Freeze Dried Tabs are a compelling alternative to screenshots particularly for transitional views or places where web content might not be immediately available and waiting for it to become available would be slow. They provide additional fidelity over a screenshot and allow some useful user behavior such as links and scrolling to behave similarly to how they would in a web page.
Currently, Freeze Dried Tabs are being used in Chrome to provide a 20% perceptible speedup in cold startup on Android. We are exploring additional places where this technology might be used.
Posted by Calder Kitagawa, Chrome Software Engineer
Chrome 106 Beta: New CSS Features, WebCodecs and WebXR Improvements, and More
Thursday, September 1, 2022
Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, ChromeOS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 106 is beta as of September 1, 2022. You can download the latest on Google.com for desktop or on Google Play Store on Android.
Origin Trials
This version of Chrome supports 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.
Anonymous iframes
Anonymous iframes give developers a way to load documents in third-party iframes using new and ephemeral contexts. Anonymous iframes are a generalization of COEP, i.e. Cross-Origin-Embedder-Policy: credentialless to support third-party iframes that may not deploy COEP. As with COEP: credentialless, it replaces the opt-in of cross-origin subresources with avoiding loading of non-public resources. This removes the constraint that third party iframes must support COEP in order to be embedded in a COEP page and unblocks developers looking to adopt cross-origin-isolation.
The origin trial is expected to last through Chrome 108. To sign up for the origin trial, visit its sign up page.
Pop-Up API
The Pop-Up API lets developers build transient user interface elements to display on top of other web app interface elements. This API is useful for creating interactive elements such as action menus, form element suggestions, content pickers, and teaching user interfaces.
This API uses a new popup content attribute to enable any element to be displayed in the top layer. This attribute's effect on the pop-up is similar to that of the <dialog> element, but has several important differences, including light-dismiss behavior, pop-up interaction management, animation, event support, and non-modal mode.
The origin trial is expected to last through Chrome 110. To sign up for the origin trial, visit its sign up page.
Other Features in this Release
Client Hints persistency in Android WebView
Client Hints are now persisted on Android WebView, creating parity with the rest of the web platform. Previously, WebView did not persist the list of Client Hints a page requests, so the initial load of a website would never include Client Hints. Only subresources on a given page would receive them. This undermined the use of the Client Hints system, which is to empower websites to adapt content to the user agent. For more information on Client Hints, see HTTP Client hints.
CSS
grid-template properties interpolation
In CSS Grid, the 'grid-template-columns' and 'grid-template-rows' properties allow developers to define line names and track sizing of grid columns and rows respectively. Supporting interpolation for these properties allows grid layouts to smoothly transition between states, instead of snapping at the halfway point of an animation or transition.
'ic' length unit
The 'ic' length unit expresses CSS lengths relative to the advanced measure of the water ideograph used in some Asian fonts such as Chinese and Japanese. This allows authors to size elements to fit a given number of full width glyphs for such fonts. Gecko and WebKit already support this unit. Adding this to Chrome is part of Interop 2022.
‘preserve-parent-color' value for the ‘forced-color-adjust' CSS property.
The 'preserve-parent-color' value has been added to the 'forced-color-adjust' CSS property. Previously, when the forced colors mode was enabled, the 'color' property was inherited. Now, when the 'preserve-parent-color' value is used, the 'color' property will use the value of its parent. Otherwise, the 'forced-color-adjust: preserve-parent-color' value behaves the same as 'forced-color-adjust: none'.
Unprefix -webkit-hyphenate-character property
Chrome now supports the unprefixed hyphenate-character property in addition to the -webkit-hyphenate-character property. The -webkit-hyphenate-character property will be deprecated at a later date.
JavaScript: Intl.NumberFormat v3 API
Intl.NumberFormat has the following new features:
- Three new functions to format a range of numbers:
formatRange(),formatRangeToParts(), andselectRange() - A grouping enum
- New rounding and precision options
- Rounding priority
- Interpretation of strings as decimals
- Rounding modes
- Sign display negative (zero shown without a negative sign)
For more information, see the original proposal's README.
SerialPort BYOB reader support
The underlying data source for a ReadableStream provided by a SerialPort is now a readable byte stream. SerialPort "bring your own buffer" (BYOB) is backwards-compatible with existing code that calls port.readable.getReader() with no parameters. To detect support for this feature, pass 'byob' as the mode parameter when calling getReader(). For example:
port.readable.getReader({ mode: 'byob' });
Older implementations will throw a TypeError when the new parameter is passed.
BYOB readers allow developers to specify the buffer into which data is read instead of the stream allocating a new buffer for each chunk. In addition to potentially reducing memory pressure, this allows the developer to control how much data is received because the stream cannot return more than there is space for in the provided buffer. For more information, see Read from and write to a serial port.
WebCodecs dequeue event
A dequeue event and associated callback have been added to the audio and video interfaces, specifically: AudioDecoder, AudioEncoder, VideoDecoder, and VideoEncoder.
Developers may initially queue encoding or decoding work by calling encode() or decode() respectively. The new dequeue event is fired to indicate when the underlying codec has ingested some or all of the queued work. The decrease in the queue size is already reflected by a lower value of encoder.encodeQueueSize and decoder.decodeQueueSize attributes. The new event eliminates the need to call setTimeout() to determine when the queue has decreased (in other words, when they should queue more work).
WebXR Raw Camera Access
Applications using the WebXR Device API can now access pose-synchronized camera image textures in the contexts that also allow interacting with other AR features provided by WebXR.
Deprecations, and Removals
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.
Remove non-ASCII characters in cookie domain attributes
To align with the latest spec (RFC 6265bis), Chromium now rejects cookies with a Domain attribute that contains non-ASCII characters (for example, éxample.com).
Support for IDN domain attributes in cookies has been long unspecified, with Chromium, Safari, and Firefox all behaving differently. This change standardizes Firefox's behavior of rejecting cookies with non-ASCII domain attributes.
Since Chromium has previously accepted non-ASCII characters and tried to convert them to normalized punycode for storage, we will now apply stricter rules and require valid ASCII (punycode if applicable) domain attributes.
Remove HTTP/2 push
Chrome has removed the ability to receive, keep in memory, and use HTTP/2 push streams sent by the server. See Removing HTTP/2 Server Push from Chrome for details and suggested alternative APIs.