Chrome 81 adds two new immersive features to the web, both designed to support augmented reality. The WebXR Device API, first enabled in Chrome 79, now supports augmented reality. We've also added support for the WebXR Hit Test API, an API for placing objects in a real-world view.

If you've already used the new API to create virtual reality, you'll be happy to know there's very little new to learn to use AR. This is because the spec was designed with the spectrum of immersive experiences in mind. Regardless of the degree of augmentation or virtualization, the application flow is the same. The differences are merely a matter of setting and requesting different properties during object creation.

The WebXR Hit Test API provides a means for an immersive experience to interact with the real world. Specifically, it enables you to place virtual objects on real-world points in a camera view. The image below from one of the Immersive Web Working Group's sample apps illustrates this. The broken blue circle indicates a point returned from the hit test API. If I tap the screen a sunflower will be placed there. The new API captures both the location of a hit test and the orientation of the point that was detected. You'll notice in the image a sunflower has been placed on both the floor and the wall.

If you're completely new to the WebXR Device API, check out our earlier articles, Virtual reality comes to the web and Virtual reality comes to the web, part II. If you're already familiar with entering a WebXR session and constructing a frame loop, then check out our new article on Web AR. Also check out our article on the WebXR Hit Test API.

Origin Trials

This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

PointerLock unadjustedMovement

Scripts now have the ability to request unadjusted and unaccelerated mouse movement data when in PointerLock. If unadjustedMovement is set to true, then pointer movements will not be affected by the underlying platform modifications such as mouse acceleration.

Other features in this release

Buffered Flag for Long Tasks

Chrome 81 updates the buffered flag of PerformanceObserver to support long tasks. In particular, this feature provides a way to gain insight into early long tasks for apps or pages that register a PerformanceObserver early.

CSS image-orientation property

Chrome will by default respect EXIF metadata within images indicating desired orientation. The accompanying image-orientation property allows developers to override this behavior.

CSS Color Adjust: color-scheme

A new meta tag and CSS property lets sites opt-in to following the preferred color scheme when rendering UI elements such as default colors of form controls and scrollbars as well as the used values of the CSS system colors. For Chrome 81 only initial color and background are affected.

Exclude Implicit Tracks from grid-template-rows and grid-template-columns Resolved Values

Implicit tracks are now excluded from the resolved values of the grid-template-rows and grid-template-columns. Previously, all tracks were included, whether implicit or explicit.

Note: This was mistakenly included though it did not actually ship.

hrefTranslate attribute on HTMLAnchorElement

The HTMLAnchorElement now has an hrefTranslate attribute, providing the ability for a page to hint to a user agent's translation engine that the destination site of an href should be translated if followed.

IntersectionObserver Document Root

The IntersectionObserver() constructor now takes a Document as the 'root' argument, causing intersections to be calculated against the scrolling viewport of the document. This is primarily targeted towards observers running in an iframe. Previously, there was no way to measure intersection with the scrolling viewport of the iframe's document.

Modernized Form Controls

In version 81, Chrome modernizes the appearance of form controls on Windows, ChromeOS, and Linux while improving their accessibility and touch support. (Mac and Android support are coming soon.) It's hoped that this will reduce the need to build custom form controls. This change is the result of collaboration between Microsoft and Google. For more information, see the recent talk at CDS or the MS blog post. For a closer look at the controls, this page gives an example of all of the elements that changed.

Move onwebkit{animation,transition}XX handlers to GlobalEventHandlers

Until now, the prefixed onwebkit{animation,transition}XX handlers were only available on the Window object in Chrome. They are now on HTMLElement and Document as required by the spec. This fix brings Chrome in line with Gecko and Webkit.

Note: This change is intended to improve interoperability on existing web pages. These handlers are still obsolete so web developers should use the non-refixed versions on new pages.

Position State for Media Session

Adds support for tracking position state in a media session. The position state is a combination of the playback rate, duration, and current playback time. This can then be used by browsers to display position in the UI and with the addition of seeking can support seeking/scrubbing too. For a code sample and demonstration, see our sample.

