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-corpCross-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.
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.
There 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.
NFC 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 Summit
With 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}`); }; }
A 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.
To 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.
navigator.share()
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.
There 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.
Chrome 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:
A 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.
The 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_override
display
"minimal-ui"
"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.
Chrome 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.
ReadableStreamDefaultController
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.
performance.measureUserAgentSpecificMemory()
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.
The 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.
Chrome 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().
'filter'
url()
blur()
sepia()
grayscale()
<filter>
Chrome 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.
AuthenticatorSelectionCriteria.residentKey
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.
credProps
Adds a highlight pseudo element to allow authors to style scroll-to-text fragments differently from the default user agent highlighting.
scroll-to-text
Flow-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
The forced-colors media feature detects whether the user agent is enforcing a user-chosen limited color palette on the page.
forced-colors
The forced-color-adjust property allows authors to opt particular elements out of forced colors mode, restoring full control over the colors to CSS.
forced-color-adjust
This 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.
Chrome 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.
await
EXIF 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.
image-orientation: none
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.
The legacy prefixed events (webkitprerenderstart, webkitprerenderstop, webkitprerenderload, and webkitprerenderdomcontentloaded) dispatched on <link rel=prerender> are now removed from Chrome.
webkitprerenderstart
webkitprerenderstop
webkitprerenderload
webkitprerenderdomcontentloaded
<link rel=prerender>
When 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.
sessionStorage
A default Action Button that shares the URL is added to the top bar when the application doesn’t provide one.
val customTabsIntent = CustomTabsIntent.Builder()
.setShareState(CustomTabsIntent.SHARE_STATE_OFF)
.build();
Posted by André Bandarra, Developer Relations Engineer and Chirag Desai, Product Manager
Posted by Jochen Eisinger, Engineering Director, Google Chrome
We all benefit from an open web that is secure, powerful, and fast. Over the past year, we’ve focused our efforts on strengthening the web in three areas:
This post is a synopsis of the updates we shared during today’s keynote at Chrome Dev Summit.
We’ve continued work on the Privacy Sandbox and we are committed to developing an open set of standards that fundamentally enhance privacy on the web. Together with the web community, we're building new privacy-preserving alternatives to third-party cookies or other cross-site tracking mechanisms. With the Client Hints API, we’re reducing the fingerprinting surface of Chrome, and we have two solutions for you to experiment with via our Chrome origin trials. The Click Conversion Measurement API measures ad conversions without using cross-site identifiers, and the Trust Token APIs help convey trust from one context to another without passive tracking.
Similarly, the security and privacy of extensions has become of utmost importance with hundreds of millions of people using over 250,000 items in the Chrome Web Store. We believe extensions must be trustworthy by default and it’s why we announced a draft proposal for a number of changes to our extension platform. After incorporating a number of different suggestions from extension developers, we're ready to launch the stable release of Manifest V3 with the goal of increased security, more control and privacy for users, and improved performance.
With Manifest V3, remote hosted code is no longer permissible to prevent malicious extensions that abuse user privacy and security. Additionally, the new extensions model allows users to withhold sensitive permissions at install time. Lastly, a new approach to background logic with the introduction of service workers for background pages and a new declarative model for extension APIs provides users more consistent performance guarantees. Manifest V3 is now available to experiment with on Chrome 88 beta, with the Chrome Web Store accepting Manifest V3 extensions mid-January when Chrome 88 reaches stable.
Great examples are coming to life from developers who are building new experiences on the web. Gravit Designer makes it easy for users to read and write files with File System Access APIs and allows the use of specialized fonts installed locally with the new Local Font Access API. Adobe has made it easy for users to create stunning visual stories and beautifully designed content with their Spark web app.
Today, we are adding new capabilities for Progress Web Apps (PWAs) to increase their discoverability by being listed in the Google Play Store. In Chrome 86 we gave you the ability to list your PWA in the Play Store using a Trusted Web Activity. We’ve now made it possible for you to start accepting payments using the new Digital Goods API in Chrome 88.
Chrome’s performance—speed and usage of resources like power, memory, or CPU—has always been top of mind so you can deliver the best experience for all our users.
Earlier this year, we made some key improvements to speed with Profile Guided Optimization & Tab throttling and today, we announced a significant reduction of V8’s memory footprint. Apart from making great strides in memory savings through V8 pointer compression, we’ve eliminated parsing pauses entirely by loading a webpage’s JavaScript files in parallel, so scripts can be parsed and compiled and ready to execute as soon as they’re needed by the page.
Since we announced our Web Vitals initiative, they are being increasingly used to measure web page performance. Google Search announced new signals to search ranking will include Core Web Vitals starting in May 2021. In addition to the Chrome User Experience Report, Search Console’s Core Web Vitals report, and many other Google tools, other providers like Cloudflare are surfacing Core Web Vitals as web page performance metrics.
Last summer, we released the web-vitals Javascript library for those sites using Google Analytics. Today we announced the Web Vitals Report, an open source website and tool that lets you query and visualize your Web Vitals metrics data in Google Analytics, enabling you to easily compare performance data across segments.
Finally, we’ve been listening to your feedback and hearing about your difficulties in building web interfaces. We’ve been working to improve the web’s styling capabilities and shipped content-visibility, a CSS feature that significantly improves rendering performance. Look for more updates and tools to improve UI styling, including the announcement of Houdini.how, a set of APIs that makes it easier for you to extend CSS.
Chrome Dev Summit has always been about connecting with the community. Although we weren’t able to convene together in person, the Chrome team launched a PWA to bring the best parts of a physical conference -- serendipitous conversations, discovering new things, and collecting swag -- to life with Chrome Dev Summit Adventure. We can’t wait to hear what you think of this experiment and look forward to chatting with you in real-time.
Become part of the community and join a Google Developer Group around the world. Check out the full list of CDS Extended events that brings together regional developer communities to recap the highlights from Chrome Dev Summit 2020 along with live interactive sessions.
Watch the sessions any time on our YouTube channel and for all the latest updates on the web, sign up for the web.dev newsletter.
See you next year!
Posted by Ben Galbraith & Dion Almaer
With hundreds of millions of people using over 250,000 items in the Chrome Web Store, extensions have become essential to how many of us experience the web and get work done online. We believe extensions must be trustworthy by default, which is why we’ve spent this year making extensions safer for everyone.
Today we’re officially announcing the planned rollout of Manifest V3 for Chrome Extensions, a new version of the extensions platform that makes extensions more secure, performant, and private-respecting by default.
With the introduction of Manifest V3, we will disallow remotely hosted code. This mechanism is used as an attack vector by bad actors to circumvent Google’s malware detection tools and poses a significant risk to user privacy and security.
The removal of remotely hosted code will also allow us to more thoroughly and quickly review submissions to the Chrome Web Store. Developers will then be able to release updates to their users more quickly.
On the extensions team, we believe that a trustworthy Chrome and a trustworthy extensions experience is not only great for users but is also essential for developers. In the long run, Manifest V3 will help the extension ecosystem continue to be a place that people can trust.
We know that performance is key to a great user experience, and as we began work on the third iteration of our extension platform, performance was a foundational consideration. Two areas where this has manifested are our approach to background logic and API design.
First, we are introducing service workers as a replacement for background pages. Unlike persistent background pages, which remain active in the background and consume system resources regardless of whether the extension is actively using them, service workers are ephemeral. This ephemerality allows Chrome to lower overall system resource utilization since the browser can start up and tear down service workers as needed.
Second, we are moving to a more declarative model for extension APIs in general. In addition to security benefits, this provides a more reliable end-user performance guarantee across the board by eliminating the need for serialization and inter-process communication. The end result is better overall performance and improved privacy guarantees for the vast majority of extension users.
To give users greater visibility and control over how extensions use and share their data, we’re moving to an extensions model that makes more permissions optional and allows users to withhold sensitive permissions at install time. Long-term, extension developers should expect users to opt in or out of permissions at any time.
For extensions that currently require passive access to web activity, we’re introducing and continuing to iterate on new functionality that allows developers to deliver these use cases while preserving user privacy. For example, our new declarativeNetRequest API is designed to be a privacy-preserving method for extensions to block network requests without needing access to sensitive data.
The declarativeNetRequest API is an example of how Chrome is working to enable extensions, including ad blockers, to continue delivering their core functionality without requiring the extension to have access to potentially sensitive user data. This will allow many of the powerful extensions in our ecosystem to continue to provide a seamless user experience while still respecting user privacy.
declarativeNetRequest
When the Manifest V3 draft proposal was initially shared with the Chromium developer community, we received an abundance of helpful feedback — thank you! We have been working closely with the developers of many extensions — including ad blockers, shopping extensions, productivity enhancements, developer tools, and more — to evolve the platform.
We've used this feedback to improve the functionality and usability of the API surfaces associated with Manifest V3. For example, we have added support to declarativeNetRequest for multiple static rulesets, regular expressions within rules, declarative header modification, and more.
“We’ve been very pleased with the close collaboration established between Google’s Chrome Extensions Team and our own engineering team to ensure that ad-blocking extensions will still be available after Manifest V3 takes effect." — Sofia Lindberg, Tech Lead, eyeo (Adblock Plus)
Even after Manifest V3 launches, expect more functionality and iteration as we continue to incorporate feedback and add new features to make V3 even more powerful for developers while preserving user privacy. If you are interested in contributing to the conversation, please comment and discuss on the chromium-extensions Google Group.
Manifest V3 is now available to experiment with on Chrome 88 Beta, with additional exciting features to follow in upcoming releases. The Chrome Web Store will start accepting Manifest V3 extensions January, shortly after Chrome 88 reaches stable. While there is not an exact date for removing support for Manifest V2 extensions, developers can expect the migration period to last at least a year from when Manifest V3 lands in the stable channel. We will continue to provide more details about this timeline in the coming months.
Posted by David Li - Product Manager, Chrome & Simeon Vincent - Developer Advocate, Chrome
App developers should be able to make money from their creations, whether via ads, purchases, or subscriptions. The first step to successfully monetizing is getting your app discovered.
Now that Progressive Web Apps (PWAs) can be listed in Google Play, we’re excited to announce that web developers can use Google Play payments in their PWA on Chromebooks and Android devices. This makes it even easier to get your PWA in front of more users and start accepting simple, secure payments by listing in Google Play.
Since their release, Chromebooks and Chrome OS have proven that a device built around the web can make computing easier, faster, and more secure. Last year, we expanded high-quality app experiences beyond mobile by adding support for PWAs on Chrome OS. And that’s clearly resonated with users — in the past year, Chromebook unit sales have grown 85% year over year (YOY)1, and PWA installs more than doubled2.
With all the new capabilities being added to web apps — from saving to the local file system to device communication — we saw an opportunity to highlight the best experiences for Chromebook users.
Search continues to be a quick and easy way to discover new web apps, but many people are also turning to app stores to find the best software for their device in one place. That’s why we gave developers the ability to list their PWA in Google Play on Chrome OS using Trusted Web Activity. Now, users can discover web apps by browsing through collections and curated recommendations in the Play Store. And once they install it, they’ll be able to enjoy the full-screen app experience they love, powered by Chrome.
Brands like Kapwing, an online image, video, and GIF editing platform, have already seen impressive results after launching their PWA:
"In the first five weeks of launching our PWA-ified website, the number of people creating videos through the PWA grew 36%. This growth in usage outpaced overall growth on the website, indicating higher retention among creators who installed the PWA." - Julia Enthoven, CEO of Kapwing
If your app accepts payments, you can simplify the process by using the Digital Goods API with Google Play. This feature is ready to start testing behind a flag in Chrome OS 88 and will launch with Chrome OS 89 in March 2021.
These APIs allow you to offer in-app payments and subscriptions with a single click, and users see the same, familiar Google Play billing flow with the ability to save credits or payment information.
We’ve already seen great responses to PWAs on Chromebooks — users enjoying the advanced graphics on Adobe Spark and Corel’s Gravit Designer, sharper video editing with Clipchamp, and more powerful viewing experiences on YouTube TV. We’re excited to share that all of these experiences will arrive in the Play Store as soon as the Digital Goods API arrives in Chrome OS 89.
It’s incredible to see the journey of developers as they build their web apps for larger screens. We can’t wait to showcase amazing web apps like these on Google Play — and we hope to see yours there soon!
Posted by PJ McLachlan & Tom Buckley
Sources: 1 The NPD Group, Inc., U.S. Retail Tracking Service, Notebook Computers, based on unit sales, Jan.–Aug. 2020. 2 Chrome usage metrics, Dec. 2019–Dec. 2020.
“Loading a page without prefetching”
“Naively prefetching websites can result in leaking user’s interest in some content or product”
“Prefetching websites via a CONNECT proxy prevents leaking user information”
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 88 is beta as of December 3, 2020.
Chrome now supports an API for querying and managing digital products to facilitate in-app purchases from web applications. This is used with the Payment Request API, which is used to make the actual purchases. The API would be linked to a digital distribution service connected via the user agent. In Chromium, this is specifically a web API wrapper around the Android Play Billing API.
This is needed so that web apps in the Play Store can accept purchases for digital goods. (Play policies prevent them from accepting payment via any other method.) Without this, websites that sell digital goods are not installable through the Play Store.
In Chrome 88, this is available for Android in an origin trial. For a list of other origin trials starting in this release, see below.
This version of Chrome introduces the origin trial 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 Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.
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 help to make models feel more natural and like they "fit" better with the user's environment. This can make them feel more "real" or "natural".
In Chrome 88, this is available for Android only.
The following features, previously in Chrome origin trials, are now enabled by default.
Adds the performance.measureMemory() method that estimates the memory usage of the web page in case the page is currently isolated (e.g. on Desktop). Because the method is gated behind COOP/COEP web sites need to enabled crossOriginIsolated to use this method. For more information, see Monitor your web page's total memory usage with measureMemory().
Adds the ability to request unadjusted/unaccelerated mouse movement data when in PointerLock. If unadjustedMovement is set to true, then the pointer movements will not be affected by the underlying platform modifications such as mouse acceleration. For more information, see Disable mouse acceleration to provide a better FPS gaming experience.
PointerLock
unadjustedMovement
To mitigate "tab-napping" attacks, in which a new tab/window opened by a victim context may navigate that opener context, anchors that target _blank will behave as though rel is set to noopener. To opt out of this behavior, you can set rel to opener. This conforms to a change in the HTML standard.
_blank
rel
noopener
Dark mode is an accessibility feature that allows web authors to enable their web pages to be viewed in dark mode. When enabled, users are able to view dark mode supported websites by toggling the dark mode settings on their OS. The benefits of dark mode are being easier on the eyes in a low light environment and lower battery consumption. For more about dark mode and form controls, see Improved dark mode default styling with the color-scheme CSS property and the corresponding meta tag.
Adds the AbortSignal option, named signal, to the options parameter of addEventListener(). The signal option must first be created by an AbortController by accessing the signal property on an AbortController instance. Once the signal is passed in to addEventListener(), calling AbortController.abort() removes the event listener added with addEventListener().
AbortSignal
signal
addEventListener()
AbortController
AbortController.abort()
Allows explicitly specifying an aspect ratio for any element to get similar behavior to a replaced element. This generalizes the aspect ratio concept to general elements. It allows various effects, examples include sizing <iframe> elements using an aspect ratio, filmstrips where each element has the same height but needs an appropriate width, and cases where a replaced element is wrapped by a component but should keep the aspect ratio.
<iframe>
Allows complex selectors inside the :not() pseudo class, such as :not(.a .b .c).
:not()
:not(.a .b .c)
When adopting a shadow root into a <template> document from a document that the <template> is in (or vice versa), Chrome will no longer clear its adoptedStyleSheets. Currently Chrome always clears adoptedStyleSheets when the shadow root containing it is adopted into a different document. This ensures that constructed stylesheets are not used across <iframe> elements, but this also covers adopting into/from <template> elements, causing some confusion for the web developer.
<template>
adoptedStyleSheets
A new attribute on ElementInternals, shadowRoot, allows custom elements to access their own shadow root, regardless of open/closed status. Additionally, further restrictions are added to the attachInternals() method to ensure that custom elements get the first chance to attach the ElementInternals interface. With this change, the attachInternals() method will throw an exception if called before the custom element constructor being run.
ElementInternals
shadowRoot
attachInternals()
This feature was mostly driven, at least initially, by the declarative Shadow DOM feature introduction. With declarative Shadow DOM, there was a problem with closed shadow roots: declarative shadow content loads before the custom element is upgraded, which means that closed shadow content would have been inaccessible. In addition to the declarative Shadow DOM use case, this feature also offers a convenience to custom element authors, who no longer need to keep a reference to attached shadow roots, and can instead use the ElementInternals interface.
The type parameter in WakeLock.request() is now optional and defaults to "screen", which is currently the only allowed value. For more information, see Stay awake with the Screen Wake Lock API.
type
WakeLock.request()
"screen"
Origin isolation allows developers to opt in to giving up certain cross-origin same-site access capabilities—namely synchronous scripting via document.domain, and calling postMessage() with WebAssembly.Module instances. This gives the browser more flexibility in implementation technologies. Reasons why a site may want better isolation include: performance isolation, allocations of large amounts of memory, side-channel protection (e.g. against Spectre), and improved memory measurement.
document.domain
postMessage()
WebAssembly.Module
Adds support for path() as a value for the CSS clip-path property, which allows specifying SVG-style paths for clipping. This supplements the four basic shapes currently supported by clip-path: circle, ellipse, polygon, and url. For example, the following would clip an element with a triangle: clip-path: path(oddeven, 'M 5 5 h 100 v 100 Z')
path()
clip-path
circle
ellipse
polygon
url
clip-path: path(oddeven, 'M 5 5 h 100 v 100 Z')
The Permissions-Policy HTTP header replaces the existing Feature-Policy header for controlling delegation of permissions and powerful features. The header uses a structured syntax, and allows sites to more tightly restrict which origins can be granted access to features.
Permissions-Policy
Feature-Policy
Transceivers allow the sending and/or receiving of media in WebRTC. Stopping a transceiver makes it permanently inactive and frees its network port, encoder, and decoder resources. This also makes its m= section in the SDP reusable by future transceivers, preventing the SDP from growing indefinitely as transceivers are added and removed. This is part of "Perfect Negotiation", which makes signaling in WebRTC race free and less error-prone.
m=
This version of Chrome incorporates version 8.8 of the V8 JavaScript engine. It specifically includes the change listed below. You can find a complete list of recent features in the V8 release notes.
Adds the JavaScript type SharedArrayBuffer gated behind COOP/COEP. A SharedArrayBuffer allows a message to be posted to a worker by sending a reference instead of a copy of the sent data.JavaScript Atomics provides atomic loads and stores and read/modify/write accesses to SharedArrayBuffer objects. Atomics.wait() provides the ability for a worker to wait for another worker to signal it, without having to spinlock.
SharedArrayBuffer
Atomics.wait()
The primary use case for SharedArrayBuffer is for asm.js code, but it is also useful for implementing other higher-level sharing between Workers.
For more information, see Making your website "cross-origin isolated" using COOP and COEP.
Since Chrome 80, pages have no longer been able to open a new page during unloading using window.open(). Since then enterprises have been able to use the AllowPopupsDuringPageUnload policy flag to allow popups during page unload. Starting in Chrome 88, this flag is no longer supported.
window.open()
Chrome is removing support for FTP URLs. The legacy FTP implementation in Chrome has no support for encrypted connections (FTPS), nor proxies. Usage of FTP in the browser is sufficiently low that it is no longer viable to invest in improving the existing FTP client. In addition, more capable FTP clients are available on all affected platforms.
Google Chrome 72 and later removed support for fetching document subresources over FTP and rendering of top level FTP resources. Navigating to FTP URLs results in showing a directory listing or a download depending on the type of resource. A bug in Google Chrome 74 and later resulted in dropping support for accessing FTP URLs over HTTP proxies. Proxy support for FTP was removed entirely in Google Chrome 76.
The remaining capabilities of Google Chrome's FTP implementation were restricted to either displaying a directory listing or downloading a resource over unencrypted connections.
In Chrome 77, FTP support was disabled by default for fifty percent of users but was available with flags.
In Chrome 88 all FTP support is disabled.
Web Components v0 have been in a reverse origin trial since Chrome 80. This allowed users of the API time to upgrade their sites while ensuring that new adopters of Web Components used version 1. The reverse origin trial ends with Chrome 87, making Chrome 88 the first in which version 0 is no longer supported. The Web Components v1 APIs replace Web Components v0 and are fully supported in Chrome, Safari, Firefox, and Edge. This removal covers the items listed below.
Protecting users and their data is a fundamental aspect of the work we do on Chrome. Last year, as part of Google’s Project Strobe, we announced an important set of policies for extensions to protect users and their data. These policies require extensions to request only the permissions needed to implement their features. Additionally, we required more extensions to post privacy policies and handle user data securely.
Today, we are announcing changes that build upon those protections with an update to our developer policy that limits what extension developers can do with the data they collect. The new policy also requires developers to certify their data use practices, and display that information directly on the Chrome Web Store listing to help users understand an extension’s privacy practices.
Starting January 2021, each extension’s detail page in the Chrome Web Store will show developer-provided information about the data collected by the extension, in clear and easy to understand language. Data disclosure collection is available to developers today.
We are also introducing an additional policy focused on limiting how extension developers use data they collect. More specifically:
Ensuring the use or transfer of user data is for the primary benefit of the user and in accordance with the stated purpose of the extension.
Reiterating that the sale of user data is never allowed. Google does not sell user data and extension developers may not do this either.
Prohibiting the use or transfer of user data for personalized advertising.
Prohibiting the use or transfer of user data for creditworthiness or any form of lending qualification and to data brokers or other information resellers.
The item listing page will also display whether the developer has certified that their extension complies with this new policy.
To publish or update an extension, our new policy will require developers to provide data usage disclosures directly from the privacy tab of the developer dashboard. These disclosures include:
The nature of the data being collected from users.
The developer’s certification that they comply with the new Limited Use policy.
The disclosure form is grouped by category to make it simpler for developers, and maps exactly to the disclosures that will be displayed to Chrome users. Most of this information will be consistent with existing privacy policies that developers have provided to the Chrome Web Store.
Data disclosures collection will be made available to developers today, and will be displayed on the Chrome Web Store listing starting January 18, 2021.
For developers who have not yet provided privacy disclosures by January 18, 2021, a notice will be shown on their Chrome Web Store listings to inform users that the developer hasn’t certified that they comply with the Limited Use policy yet.
You can find the full policy in the Developer Program Policies page as well as additional details in the User Data FAQ .
Thank you for working with us to build a better web with transparency, choice, and control for everyone.
Posted by Alexandre Blondin and Mark M. Jaycox, Chrome Product & Policy