Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Android WebView, 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 93 is beta as of July 29, 2021.

Origin Trials

This 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 Trials

Cross-Origin-Embedder-Policy: credentialless

Cross-origin no-CORS requests can now be made to omit credentials (cookies, client certificates, etc.) using the credentialless keyword. Similarly to COEP: require-corp, it can enable cross-origin isolation.

Sites that wish to continue using SharedArrayBuffer must opt-in to cross-origin isolation. Today, COEP: require-corp exists, and is used to enable cross-origin isolation. It is functional and solid, but turns out to be difficult to deploy at scale, as it requires all subresources to explicitly opt-in. This is fine for some sites, but creates dependency problems for sites that gather content from users (Google Earth, social media generally, forums, etc.).

Multi-Screen Window Placement

The Multi-Screen Window Placement API allows you to place windows on any display connected to your machine, store that placement, and make a window full-screen on any display. With this API, a presentation app can show slides on one screen and speaker notes on another. An art or music creation app can place palettes on a second screen. And a restaurant can show a touchscreen menu on a kiosk and a separate window for employees. Incorporating developer feedback from the first origin trial, the API enters a second origin trial with an improved shape and ergonomics.

Window Controls Overlay for Installed Desktop Web Apps

Window controls overlay extends an app's client area to cover the entire window, including the title bar, and the window control buttons (close, maximize/restore, minimize). The web app developer is responsible for drawing and input-handling for the entire window except for the window controls overlay. Developers can use this feature to make their installed desktop web apps look like O.S. apps. For more information, see Customize the window controls overlay of your PWA's title bar.

PWAs as URL Handlers

PWA as URL Handlers allows apps like music.example.com to register themselves as URL handlers for URLs that match patterns like https://music.example.com, https://*.music.example.com, or https://🎵.example.com, so that links from outside of the PWA, for example, from an instant messenger application or an email client, open in the installed PWA rather than in a browser tab.

Completed Origin Trials

The following features, previously in a Chrome origin trial, are now enabled by default.

Subresource loading with Web Bundles

Web Bundles provides a new approach to load a large number of resources efficiently using a format that allows multiple resources to be bundled. This feature addresses issues with previous approaches to resource bundling.

The output of some JavaScript bundlers does not interact well with the HTTP cache and configuring them can sometimes be difficult. Even with bundled JavaScript, execution needs to wait for all bytes to download. Ideally loading multiple subresources should use streaming and parallelization, which is not possible with one JavaScript file. For JavaScript modules, execution still needs to wait for an entire resource tree to download because of deterministic execution.

WebXR Plane Detection API

WebXR applications can now retrieve data about planes present in a user's environment, which enables augmented reality applications to create more immersive experiences. Without this feature, developers would have to resort to running their own computer vision algorithms on data from getUserMedia() (available on navigator and MediaDevices) in order to detect planes present in the users' environment. Such solutions have thus far been unable to match the quality and accuracy of native augmented reality capabilities or support world scale.

Other features in this release

AbortSignal.abort() Static Method

AbortSignal.abort() is a static method that allows creating a new AbortSignal object that is already aborted. It is similar in spirit to Promise.reject(), and provides improved developer ergonomics.

Web developers have found aborted AbortSignal objects to be useful for a variety of purposes. They signify to JavaScript APIs that no work should be done. Currently, creating an already-aborted AbortSignal object requires multiple lines of code. AbortSignal.abort() requires one:

return AbortSignal.abort();

CSS Flexbox: Support Alignment Keywords start, end, self-start, self-end, left, right

The flexbox and flex items now obey positional alignment keywords. Flexbox previously only obeyed center, flex-start, and flex-end. The additional alignment keywords (start, end, self-start, self-end, left, right) allow authors to more easily align the flex items in the face of varying writing modes and flex flows.

Without these additional keywords, developers need to change the keyword values whenever they change the writing mode, text direction, or flex reversal properties (flex-direction: row-reverse, flex-direction:column-reverse or align-content: wrap-reverse). The keywords implemented here let them set alignment once.

Error.cause Property

The Error() constructor supports a new options property called cause, which will be assigned to the error as a property. This allows errors to be chained without unnecessary and overelaborate formalities on wrapping the errors in conditions.

Honor Media HTML Attribute for meta name=theme-color

The meta element's "media" attribute will be honored for meta[name="theme-color"] so that web developers can adjust the theme color of their site based on a media query (dark and light modes for instance). The first one that matches will be picked.

noplaybackrate in HTMLMediaElement.controlsList

The HTMLMediaElement.controlsList property now supports noplaybackrate, which allows websites to enabled or disable the playback speed control exposed by the browser. With browser vendors adding playback speed control to their media controls, developers should have a way to control the visibility of this new control. Try the new property on the noplaybackrate in HTMLMediaElement.controlsList Sample.

Sec-CH-Prefers-Color-Scheme Client Hint Header

The CSS user preference media feature prefers-color-scheme has a potentially significant impact on the amount of CSS that needs to be delivered by a page and on the experience the user is going to have when the page loads. The new Sec-CH-Prefers-Color-Scheme client hint header allows sites to obtain the user's preference optionally at request time, allowing servers to inline the right CSS and therefore avoid a flash of incorrect color theme.

User-Agent Client Hints API Updates

This version of Chrome adds four new features and changes to the User-Agent client hints API.

Labels:



Keeping Chrome users safe as they browse the web is crucially important to Chrome; in fact, security has always been one of our four core principles. In some cases, security can come at the expense of performance. In our next post in The Fast and the Curious series, we are excited to share how improvements to our phishing detection algorithms keeps users safe online. With these improvements, phishing detection is now 50 times faster and drains less battery.

Phishing detection

