Google Chrome 105 ships today despite Apple privacy concerns

0

Earlier this month, Chrome 104 hit the Stable channel with an updated Bluetooth Web API that has come under heavy criticism from Apple and Mozilla for exposing fingerprint surfaces. which could be used to invade the privacy of Chrome users. Today Chrome 105 arrives and although it is not as controversial as the previous version, Apple has some concerns with this version as well.

Chrome 105 contains many changes on the backend. One of them is User Agent Client Hints, an API that exposes information about device activity and conditions so developers can make their web pages dynamically respond to various hardware. With the release of Chrome 100 in March, Google warned web developers that they had until March 2023 to migrate to this Client Hints API instead of relying on user agent strings.

As such, the Hints Clients API review isn’t new but Chrome 105 makes some changes to it where developers can request information about the height of the browser window Show content. Previously, this API only exposed viewport width information, but Google believes that retrieving the height would also be useful to ensure that height-restricted images on web pages display correctly. Client advice delegation syntax is also changedin response to developer feedback.

Google highlighted a thread from 2020 where Apple’s WebKit team raised concerns about the use of Client Hints API for fingerprint users. Excerpts from the thread are attached below:

I may have misinterpreted the spec, but as written, getHighEntropyValues ​​seems to give access to all high-entropy client hints to third-party scripts in the first-party context, and to scripts running in third-party iframes, regardless of which ones the site has enabled via the corresponding HTTP header.

[…] We are currently deeply skeptical of implementing any of the other client indices due to their extension of fingerprint area, so I don’t feel particularly obligated by this precedent. That said, it’s likely that the client’s other tips have the same problem, where they expose the fingerprint surface much wider than they want. This would be a huge problem, as it would unnecessarily grant a lot of active fingerprint area.

[…] My understanding is that the feature policy applies at the framework level and therefore cannot 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 that Feature Policy can only deny this default JS API entirely, and would not be able to filter results down to the delegated set via HTTP headers (or otherwise). Perhaps you intend to enforce a feature policy per individual high entropy index, but firstly that seems overkill, and secondly the spec is clearly not written to support a such filtering. So no, that would not address the concerns. I think the best approach is to limit indices to those that have been chosen (or, in the case of a third-party framework, delegated). Either that or remove the scripting 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 upper frame. The spec doesn’t even allow denying the request entirely as written. A non-normative note suggests this 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 even matter, it’s because web developers ideally want to write code that’s consistent and compatible across all browsers. As such, when it comes to a new feature, buy-in from major browser vendors is important. Rejection of a feature by a vendor would mean that the developers either drop the feature altogether or write specific code for that browser to ensure compatibility and behavior across all platforms.

Chrome 105 logo on a blue background with a dark blue padlock, an Xbox controller and a person with a

There are also other notable changes, although less controversial. The use of WebSQL in insecure contexts is deprecated because it’s a legacy spec from 2009 that Apple dropped in 2019 and Mozilla didn’t even implement it. Other features removed from Chrome 105 include Gesture Scroll DOM events that were never intended to be published and the ability to use “default” CSS keyword in custom identifiers.

A global event handler called “onbeforeinput” has also been introduced, and it’s supported by Apple, Mozilla, and web developers. In a similar vein, another new feature that has developer support is explicit marking of resources to block rendering.

Other features that come with Chrome 105 are Container queries for more consistent styling for itemstwo pseudo class selectors (1, 2), a easier way to access TransformStreamDefaultController classand some new methods for navigation classes (1, 2), as well as some behavior changes for fixed elements when overscrolling.

Another thing that will make developers using the Filesystem 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 authorization fatigue for the user. In the same vein, a download stream fetch method has been introduced So developers don’t have to write complicated code on the WebSocket to achieve the same goal. In addition, an MVP version of the Sanitizer API is also on the wayit makes it easier for developers to build web applications without XSS by shifting some of the maintenance burden to the platform.

Major changes are made to the audio input and output mechanics. Streaming and video conferencing apps should now explicitly request to receive non-system audio. There is also new method to resolve imported URLsand one Media Source Extensions API (MSE)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 in the main context of the window. Especially when the main context is busy handling other application logic, these restrictions can significantly impair the user experience. For example, even if an application uses worker contexts to retrieve media to be fed by MSE, such feeding must still occur on the main context, resulting in delayed start of media playback and recurrent playback stops in edge cases when playback reaches points in the presentation timeline. for which the application could not buffer enough media.

The original proposal included text to support “early opening” using a new MediaSourceHandle object. Further discussion, simplification, and experimental implementation remove “early open” and MediaSourceHandle from this initial work as they are two significant complexities that can be decoupled and incubated into tracking functionality.

Moreover, it is now easier to create a JSON response. Loading of worklets is now reported to Resource Timing for more transparency too.

While that’s it for generally available features, there are also a number of features locked behind developer flags. These include limitation of all timers (including DOM timers) to 125 Hz, which should encourage developers to migrate to better and more energy-efficient alternatives. Other cool features include anonymous iframe objects (read all the technical details here), removal of merchant identity from the “canmakepayment” service worker event, and expose WebHID API to extension service workers.

In addition to being already available on Android, Prerender 2 for Desktop is being implemented for feature parity reasons as well. 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 double rumble (Android 12+ only). Finally, Chrome 105 also has a implemented TLS Encrypted Client Hello (ECH) for better privacy behind a flag, similar to Microsoft Edge.

A graphic showing that Chrome 105 will arrive on August 30 while Chrome 106 will arrive on September 2

As you might have guessed by the length of this article, Chrome 105 is a major update. It will begin to unfold in the final hours of today. If Chrome doesn’t automatically update to version 105 for you throughout the day, go to Help > About Google Chrome to trigger the update as soon as it is available. Next up is Chrome 106 which will hit the beta channel on September 1 and land on Stable on September 27.

Share.

Comments are closed.