SubmitEvent

Chrome now supports a SubmitEvent type, an Event subtype which is dispatched on form submission. The SubmitEvent has a submitter property that refers to attributes of the submitter button including the entry data, the formaction attribute, the formenctype attribute, the formmethod attribute, and the formtarget attribute.

Currently, applications are doing their own form submission by calling preventDefault() during onsubmit. This approach has the limitation that the received event does not include the button that triggered the submission.

WebAudio: ConvolverNode.channelCount and channelCountMode

For a ConvolverNode, the channelCount can now be set to 1 or 2. The channelCountMode can be "explicit" or "clamped-max". Previously, a channelCount of 1 was not allowed and neither was a mode of "explicit".

This release also extends ConvolverNode capabilities slightly to allow developers to choose the desired behavior without having to add a GainNode to do the desired mixing.

WebRTC

RTCPeerConnection.onicecandidateerror event changes

The candidateerror event now has an explicit address and port, replacing hostCandidate.

onclosing Event for RTCDataChannel

Adds the onclosing event to the RTCDataChannel object, which signals to the user of a data channel that the other side has started closing the channel. The user agent will continue reading from the queue (if it contains anything) until the queue is empty, but no more data can be sent.

WorkerOptions for shared workers constructor

Adds the WorkerOptions object as the second argument for a shared worker constructor. The previous second argument, a string containing the worker's name is still supported.

WritableStream.close()

WritableStream objects now have a close() method that closes a stream if it is unlocked. This is directly equivalent to getting a writer, using the writer to close the stream, and then unlocking it again.

JavaScript

This version of Chrome incorporates version 8.1 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent changes in the V8 release notes.

Intl.DisplayNames()

The Intl.DisplayNames() object lets an app or script get localized names of language, script, currency codes, and commonly used names of date fields and symbols. This will reduce the size of apps (thereby improving latency), make it easier to build internationalized UI components, reduce translation costs, and provide more consistent translations across the web.

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.

Deprecation and Remove "basic-card" support Payment Handler

This version of Chrome removes the basic-card polyfill for Payment Request API in iOS Chrome. As a result, the Payment Request API is temporarily disabled in iOS Chrome. For full details, see Rethinking Payment Request for iOS.

Remove supportedType field from BasicCardRequest

Specifying "supportedTypes":[type] parameter for "basic-card" payment method shows cards of only the requested type, which is one of "credit", "debit", or "prepaid".

The card type parameter has been removed from the spec and is now removed from Chrome, because of the difficulty of accurate card type determination. Merchants today must check card type with their PSP, because they cannot trust the card type filter in the browser:

  • Only issuing banks know the card type with certainty and downloadable card type databases have low accuracy, so it's impossible to know accurately the type of the cards stored locally in the browser.
  • The "basic-card" payment method in Chrome no longer shows cards from Google Pay, which may have connections with issuing banks.

Firefox removed "supportedTypes" in version 65.

Remove the <discard> element

Chrome 81 removes the <discard> element. It is only implemented in Chromium, and is thus not possible to use interoperably. For most use cases it can be replaced with a combination of animation of the 'display' property and a removal (JavaScript) callback/event handler.

Remove TLS 1.0 and TLS 1.1

Note: Removal of TLS 1.0 and TLS 1.1 has been delayed to Chrome 83, which is expected to ship in late May 2020.

This version of Chrome removes TLS 1.0 and TLS 1.1. TLS (Transport Layer Security) is the protocol which secures HTTPS. It has a long history stretching back to the nearly twenty-year-old TLS 1.0 and its even older predecessor, SSL. Both TLS 1.0 and 1.1 have a number of weaknesses.
  • TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the transcript hash for the Finished message.
  • TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature. (Note: this is not the signature in the certificate.)
  • TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken and has since been removed. TLS's CBC mode construction is flawed and was vulnerable to attacks.
  • TLS 1.0's CBC ciphers additionally construct their initialization vectors incorrectly.
  • TLS 1.0 is no longer PCI-DSS compliant.
