Chrome 119 release

Google has released version 119 of the Chrome web browser. At the same time, a stable release of the open-source project Chromium, which serves as the basis for Chrome, is available. The Chrome browser differs from Chromium by using Google logos, having a notification system for crashes, modules for playing copy-protected video content (DRM), an automatic update installation system, always enabling Sandbox isolation, delivering keys to Google API, and transmitting RLZ parameters during searches. For those who need more time to update, an Extended Stable branch is separately maintained, accompanied by 8 weeks. The next release, Chrome 120, is scheduled for December 5.

Key changes in Chrome 119:

• The release cycle has been shortened, reducing the time between creating a new branch and starting beta testing—the beta version is now generated two days after the branch is created instead of eight days. Stabilization of the beta version continues to take four weeks as before. Thus, the preparation cycle for new releases is now one week shorter.
• The ability to save tab groups has been introduced. Users can now save a group and close the tabs within it to conserve resources. Later, when needed, tabs from the saved group can be restored and opened on other devices participating in tab synchronization. This feature is enabled for a subset of users, with a setting for forced enabling available at ‘chrome://flags/#tab-groups-save’.
• The interface has seen changes in the phrasing of operations and settings related to the deletion and loss of data. Instead of the term 'Clear' in such operations, the word 'Delete' is now used, as 'Clear' was not perceived by some users as an indication of irreversible data loss.
• URL auto-completion now considers any keyword previously used to search for a site, not just words that match the beginning of the address. For example, auto-completion for the address 'https://www.google.com/travel/flights' will work not only when entering the word 'google' but also when entering 'flights'.
• Automatic spelling correction has been implemented when entering a website address, along with relevant suggestions based on sites previously accessed by the user. For instance, when typing "youutube", it will suggest opening YouTube.com.
• Users can now search within bookmark sections through the address bar. For example, by entering the name of a bookmark section, Chrome will suggest links from that section that correspond to the entered keyword. For example, entering "trips 2023 New" will suggest links from the "trips 2023" bookmark section related to New York.
• Recommendations for popular sites are now provided, even if the user has not visited them before or made a mistake entering the URL. For example, if a user begins typing "googleear" to open Google Earth without knowing the exact address, the browser will suggest visiting earth.google.com.
• In Chrome for desktop systems, the readability of information in the address bar has improved, and the interface responsiveness has increased — results now appear immediately after the user starts typing in the address bar.
• In accordance with the updated Fetch API specification, the HTTP Authorization header is removed when redirecting to another domain (cross-origin).
• In the notification settings and location definition, an option has been added to enable the Permission Suggestions Service for suppressing requests for permission confirmation. The following modes are offered:
  • always show permission requests for notifications and location access;
  • automatically ignore spammy permission requests using the Permission Suggestions Service mechanism;
  • always ignore all requests for notifications;
  • always block all requests for permission to display notifications and access location.
