Earlier this month, Chrome 104 arrived to the Stable channel with an updated Web Bluetooth API that faced a lot of criticism from both Apple and Mozilla for exposing fingerprinting surfaces that could be used to invade the privacy of Chrome users. Today, Chrome 105 is landing and while it's not as controversial as the previous version, Apple has some concerns with this release too.
.jpg)
Chrome 105 packs a lot of changes on the backend. One of those is User Agent Client Hints which is an API that exposes information about device activity and conditions so that developers can make their webpages respond to various hardware dynamically. With the release of Chrome 100 back in March, Google cautioned web developers that they had until March 2023 to migrate to this Client Hints API instead of depending on user-agent strings.
As such, the criticism of the Clients Hints API is not new but Chrome 105 makes some changes to it where developers can request information about the height of the browser window displaying the content. Previously, this API only exposed width information of the viewport, but Google believes that fetching the height would be useful as well to make sure that height-constrained images on webpages display properly. The syntax for Client Hints delegation is being changed too, in response to developer feedback.
Google has highlighted a thread dating back to 2020 where Apple's WebKit team has cited concerns with the Client Hints API being used to fingerprint users. Excerpts from the thread are attached below:
I may be misreading the spec, but as written getHighEntropyValues seems to give access to all of the high entropy client hints to third-party scripts in the first party context, and scripts running in third-party iframes, regardless of which ones the site has opted into via the relevant HTTP header.
[...] We’re currently deeply skeptical of implementing any of the other client hints due to their expansion of fingerprinting surface, so I don’t feel particularly compelled by that precedent. That said, it’s likely the other client hints have this same problem, where they expose fingerprinting surface way more widely than they may be intending to. That would be a huge problem, as it would grant a lot of active fingerprinting surface unnecessarily.
[...] My understanding is that feature policy applies at the frame level, and therefore could not be used to control what happens when a third-party script in a first party context calls the API. Even for third-party iframes, it seems like Feature Policy could only default-deny this JS API entirely, and would not be able to filter the results down to the set delegated via HTTP headers (or otherwise). Maybe you intend a feature policy per individual high entropy hint, but first of all that seems like overkill, and second, the spec is clearly not written to support such filtering. So no, it would not address the concerns. I think the best approach is to limit the hints to those opted into (or, in case of a third-party frame, delegated). That or remove the script API entirely. The origin-based delegation model that works well at the HTTP level is not well aligned with the widespread practice of including third-party scripts in the top frame. The spec does not even allow denying the request entirely as written. A non-normative Note suggests that is allowed, but I can’t find any step in the algorithm that would ever reject the promise.
In case you're wondering why Apple's thoughts on Chrome are even important, that is because web developers ideally want to write code that is consistent and compatible across all browsers. As such, when it comes to a new feature, a buy-in from major browser vendors is important. A rejection of a feature from a vendor would mean that developers would either ditch the feature completely or write specific code for that browser to ensure compatibility and behavior across platforms.
.jpg)
There are other notable changes too, though not quite so controversial. The use of WebSQL in non-secure contexts is being deprecated because it's a legacy spec from 2009 that Apple abandoned in 2019 and Mozilla didn't even implement it. Other removed features in Chrome 105 include Gesture Scroll DOM events which were never meant to be released and the ability to use the "default" CSS keyword in custom identifiers.
A global event handler called "onbeforeinput" has been introduced too, and it has support from Apple, Mozilla, and web developers. In the same vein, another new feature that enjoys support from developers is explicit marking of resources that should be blocked from rendering.
Other capabilities shipping with Chrome 105 are Container Queries for more consisting styling for elements, two pseudo class selectors (1, 2), a way to access the TransformStreamDefaultController class more easily, and some new methods for navigation classes (1, 2), along with some behavioral changes for fixed elements during overscrolling.
Another thing that will make developers using the File System Access API very happy is the ability to get a writable directory in the same prompt as the readable directory. Previously, this only returned the latter which caused confusion and permission fatigue for the user. In the same vein, a fetch upload streaming method has been introduced so developers don't have to write messy code on the WebSocket to achieve the same purpose. Additionally, an MVP version of the Sanitizer API is being shipped as well, it enables developers to build XSS-free web applications in an easier fashion by transferring some maintenance burden to the platform.
Major changes are being made to the audio input and output mechanisms. Streaming and video conferencing applications should now explicitly request to receive non-system audio. There is also a new method to resolve imported URLs, and a Media Source Extensions (MSE) API, described as follows:
Web authors have consistently requested that MSE be available from Worker contexts. In the absence of such mechanisms, web authors are forced to perform all operations on the MSE API on the main Window context. Especially when the main context is busy servicing other application logic, these restrictions can significantly impair the user experience. For example, even if an app uses Worker contexts to fetch media to feed to MSE, such feeding must still occur on the main context, resulting in delayed media playback start and recurring playback stalls in extreme cases when the playback reaches points in the presentation timeline for which the app has been unable to buffer enough media.
The original proposal included text to support "early open" using a new MediaSourceHandle object. The subsequent discussion, simplification and experimental implementation drop "early open" and MediaSourceHandle from this initial work since those are both significant complexities that can be decoupled and incubated in follow-on features.
Furthermore, it's now easier to create a JSON response. Worklet loading is now reported to Resource Timing for more transparency too.
While that is all for generally available features, there are quite a few capabilities locked behind developer flags as well. These include throttling all timers (including DOM timers) to 125Hz, which should encourage developers to migrate to better and more power-efficient alternatives. Other interesting capabilities include anonymous iframe objects (read all the technical details here), removal of the merchant identity from the "canmakepayment" service worker event, and exposing the WebHID API to extension service workers.
In addition to being available on Android already, Prerender 2 for Desktop is now being implemented for the sake of feature parity too. Those who play games on their Android handset using gamepads will be very happy to know that the Gamepad API will be able to take advantage of haptic feedback options like trigger-rumble and dual-rumble (Android 12+ only). Finally, Chrome 105 also has an implementation of TLS Encrypted Client Hello (ECH) for improved privacy behind a flag, similar to Microsoft Edge.
.jpg)
As you might have surmised by the length of this article, Chrome 105 is a major update. It will start rolling out in the later hours of today. If Chrome does not automatically update to version 105 for you throughout the course of the day, head over to Help > About Google Chrome to trigger the update once it becomes available. Next up is Chrome 106 which will hit the Beta channel on September 1, and will land on Stable on September 27.