Supporting TLS 1.2 is a prerequisite to avoiding the above problems. The TLS working group has deprecated TLS 1.0 and 1.1. Chrome deprecated these features in version 72 in early 2019.

TLS 1.3 downgrade hardening bypass

TLS 1.3 includes a backwards-compatible hardening measure to strengthen downgrade protections. However, when we shipped TLS 1.3 last year, we had to partially disable this measure due to incompatibilities with some non-compliant TLS-terminating proxies. Chrome currently implements the hardening measure for certificates which chain up to known roots, but allows a bypass for certificates chaining up to unknown roots. We intend to enable it for all connections.

Downgrade protection mitigates the security impact of the various legacy options we retain for compatibility. This means user's connections are more secure and, when security vulnerabilities are discovered, it is less of a scramble to respond to them. (That, in turn, means fewer broken sites for users down the road.) This also aligns with RFC 8446.
Labels:


We plan to roll out restrictions on mixed content downloads on desktop platforms (Windows, macOS, Chrome OS and Linux) first. Our plan for desktop platforms is as follows:



  • In Chrome 81 (released March 2020) and later:
    • Chrome will print a console message warning about all mixed content downloads.
  • In Chrome 84 (released July 2020):
    • Chrome will warn on mixed content downloads of executables (e.g. .exe).
  • In Chrome 85 (released August 2020):
    • Chrome will block mixed content executables.
    • Chrome will warn on mixed content archives (.zip) and disk images (.iso).
  • In Chrome 86 (released October 2020):
    • Chrome will block mixed content executables, archives and disk images.
    • Chrome will warn on all other mixed content downloads except image, audio, video and text formats.
  • In Chrome 87 (released November 2020):
    • Chrome will warn on mixed content downloads of images, audio, video, and text.
    • Chrome will block all other mixed content downloads.
  • In Chrome 88 (released January 2021) and beyond, Chrome will block all mixed content downloads.



Example of a potential warning



Chrome will delay the rollout for Android and iOS users by one release, starting warnings in Chrome 85. Mobile platforms have better native protection against malicious files, and this delay will give developers a head-start towards updating their sites before impacting mobile users. 

Developers can prevent users from ever seeing a download warning by ensuring that downloads only use HTTPS. In the current version of Chrome Canary, or in Chrome 81 once released, developers can activate a warning on all mixed content downloads for testing by enabling the "Treat risky downloads over insecure connections as active mixed content" flag at chrome://flags/#treat-unsafe-downloads-as-active-content. 

Enterprise and education customers can disable blocking on a per-site basis via the existing InsecureContentAllowedForUrls policy by adding a pattern matching the page requesting the download. 

In the future, we expect to further restrict insecure downloads in Chrome. We encourage developers to fully migrate to HTTPS to avoid future restrictions and fully protect their users. Developers with questions are welcome to email us at [email protected]. 

Posted by Joe DeBlasio, Chrome Security team


In order to determine which ads are the most intrusive to web experience, we rely on the Better Ads Standards which give companies like Google guidance based on feedback from people around the world. 
Today, the group responsible for developing the Better Ads Standards, the Coalition for Better Ads, announced a new set of standards for ads that show during video content, based on research from 45,000 consumers worldwide. 
There are many different types of ads that can run before, during, or after a video but according to the Coalition’s research, there are three ad experiences that people find to be particularly disruptive on video content that is less than 8 minutes long: 

Image Source: Coalition for Better Ads


Long, non-skippable pre-roll ads or groups of ads longer than 31 seconds that appear before a video and that cannot be skipped within the first 5 seconds.

Image Source: Coalition for Better Ads


Mid-roll ads of any duration that appear in the middle of a video, interrupting the user’s experience.


Image Source: Coalition for Better Ads


Image or text ads that appear on top of a playing video and are in the middle 1/3 of the video player window or cover more than 20 percent of the video content.

