[go: up one dir, main page]

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:

  1. Rethinking how we can deliver a safe and secure web
  2. Adding the capabilities you need to build powerful, rich, and diverse applications
  3. Optimizing for performance, for users and developers alike

This post is a synopsis of the updates we shared during today’s keynote at Chrome Dev Summit.

Rethinking privacy from the ground up

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.

Available as Origin Trials
More info at web.dev/trust-tokens/

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.

Bringing powerful capabilities for advanced apps

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.

Optimizing for performance

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.

A virtual gathering experiment

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.

Learn more

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.

Security

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.

Performance

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.

Privacy

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.

Availability & Continued Iteration

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

Labels: ,

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.

A new way to connect with Chromebook users

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

Streamlined secure payments

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.

More amazing apps coming to Chrome OS

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.

Many people choose to save their payment information and passwords for their favorite websites to their Google Account for easy access. Until recently, it was not always easy to access them in Chrome. For example: in that moment where you (finally!) found the perfect holiday gift, and started the checkout, Chrome couldn't help you access the login credentials you had saved in Password Manager, or the payment methods you had added to your account, unless you had Chrome sync turned on for that device.

This changed last year, when we made it easier to access the payment methods in your Google Account. Since then, we've been working hard to bring the same signed-in experience to more features and users -- making it simpler and more intuitive to access your Google Account info in Chrome. We're happy to announce that over the coming weeks and months, seamless payments and password management will become available to all signed-in users, syncing or not.

More convenient sign in on Android
To help you get the most out of your Google Account, Chrome on Android will soon let you sign in with a single tap, even when not using sync. When you sign in to a Google service like Gmail, you can now choose to sign in to Chrome with one of your Google Accounts on the device – with a single tap and without having to re-enter your credentials. If you prefer to sign in without adding your account to the device, you can simply dismiss the dialog. And if you want a temporary browsing session, the menu provides a quick way to open Incognito mode.



Easier payments with Chrome on AndroidWhen you sign in to Chrome on your Android phone using the new single tap option, you’ll soon be able to autofill the payment methods stored in your Google Account for a more convenient shopping experience. Chrome will ask you to confirm the card’s CVC or let you authenticate with biometrics, and then you’re good to go. You can also save a new credit card to your account to use it across all your devices. Each time you save a card to your account, you will receive a confirmation email. You can manage and delete the cards at any time by going to your Payment methods in your account.




Easier Password Management on Chrome desktop
We’ve heard your feedback for more flexibility when it comes to having access to passwords saved to your Google Account. Over the next couple of months, accessing and managing your passwords safely across your devices will become even easier. This can all be done simply by signing in to your Google Account, regardless of whether sync is enabled. You’ll be able to autofill passwords on sites that you previously saved to your account, and when you save a new password, Chrome will let you choose where you want to save it — on the device or in your Google Account. If you choose your account, you can access it on all your devices.

With this change we’re also bringing Chrome’s password generation feature to more people, helping them create strong and unique passwords for the many online accounts people manage when using Chrome.



Keep an eye out for these features over the coming months, and as always, be sure to keep tabs on our blog for future updates. 

Posted by Sabine Borsay, Product Manager, Chrome
Labels: ,

Speed has always been a core tenet of Chrome. We care about speed, not only because it helps our users get things done quicker, but because it also contributes to making the web ecosystem more diverse by lowering the friction of discovering and engaging with more content or new websites. So, what if we could make the web more instant? Building on some of our previous work in this space, we have a new proposal that aims at speeding up navigations by downloading resources ahead of time, i.e. prefetching. The proposal defines the concept of a “private prefetch proxy” through the combination of an end-to-end encrypted CONNECT proxy to hide potentially identifiable information (e.g. user’s IP address), as well as rules governing its usage, and additional measures to ensure that the prefetches can not be personalized to the user. We are eager to work with the community on refining and generalizing the proposal for the benefit of the whole web.