• In builds for the Android platform, when standard browser protection (Safe Browsing > Standard protection) is enabled, real-time security checks of open URLs are implemented based on the transmission of servers partial hashes of the URLs opened by the user to Google. To exclude matches an IP address Users and hashes, data is transmitted through an intermediary proxy. Previously, verification was done by uploading a local copy of the list of unsafe URLs to the user's system. The new scheme allows for more prompt blocking of malicious URLs. This mode for desktop systems was included in the last release.
• Escaping non-alphanumeric characters in the host name in the URL function call has been aligned with the updated specification. For example, calling the function ‘URL("http://exa(mple.com;")’ previously returned ‘http://example.com/’, but now will result in an error output: "Invalid URL."
• A lifespan restriction similar to that applied since Chrome 104 for new and updated cookies has been applied to all previously saved cookies. For existing cookies, the lifespan will be shortened to 400 days from the release of Chrome 119.
• New pseudo-classes ‘:user-valid’ and ‘:user-invalid’ have been proposed in CSS, representing form elements whose values have passed or failed validation. Unlike ‘:valid’ and ‘:invalid’, the new pseudo-classes trigger only after user interaction with the form element.
• When setting colors in CSS, the definition of values computed relative to other color parameters is allowed. For example, specifying ‘oklab(from magenta calc(l * 0.8) a b)’ will yield a color that is 80% lighter than magenta.
• In the CSS property clip-path, which allows limiting the visibility of an element to a specific area, support for the value has been added to define a custom area for clipping. The use of xywh() and rect() functions has also been provided for simplifying the specification of rectangular or rounded areas.
• Support for the WebSQL API has been disabled, which is recommended to be replaced with the Web Storage and Indexed Database APIs. The WebSQL handler was based on the SQLite library code. The WebSQL API was not supported in other browsers, depended on external library APIs, and increased the risk of security issues (WebSQL could be exploited by attackers to exploit vulnerabilities in SQLite). A policy, WebSQLAccess, has been left in place to return WebSQL support for enterprise users, which will be removed in Chrome 123.
• The HTML Sanitizer API, which allowed to cut elements from content that affect the display and execution when outputting via the setHTML() method, has been temporarily removed. The API was designed to cut HTML tags that could be used for XSS attacks. The reason for removal is the incompleteness of the specification, which has significantly changed since the Sanitizer was added to Chrome. The API will be returned once the specification is complete.
• The non-standard attribute shadowRoot, which allowed self-elements to access their separate root in the Shadow DOM regardless of the state, has been removed. Instead of shadowRoot, Chrome 111 introduced the shadowRootMode attribute, which has been included in the web standard.
• The implementation of the HTML element , which resembles and also allows embedding third-party content on the page, has been improved. The differences are mainly related to restricting the interaction of the embedded content with the page content at the DOM and attribute level. For example, the news.example page, which includes a block of ads embedded using fencedframe from the shoes.example site, cannot access data from shoes.example, nor can the code from shoes.example access data related to news.example. The new version adds support for size macros for ad blocks that have appeared in the Protected Audience API, such as "https://ad.com?width={/AD_WIDTH}&height={/AD_HEIGHT}".
• A parameter monitorTypeSurfaces has been added to the getDisplayMedia() method, which can be used to prevent sharing access to the entire screen.
• An experimental (origin trial) parameter fullscreen has been added to the window.open() method, allowing a window to be opened directly in full-screen mode.
• A flag "bitrateMode" has been added to the AudioEncoderConfig API to choose between constant and variable bitrate.
• TLS includes the implementation of the Key Encapsulation Mechanism (KEM), using the hybrid algorithm X25519Kyber768, which is resistant to attacks by quantum computers. To create session keys used for encrypting data within TLS connections, a combination of the X25519 key exchange mechanism, based on elliptic curves and currently utilized in TLS, with the Kyber-768 algorithm, which utilizes lattice-based cryptography methods, can now be employed. The time required to solve these problems is equivalent on both classical and quantum computers.
• Support for the WasmGC extension, which simplifies the porting of programs written in programming languages that use garbage collection (such as Kotlin, PHP, Java, etc.) to WebAssembly, is enabled by default. WasmGC introduces new types of structures and arrays, for which non-linear memory allocation can be applied.
• Improvements have been made to the tools for web developers. The ability to edit CSS rules with ‘@property’ has been added, along with warnings for incorrect definitions. The list of emulated devices has been updated (for example, iPhone 14 and Pixel 7 have been added). The web console now features autocomplete for private fields. Formatting for JSON data contained within blocks has been ensured.

In addition to new features and bug fixes, the new version resolves 15 vulnerabilities. Many of these vulnerabilities were discovered through automated testing with tools such as AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer, and AFL. Critical issues that allow bypassing all browser security levels and executing code on the system outside the sandbox environment have not been identified. As part of the bug bounty program for this release, Google awarded 13 prizes totaling $40,500 (including one prize of $16,000, $11,000, $2,000, and $500, three prizes of $3,000, and two prizes of $1,000). The amount for four awards has yet to be determined.

Source: opennet.ru