Does this affect my video content? 
The Coalition has announced that website owners should stop showing these ads to their site visitors in the next four months. Following the Coalition’s lead, beginning August 5, 2020, Chrome will expand its user protections and stop showing all ads on sites in any country that repeatedly show these disruptive ads. It’s important to note that YouTube.com, like other websites with video content, will be reviewed for compliance with the Standards. Similar to the previous Better Ads Standards, we’ll update our product plans across our ad platforms, including YouTube, as a result of this standard, and leverage the research as a tool to help guide product development in the future.
If you operate a website that shows ads, you should consider reviewing your site status in the Ad Experience Report, a tool that helps publishers to understand if Chrome has identified any violating ad experiences on your site. Starting this week, we’ll update the Ad Experience Report with information to help publishers resolve any issues with these new video standards currently on their site. For more information about this process, you can reference the Help Center and Community Forum.


Posted by Jason James, Product Manager
Labels: , ,




Launch Timing: The stable release of Chrome 80 is scheduled to begin on February 4. Enforcement of the new cookie classification system in Chrome 80 will begin later in February with a small population of users, gradually increasing over time. To get the latest information about the rollout timing and process,  monitor the SameSite Updates page. To see if your browser has been updated, you can visit this page; if all the rows are green then your browser is applying the new defaults.


Developer Tools Console Warnings: The Developer Tools console provides warnings when a page contains cross-site cookies that are missing the required settings.  If you see these warnings while viewing your site in Developer Tools, that could mean cookies which support features on your site are not properly configured. Here is a Developer Tools warning in Chrome 80; earlier versions of Chrome (77+) provide a similar one:


An exception is the case where a service issues a pair of redundant cookies: One cookie with the new settings, and one cookie with the legacy settings for incompatible clients. In that case, you may see a warning triggered by the legacy cookie even though the service is working as intended. This approach is described here.


Google Cookies: Some Google services will use the approach described above, issuing a cookie with the new settings and a cookie with legacy settings. For this reason, you might see the Developer Tools console warning for Google cookies even though the Google service is working as intended.


Temporary Transition Effects: If a cross-site cookie provider updates its cookies immediately before the Chrome 80 release, some known or returning users with Chrome 80 may temporarily appear as unknown or new users until their cookies are refreshed with the new settings. Providers who updated their cookies farther in advance are less likely to notice an impact because their users had a longer window of time to pick up cookies with the new settings.


Temporary Mitigation for Sign-On Flows: To help avoid broken user sign-on experiences when cookies are passed between websites and third-party providers during the authentication process, Chrome introduced a temporary mitigation known as “Lax + POST” so that, within a two-minute window, cookies without specified SameSite settings can be available for the type of top-level cross-site POST request typically used in sign-on flows. (This does not change behavior for top-level cross-site GET requests, which will attach “Lax” but not “Strict” SameSite cookies.) This mitigation is described in the Chromium tracker for the new model. If you use or provide third party sign-on services we strongly recommend testing your sign-on flow immediately.


Enterprise Policies: Enterprise administrators may need to implement special policies to temporarily revert Chrome Browser to legacy behavior if some services such as sign-on or internal applications are not ready for the Chrome 80 changes.


Testing and Troubleshooting: To see how a site or service will behave under the new model, we strongly recommend testing in Chrome 76+ with the “SameSite by default cookies” and “Cookies without SameSite must be secure” experimental flags enabled.  (To enable flags to go chrome://flags.)  Since the new model will roll out to Chrome 80 gradually, when testing, you should also enable the flags in Chrome 80 to make sure your browser reflects the new default settings.


You can also test whether any unexpected behavior you’re experiencing in Chrome 80 is attributable to the new model by disabling the “SameSite by default cookies” and “Cookies without SameSite must be secure” flags.  If the issue persists with the flags disabled, then the cookie changes are probably not the cause of the issue.  You can find more testing and debugging tips here.

More Resources:


Posted by Barb Smith, Chrome and Web Platform Partnerships