Our journey toward instant experiences
In Chrome 73, with Signed HTTP Exchange, we launched the first phase of a long term effort designed to bring instant experiences to the whole web, through improved prefetching and pre-rendering techniques that are privacy and developer friendly. As a quick refresher, Signed HTTP Exchange makes it possible to create “portable” content, i.e. content that other parties can deliver on your behalf with the assurance that it will remain unaltered and properly attributed to your origin. This offers several advantages such as the ability to speed up page loads, increasing the availability of popular or critical content when the origin servers can’t keep up with the demand, and can also help reduce a publisher’s data transfer costs since the bytes are served by a third party.

In Chrome 86 for Android, we ran a proof-of-concept experiment to test a different approach that we hope will be a complementary option to Signed HTTP Exchange. While Signed HTTP Exchange can already be used to enable instant experiences, they require some extra work and setup which isn’t yet always trivial. We are always on the lookout for innovation opportunities, and with this new approach, our goal is to make it easier to achieve instant experiences across the whole web, thereby helping the community better understand the value of such experiences, and consequently motivating further investment in instant techniques or efforts meant to lower the barriers to adoption of such techniques.

The experiment consisted of prefetching the critical resources for a subset of the most likely cross-site navigations in Chrome for Android, and showed an improvement of 40% on the Largest Contentful Paint page load time metric, without revealing potentially identifiable information, such as the user’s IP address, and without requiring extra work from developers to start seeing some benefits. Given the successful proof of concept experiment, we feel ready to share more details about the approach and start engaging with the community to iterate on a viable web platform solution. But before we do, let us take you for a walk down memory lane.


“Loading a page without prefetching”



Lessons learned from prefetching and prerenderingPrefetching is a way to speed up page loads by downloading the bits and pieces that make up a web page (e.g. HTML documents, Javascript, Stylesheet, Images, etc.) in anticipation of a user navigating to said webpage. Pre-rendering is taking things a bit further by drawing and running the web page ahead of time, off-screen, so that by the time the user navigates to the web page, it’s ready to go and displays instantly.

Prefetching or pre-rendering web pages is not a brand new idea. In fact, most modern browsers have such features. For instance, Chrome for desktop had a feature called “Instant Pages” from 2011 until 2017 when it was replaced with NoState Prefetch. Here are some of the key reasons that made us take a step back with regards to pre-rendering at the time:
  • Pre-rendering was an all or nothing approach where calls to unsupported web features would result in completely abandoning pre-rendering. The intent was to avoid annoyances such as having sounds or permission prompts coming out of nowhere, but in practice, this meant that most websites were not compatible with pre-rendering and that web developers could inadvertently fall outside of the set of pre-rendering compatible web features, and lose all the benefits as a result.
  • Not all pages can be safely pre-rendered. For instance, pre-rendering a link to a page that logs you out of your favorite website would be a bad experience. Because it is non trivial to dissociate pages that are consequence-free vs. those that aren’t, this meant that we were only able to safely apply pre-rendering to a narrow subset of links on the web.
These hurdles meant that pre-rendering was only used by, and for, a handful of websites. Even today, with the NoState Prefetch approach, the feature is only used on 1.4% of all page loads. Given the significant upsides (e.g. 40% faster page loads with prefetching), we believe that the ceiling ought to be much higher. To start, we decided to set our sights on addressing a significant impediment to the use of prefetching, and by extension pre-rendering: preserving privacy while improving page load performance.


Prefetching and privacy
A fundamental challenge with prefetching another website is that it inherently happens before the user has signaled their interest, i.e. by visiting said website. So, if your browser, or favorite websites, were to prefetch links to pages on other websites that you might be interested in, it exposes potentially identifiable information, such as your IP address or cookies, to the servers hosting those websites. This approach to prefetching is problematic because it allows the prefetched websites to learn something new about you, such as your interest in some content or product. In practice, as we have said earlier, this heavily limits the usage of prefetching to a small number of cases where prefetching a page doesn’t reveal new information to its publisher.


“Naively prefetching websites can result in leaking user’s interest in some content or product”



