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.
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.
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.
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.
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:
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."
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 ontransitioncancelevent 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.
QUIC is a new networking transport protocol that combines the features of TCP, TLS, and more. HTTP/3 is the latest version of HTTP, the protocol that carries the vast majority of Web traffic. HTTP/3 only runs over QUIC.
QUIC was initially developed by Google and first announced in 2013. Since then, the protocol has matured, and is now responsible for carrying over a third of Google traffic. In 2015, Google brought QUIC to the IETF (the standards organization responsible for maintaining the Internet's protocols) and the IETF has been improving QUIC by making many changes to it. At this point, there are now two similar but different protocols: Google QUIC and IETF QUIC. The QUIC team at Google has been involved in the IETF process from the start, but we've been using Google QUIC in Chrome while working on implementing IETF QUIC. We've put tremendous effort into evolving Google QUIC over the last five years to track changes at IETF, and the current latest Google QUIC version (Q050) has many similarities with IETF QUIC. But up until now, the majority of Chrome users didn't communicate with IETF QUIC servers without enabling some command-line options.
Today this changes. We've found that IETF QUIC significantly outperforms HTTP over TLS 1.3 over TCP. In particular, Google search latency decreases by over 2%. YouTube rebuffer time decreased by over 9%, while client throughput increased by over 3% on desktop and over 7% on mobile. We're happy to announce that Chrome is rolling out support for IETF QUIC (specifically, draft version h3-29). Today 25% of Chrome Stable users are using h3-29, and we plan on increasing that number over the coming weeks as we continue to monitor performance data. Chrome will actively support both IETF QUIC h3-29 and Google QUIC Q050 to provide servers that support Q050 with time to update to IETF QUIC.
Chrome m85 doesn't yet support IETF QUIC 0-RTT, so we expect these performance numbers to look even better once we launch 0-RTT support for IETF QUIC in the coming months.
Since the subsequent IETF drafts 30 and 31 do not have compatibility-breaking changes, we currently are not planning to change the over-the-wire identifier. What this means is that while we'll keep tracking changes in the IETF specification, we will be deploying them under the h3-29/0xff00001d name. We therefore recommend that servers keep support for h3-29 until the final RFCs are complete if they wish to interoperate with Chrome. However, if the IETF were to make compatibility-breaking changes in a future draft, Chrome will revisit this decision.
The authors would like to thank the entire QUIC team at Google for all their hard work leading up to this announcement. We're incredibly proud of what we've achieved together. We would also like to thank everyone who has contributed to QUIC at the IETF, and all of the former members of the QUIC team at Google, without whom none of this would have been possible.
Last year we announced a new initiative (known as Privacy Sandbox) to develop a set of open standards to fundamentally enhance privacy on the web. With Privacy Sandbox we’ve been exploring privacy-preserving mechanisms with the web community that protect user data and prevent intrusive cross-site tracking. Our aim is to preserve the vitality of the open web by continuing to enable the rich, quality content and services that people expect, but with even stronger guarantees of privacy and safety. Today we’re sharing progress on this long-term initiative and asking for your continued help in increasing the privacy of web browsing.
In January we shared our intent to develop privacy-preserving open-standards that will render third-party cookies obsolete. Since then, Google and others have proposed several new APIs to address use cases like fraud protection, ad selection, and conversion measurement without allowing users’ activity to be tracked across websites. Following web community input, some of these solutions are now available for experimental testing via Chrome origin trials:
Click Conversion Measurement API opened up for testing in September and aims to enable marketers to know whether an ad click resulted in a conversion (for example, a purchase or a sign-up) on another site, without connecting the identity of the user across both sites.
Trust Tokens opened up for testing in July and is intended to support a number of use cases evaluating a user’s authenticity, including combating fraud.
If you integrate APIs into your products and services, you can register for access to these and other APIs through Chrome origin trials. We encourage ecosystem stakeholders to participate and share their feedback and results. Developing and implementing web standards which change the core architecture of the web is a complex process, so we are taking a long-term, collaborative approach.
We’re also continuing our work to make current web technologies more secure and private.
Earlier this year Chrome started limiting cross-site tracking by treating cookies that don’t include a SameSite label as first-party only, and requiring cookies to be labeled and accessed over HTTPS in order to be available in third-party contexts. With this update — which Edge and Firefox are in the process of adopting — third-party cookies are no longer sent for the 99.9% of registered domains that do not require them, improving privacy and security for the vast majority of sites on the web.
In a release early next year, Chrome will also strengthen protection against additional types of network attacks that could hijack the users’ privileged credentials to perform malicious actions on their accounts.
We’re also rolling out changes in Chrome to mitigate deceptive and intrusive tracking techniques, such as fingerprinting.
In September we rolled out an update to prevent inadvertent sharing of information such as users' names and access tokens. When users navigate from one site to another we are reducing the information from the originating page’s URL that is sent to the destination site by default.
Also in September, we extended support of Secure DNS in Chrome beyond desktop to Android. Secure DNS is designed to improve user safety and privacy while browsing the web by automatically switching to DNS-over-HTTPS if the user's current provider supports it.
Coming soon, we’re also closing the ability for a site to observe other sites that a user might have visited through caching mechanisms.
As always, we encourage you to give feedback on the web standards community proposals via GitHub and make sure they address your needs. And if they don’t, file issues through GitHub or email the W3C group. If you rely on the web for your business, please ensure your technology vendors engage in this process and that the trade groups who represent your interests are actively engaged.
We are appreciative of the continued engagement as we build a more trustworthy and sustainable web together. We will continue to keep everyone posted on the progress of efforts to increase the privacy of web browsing.
Posted by Justin Schuh - Director, Chrome Engineering