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.
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.
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.
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.
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.
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.
The Search Console help center has a guide for how to fix abusive notifications and request another review of your website.
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.
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.
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).
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().
MediaDevices.getUserMedia()
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.
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.
margin-block-start
margin-block-end
margin-block
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.
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.
The Cookie Store API exposes HTTP cookies to service workers and offers an asynchronous alternative to document.cookie.
document.cookie
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:
document.domain
window.crossOriginIsolated
SharedArrayBuffer
performance.measureMemory()
For more information, see Making your website "cross-origin isolated" using COOP and COEP.
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.
disallowdocumentaccess
Note: This item was pulled from Chrome 87 beta and was not in later builds.
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.
isInputPending()
navigator.scheduling
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.
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.
ReadableStream
WritableStream
TransformStream
postMessage()
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.
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.
ontransitionrun
ontransitionstart
ontransitioncancel
'transitionrun'
'transitionstart'
'transitioncancel'
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.
WakeLockSentinel
released
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.
@font-face
ascent-override
descent-override
line-gap-override
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.
text-decoration-skip-ink
text-decoration-thickness
text-underline-offset
from-font
text-underline-position
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.
'auto'
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.
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.waitAsync()
Atomics.wait()
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.
SharedArrayBuffers
This version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.
Permissions policy declarations in an <iframe> tag can no longer use commas as a separator between items. Developers should use semicolons instead.
<iframe>
Blink will no longer support the rarely-used -webkit-font-size-delta property. Developers should use font-size to control font size instead.
-webkit-font-size-delta
font-size
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:
FTP support will be disabled by default for fifty percent of users but can be enabled using the flags listed above.
FTP support will be disabled.