In essence, the challenge here is to find an approach which upholds the following privacy principle: “None of the parties involved can learn anything new about the user as a result of prefetching a website”. For the experiment, we’ve addressed this challenge by having Chrome use a “private prefetch proxy” which consists of a CONNECT proxy, a set of rules governing its usage, and additional measures to ensure that the prefetches can not be personalized to the user.


Private prefetch proxy
At a high level, Chrome gives the name of a website to the CONNECT proxy which then creates a secure communication channel between Chrome and that website. By design, the proxy was operated for and by Google, and was restricted to navigations originating from Google owned surfaces, thereby ensuring that the proxy could only see information that’s already accessible such as the names of the websites prefetched from surfaces that we authored. The end-to-end encrypted communication channel provided by the CONNECT proxy means that the proxy is only able to relay further requests without being able to see the content of the communication. Furthermore, given that the content of the communication is encrypted end-to-end between Chrome and the destination site, it also means that intermediaries can’t see the prefetched domains, nor the content of the prefetched resources. Likewise, since the proxy is relaying the prefetching requests, the destination website only sees the IP address of the proxy, not the user’s IP address. Finally, prefetching was restricted to websites that had no cookies or other local state, thereby preventing the destination site from identifying a user via information previously stored on their device.


“Prefetching websites via a CONNECT proxy prevents leaking user information”




Rebuilding pre-rendering on a solid foundationAs mentioned in the introduction, our goal is to bring instant experiences to the whole web through prefetching and pre-rendering techniques that are privacy and developer friendly. This proof of concept experiment and the follow-up discussions with the community represent small, but nevertheless important, steps toward that goal. Indeed, any pre-rendering feature is inherently built on top of a prefetching capability, which must abide by the same privacy principles. There are a few more challenges that we’ll need to solve to bring back an improved, privacy and developer friendly, pre-rendering feature. To be clear, we see this successful proof of concept experiment as a positive signal for iterating on a viable web platform solution, so that more websites can both benefit from, and take advantage of the approach outlined in this blog post. We are hopeful that what we’ve learned from past efforts, as well as new learnings we’ve gained thanks to this proof-of-concept experiment, will help foster a fruitful collaborative effort with the rest of the community.


Posted by Michael Buettner (Software Engineer), and Kenji Baheux (Product Manager)







Labels: ,

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.

Digital Goods API

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.

Origin Trials

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.

New Origin Trials

WebXR: AR Lighting 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 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.

Completed Origin Trials

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

performance.measureMemory() Method

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().

PointerLock unadjustedMovement

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.

Other features in this release

Anchor target=_blank implies rel=noopener by Default

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.

Dark Mode Form Controls and Scrollbars

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.

AbortSignal in addEventListener()

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().

CSS aspect-ratio Property

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.

CSS Selectors 4: Complex :not()

Allows complex selectors inside the :not() pseudo class, such as :not(.a + .b .c).

Don't Clear adoptedStyleSheets on Adoption to/from <template>

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.

ElementInternals.shadowRoot Attribute

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.

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.

Make Type Optional in WakeLock.request()

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.

Origin Isolation

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.

path() Support in clip-path CSS Property

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')

Permissions-Policy Header

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.

RTCRtpTransceiver.stop()

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.

JavaScript

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.

Shared Array Buffers, Atomics, and Futex APIs

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.

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.

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.

Don't Allow Popups During Page Unload (Enterprises)

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.

FTP Support Removed

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 Removed

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.

Labels:

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. 


Simplifying privacy practices for our users

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. 

Updating our user data privacy policy

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. 


Developer-provided privacy disclosures

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
Labels: , ,

Even if you have a lot of tabs open, you likely only focus on a small set of them to get a task done. Starting in this release, Chrome is actively managing your computer’s resources to make the tabs you care about fast—while allowing you to keep hundreds of tabs open—so you can pick up where you left off.

In this release, we’re improving how Chrome understands and manages resources with Tab throttling, occlusion tracking and back/forward caching, so you can quickly get to what you need when you need it.