Every time you navigate to a new page, Chrome evaluates a collection of signals about the page to see if it matches those of phishing sites. To do that, we compare the color profile of the visited page - that’s the range and frequency of the colors present on the page - with the color profiles of common pages. For example in the image below, we can see that the colors are mostly orange, followed by green and then a touch of purple.





If the site matches a known phishing site, Chrome warns you to protect your personal information and prevent you from exposing your credentials.



What you will see if a phishing attempt is detected

To preserve your privacy, by default Chrome's Safe Browsing mode never sends any images outside the browser. While this is great for privacy, it means that your machine has to do all the work to analyze the image.

Image processing can often generate heavy workloads because analyzing the image requires an evaluation of each pixel in what is commonly known as a “pixel loop.” Some modern monitors display upwards of 14 million pixels, so even simple operations on each of those pixels can add up to a lot of CPU use! For phishing detection, the operation that takes place on each pixel is the counting of its basic colors.

Here is what this looks like. The counts are stored in an associative data structure called a hashmap. For each pixel, we extract its RGB color values and store the counts in one of 3 different hashmaps -- one for each color.





Making it more efficient

Adding one item to a hashmap is fast, but we have to do this for millions of pixels. We try to avoid reducing the number of pixels to avoid compromising the quality of the analysis. However, the computation itself can be improved.

Our improvements to the pipeline look like this:
  • The code now avoids keeping track of RGB channels in three different hashmaps and instead uses only one to index by color. Three times less counting!
  • Consecutive pixels are summed before being counted in the hashmap. For a site with a uniform background color, this can reduce the hashmap overhead to almost nothing.
Here is what the counting of the colors looks like now. Notice how there are significantly fewer operations on the hashmap:





How much faster did this get?

Starting with M92, Chrome now executes image-based phishing classification up to 50 times faster at the 50th percentile and 2.5 times faster at the 99th percentile. On average, users will get their phishing classification results after 100 milliseconds, instead of 1.8 seconds.

This benefits you in two ways as you use Chrome. First and foremost, using less CPU time to achieve the same work improves general performance. Less CPU time means less battery drain and less time with spinning fans.

Second, getting the results faster means Chrome can warn you earlier. The optimization brought the percentage of requests that took more than 5 seconds to process from 16.25% to less than 1.6%. This speed improvement makes a real difference in security - especially when it comes to stopping you from entering your password in a malicious site!

Overall, these changes achieve a reduction of almost 1.2% of the total CPU time used by all Chrome renderer processes and utility processes.

At Chrome’s scale, even minor algorithm improvements can result in major energy efficiency gains in aggregate. Here’s to many more centuries of CPU time saved!

Stay tuned for many more performance improvements to come!

Posted by Olivier Li Shing Tat-Dupuis, Chrome Developer

Data source for all statistics: Real-world data anonymously aggregated from Chrome clients.



Labels: , ,

When a browser connects to websites over HTTPS (vs. HTTP), eavesdroppers and attackers on the network can't intercept or alter the data that's shared over that connection (including personal info, or even the page itself). This level of privacy and security is vital for the web ecosystem, so Chrome continues to invest in making HTTPS more widely supported.

Thankfully, HTTPS adoption has come a long way in recent years, and most operating systems now see 90%+ of page loads over HTTPS in Chrome. Still, there's more we can do to help make HTTPS the preferred protocol on the web, and better protect users on the remaining slice of the web that doesn’t yet support HTTPS, so today we're sharing some future work in this area.



Opting in to an HTTPS-First World


Beginning in M94, Chrome will offer HTTPS-First Mode, which will attempt to upgrade all page loads to HTTPS and display a full-page warning before loading sites that don’t support it. Users who enable this mode gain confidence that Chrome is connecting them to sites over HTTPS whenever possible, and that they will see a warning before connecting to sites over HTTP. Based on ecosystem feedback, we’ll explore making HTTPS-First mode the default for all users in the future. Mozilla has also shared their intent to make HTTPS-only mode the future of web browsing in Firefox.



Experimenting with the lock icon

As we approach an HTTPS-first future, we're also re-examining the lock icon that browsers typically show when a site loads over HTTPS. In particular, our research indicates that users often associate this icon with a site being trustworthy, when in fact it's only the connection that's secure. In a recent study, we found that only 11% of participants could correctly identify the meaning of the lock icon. To try and reduce this confusion, Chrome will run an experiment in M93 that replaces the lock in the address bar with a more neutral entry point to Page Info (example below). We hope that this experiment will improve the discoverability of critical privacy and security information and controls provided in Page Info, such as site permissions. Importantly, a "Not Secure" indicator will continue to show on sites without HTTPS support, and the experiment includes an enterprise policy in case organizations want to opt-out. In all cases, we'll provide advance notice if we decide to move ahead with a full launch.





Protecting users on the HTTP web


While we are excited to see users adopt HTTPS-First Mode in future versions of Chrome, HTTP connections will still continue to be supported and Chrome will take additional steps to protect and inform users whenever they are using insecure connections. Continuing from our past efforts to restrict new features to secure origins and deprecate powerful features on insecure origins, we’ll evaluate a broad set of web platform features to determine if they should be limited or restricted on HTTP webpages.

In order to focus on changes that provide the greatest security improvements to our users, we are relying on a set of guiding principles to prioritize our future work in this area:

  • Better inform users when making trust decisions about sites over insecure connections
  • Limit the ability for sites to opt out of security policies over insecure connections
  • Restrict how, and for how long, Chrome stores site content provided over insecure connections
A deeper explanation of how we plan to act on these principles, as well as an updated list of affected features will be maintained on the Chromium wiki and we are excited to announce more details later this year.

Posted by Shweta Panditrao, Devon O'Brien, Emily Stark, Google Chrome team


Labels: ,