Tab throttling and Occlusion Tracking
Knowing what tabs you’re using helps Chrome manage your computer’s resources more efficiently to get things done. We’ve made significant improvements by preventing background tabs from waking up your CPU too often, and no longer rendering tabs that you can’t see.

We investigated how background tabs use system resources and found that JavaScript Timers represent >40% of the work in background tabs. Reducing their impact on CPU and power is important to make the browser more efficient. Beginning in M87, we’re throttling JavaScript timer wake-ups in background tabs to once per minute. This reduces CPU usage by up to 5x, and extends battery life up to 1.25 hours in our internal testing. We’ve done this without sacrificing the background features that users care about, like playing music and getting notifications.

Next, we’re bringing Occlusion Tracking--which was previously added to Chrome OS and Mac--to Windows, which allows Chrome to know which windows and tabs are actually visible to you. With this information, Chrome can optimize resources for the tabs you are using, not the ones you’ve minimized, making Chrome up to 25% faster to start up and 7% faster to load pages, all while using less memory.

These updates will be gradually rolling out in M87 and our next release, M88. 



Back/forward cache
How many times have you visited a website and clicked a link to go to another page, only to realize it's not what you wanted and click the back button? On mobile devices, this happens a lot: 1 in 5 navigations are a back/forward navigation. This is where a back/forward cache shines! It’s a browser optimization which enables instant back and forward navigations. In Chrome 87, our back/forward cache will make 20% of those back/forward navigations instant, with plans to increase this to 50% through further improvements and developer outreach in the near future. Here is how it works:
 


Back/forward cache is one of our long wished-for feature requests in Chrome and now with Chrome 87 we will gradually launch it to Chrome for Android users. Head over to this technical article to learn more about how we added back/forward cache within Chrome's multi-process architecture and if you're a web developer, learn how to make the most of the back/forward cache on your website.

Posted by Mark Chang, Chrome Product Manager



Data source: Real world data anonymously aggregated from Chrome pre-stable channels.

Although notifications on the web are useful for a variety of applications, they can also be misused for phishing, malware or fake messages that imitate system notifications for the purpose of generating user interactions.  


In Chrome 86, we’ve expanded on previous efforts [1] [2] to improve the quality of the web notification ecosystem by adding enforcement for websites sending abusive notification content. This includes sites sending messages containing links to malware or that seek to spoof system administrative messages. 


When abusive notification content is detected on an origin, Chrome will automatically display the permission requests using a quieter UI, shown below.  

How is this different from previous abusive notification protections?

Chrome 80 introduced the quiet Notification permission UI. Chrome 84 announced auto-enrolment in quiet notification UI for websites with abusive notification permission requests, such as sites that use deceptive patterns to request notification permission. 


The new enforcement in Chrome 86 focuses on notification content and is triggered by sites that have a history of sending messages containing abusive content. This treatment applies to sites that try to trick users into accepting the notification permission for malicious purposes, for example sites that use web notifications to send malware or to mimic system messages to obtain user login credentials.  

What does it look like?

Desktop UI for quiet notifications UI on abusive websites. The new UI discourages users from allowing notifications from these websites.  




Mobile UI for quiet notifications on abusive websites.  The new UI discourages users from allowing notifications from these websites.  


This UI exactly matches the UI that was previously announced for Chrome 84. The only difference is in Chrome 86 we will begin blocking notification permission requests when sites have a pattern of sending abusive notification content.  

Why are we doing this?

Abusive notification prompts are one of the top user complaints we receive about Chrome. Our goal with these changes is to improve the experience for Chrome users and to reduce the incentive for abusive sites to misuse the web notifications feature.  

How will Chrome detect sites sending abusive notification content?  

Google’s automated web crawling service will occasionally subscribe to website push notifications if the push permission is requested. Notifications that are sent to the automated Chrome instances, using Safe Browsing technology, will be evaluated for abusive content, and sites sending abusive notifications will be flagged for enforcement if the issue is unresolved. 

What happens if abusive notifications are detected from my website?

When a site is found to be in “Failing” status for any type of notification abuse, Search Console will send an email to registered site owners and users in the site's Search Console at least 30 calendar days prior to the start of enforcement. During the 30 day grace period websites can address the issue and request another review.  


We recommend concerned site owners and developers review the Abusive Notifications Report in Search Console. The Search Console help center has additional information on the Abusive Notifications Report and the abusive notification review process.

What should I do if my website failed the abusive notification review? 

The Search Console help center has a guide for how to fix abusive notifications and request another review of your website.  

Are any further abusive notification protections planned?   

Prior to the release of Chrome’s abusive notifications protections, many users have already unintentionally allowed notifications from websites engaging in abusive activity.  In an upcoming release, Chrome will revert the notification permission status from “granted” to “default” for abusive origins, preventing further notifications unless the user returns to the abusive origin and re-enables notifications.  


We’ll be listening for feedback from users and developers about the effectiveness of current enforcements and may make further changes based on that feedback.


Posted by PJ McLachlan, Product Manager
Labels:

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 87 is beta as of October 15, 2020.

WebAuthn Tab in DevTools

Testing web authentication has long been difficult because developers need devices to test their code. Starting in Chrome 87, authentication can be emulated and debugged using a new panel in DevTools. You can find the panel in DevTools by selecting More options, then More tools, then WebAuthn. To learn how to use it, see the section in What's New in DevTools (Chrome 87).

Control camera pan, tilt, and zoom

Room-scale video conferencing solutions deploy cameras with pan, tilt, and zoom capabilities so that software can point the camera at meeting participants. Starting in Chrome 87, the pan, tilt, and zoom features on cameras are accessible to websites using media track constraints in MediaDevices.getUserMedia() and MediaStreamTrack.applyConstraints().

Websites are only allowed to control these capabilities when users explicitly grant permission. For details on using the new capabilities and a demo, see Control camera pan, tilt, and zoom.

CSS flow-relative shorthand and offset properties

The trend in CSS for many years has been to supplement physical properties with logical properties. Properties that assume language flows left to right and top to bottom don't work in non-European text such as vertical Chinese text, or Arabic. Modern CSS rules use flow-relative terms like start and end and provide rules for dealing with the text's axis (direction).

The first step in implementing this in Chrome was to implement the most granular flow-relative features of the CSS Logical Properties and Values spec. Chrome 87 ships shorthands and
offsets to make these logical properties and values a bit easier to write. What was once written with multiple CSS rules can now be written as one. For example, separate rules for margin-block-start and margin-block-end may now be written using a single margin-block property.

For a list of all flow-relative shorthands now supported by Chrome, and explanations for how to use them, see Logical layout enhancements with flow-relative shorthands. For more CSS-related updates, see the CSS section, below.

Completed Origin Trials

Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. The following feature, previously in a Chrome origin trial, is now enabled by default.

Cookie Store API

The Cookie Store API exposes HTTP cookies to service workers and offers an asynchronous alternative to document.cookie.

Other features in this release

cross-origin isolation

Chrome 87 has a number of changes related to cross-origin isolation. Chrome will now use origin instead of site as agent cluster key for cross-origin isolated agent clusters. Mutation of document.domain is no longer supported for cross-origin isolated agent clusters. This change also introduces window.crossOriginIsolated, a boolean that indicates whether APIs that require cross-origin isolation are allowed to use it. Supporting APIs include:

For more information, see Making your website "cross-origin isolated" using COOP and COEP.

iframe attribute for limiting same-origin iframe document access

Adds the disallowdocumentaccess property to disallow cross-document scripting between iframes from the same origin in the same parent document. This also puts same-origin iframes in separate event loops.

Note: This item was pulled from Chrome 87 beta and was not in later builds.

isInputPending()

Sometimes long-running scripts block user input. A lag between a user's action and a response by an app is a bad user experience. To address this, Chrome has added a method called isInputPending(), accessible from navigator.scheduling, which can be called from long-running operations. You can find an example of the method's use in the draft spec.

Range Request Headers in Service Workers

HTTP range requests, which have been available in major browsers for several years, allow servers to send requested data to the client in chunks. This has proved especially useful for large media files where the user experience is improved through smoother playback and improved pause and resume functions.

Historically, range requests and services workers did not work well together, forcing developers to build work-arounds. Starting in Chrome 87, passing range requests through to the network from inside a service worker will "just work."

For an explanation of the issues with range requests and what's changed in Chrome 87, see Handling range requests in a service worker.

Streams API: transferable streams

Transferable streams now allows ReadableStream, WritableStream, and TransformStream objects to be passed as arguments to postMessage(). The streams APIs provide ubiquitous, interoperable primitives for creating, composing, and consuming streams of data. A natural thing to do with a stream is to pass it to a web worker. This provides a fluent primitive for offloading work to another thread.

Offloading work onto a worker is important for a smooth user experience, but the ergonomics can be awkward. Transferable streams solve this problem for streams. Once the stream itself has been transferred, the data is transparently cloned in the background.

Transition related event handlers

The ontransitionrun, ontransitionstart, and ontransitioncancel event handler attributes allow developers to add event listeners for 'transitionrun', 'transitionstart', and 'transitioncancel' events on elements, Document objects, and Window objects.

WakeLockSentinel.released Attribute

The WakeLockSentinel object has a new property called released that indicates whether a sentinel has already been released. It defaults to false and changes to true when a release event is dispatched. The new attribute helps web developers know when locks are released so that they do not need to keep track of them manually.

CSS

@font-face descriptors to override font metrics

New @font-face descriptors have been added to ascent-override, descent-override, and line-gap-override to override metrics of the font. This Improves interoperably across browsers and operating systems, so that the same font always looks the same on the same site, regardless of OS or browser. Additionally, it aligns metrics between two web fonts present simultaneously, but for different glyphs. Finally, it overrides font metrics for a fallback font to emulate a web font, to minimize cumulative layout shift.

Text Decoration and Underline Properties

Chrome now supports several new text decoration and underline properties. These properties solve use cases where underlines are too close to the text baseline and ink-skipping triggers too early in a text run. These use cases solve problems caused by the launch of the text-decoration-skip-ink property. The new properties are text-decoration-thickness, text-underline-offset and a from-font keyword for text-underline-position.

The quotes Property Supports the 'auto' Value

CSS2 allowed browsers to define the default value for the quotes property, which Chrome formerly followed. Chrome 87 now follows CSS Generated Content Module Level 3 in which the 'auto' keyword is the default value. That spec requires that a typographically appropriate value be used for quotes based on the content language of the element and/or its parent.

JavaScript

This version of Chrome incorporates version 8.7 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.

Atomics.waitAsync()

Chrome now supports Atomics.waitAsync(), the async version of Atomics.wait(). Atomics.waitAsync() allows programmers to wait on a SharedArrayBuffer location in the same fashion as Atomics.wait() but returns a Promise instead.

Atomics.wait() blocks the thread and cannot be used on the main web browser thread, where blocking is disallowed. This makes coordination via SharedArrayBuffers between the main thread and worker threads more ergonomic.

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.

Comma separator in iframe allow attribute

Permissions policy declarations in an <iframe> tag can no longer use commas as a separator between items. Developers should use semicolons instead.

-webkit-font-size-delta

Blink will no longer support the rarely-used -webkit-font-size-delta property. Developers should use font-size to control font size instead.

Deprecate FTP support

Chrome is deprecating and removing support for FTP URLs. The current FTP implementation in Google 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. Currently 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. In Chrome 86, FTP was turned off for pre-release channels (Canary and Beta) and was experimentally turned off for one percent of stable users.

The remaining capabilities of Google Chrome's FTP implementation are restricted to either displaying a directory listing or downloading a resource over unencrypted connections.

Remainder of the deprecation follows this timeline:

Chrome 87

FTP support will be disabled by default for fifty percent of users but can be enabled using the flags listed above.

Chrome 88

FTP support will be disabled.

Labels: