Chrome 158 Arrives: WebHID Lands on Android 17, XSLT Dies for Good, and Why ChromeOS Skipped 157

If you have been watching Chrome version numbers jump faster than usual this autumn, you aren’t imagining things. Starting with ChromeOS 154, Google shifted the Chrome browser to a rapid two-week release cycle while keeping ChromeOS on a four-week schedule that increments by even numbers (154 → 156 → 158).

That means odd-numbered milestones like Chrome 157 are now quiet, browser-only stops, while even-numbered milestones carry the heavy OS and platform upgrades. Published in the latest Chrome Enterprise Release Notes, Chrome 158 is now rolling out—bringing major peripheral upgrades for Android 17 and Googlebook users, killing off a 27-year-old web standard, and laying out the security roadmap through Chrome 168.

1. WebHID Lands on Android 17: A Big Deal for Googlebooks

One of the sharpest friction points when moving from classic ChromeOS to an Android 17-powered Googlebook has been advanced peripheral support. On desktop Chrome and ChromeOS, we have had the WebHID API since Chrome 89—letting web configurators like VIA, QMK, Logitech G Hub Web, and enterprise call-centre dashboards communicate directly with USB and Bluetooth Human Interface Devices (HIDs) without installing bulky native drivers.

Chrome 158 brings the full WebHID API to Chrome on Android, built directly on new OS-level support in Android 17 (API level 37 and later) with zero changes to the web-exposed API surface.

• Custom Keyboards, Mice & Gamepads: Googlebook and Android 17 tablet users can now remap mechanical keyboards, programme gaming mice, and calibrate controllers straight from a browser tab.
• Enterprise Call-Centre Headsets: Browser-based contact-centre web apps can now read hardware mute, hook-switch, and call-answer buttons on USB/Bluetooth headsets connected to Android 17 endpoints.
• Full Admin Policy Parity: IT administrators can govern WebHID on Android using the exact same policies already supported on ChromeOS: DefaultWebHidGuardSetting, WebHidAllowAllDevicesForUrls, WebHidAllowDevicesForUrls, WebHidAllowDevicesWithHidUsagesForUrls, WebHidAskForUrls, and WebHidBlockedForUrls. (Note: Android WebView is not supported as it lacks a permissions chooser UI.)

2. The End of an Era: Chrome 158 Disables XSLT on Stable

Standardised back in 1999, XSLT v1.0 (Extensible Stylesheet Language Transformations) has been frozen inside web browsers for over two decades while the rest of the web moved to JSON, React, and modern JavaScript DOM manipulation.

Starting in Chrome 158, XSLT stops functioning by default on Stable releases across Android, ChromeOS, Linux, macOS, and Windows.

Why pull the plug now? Chromium relies on libxslt to process these transformations—a complex, aging C codebase that went completely unmaintained for roughly six months of 2025. Because legacy C XML/XSLT parsers are notoriously prone to buffer overflows and arbitrary code execution—and have been the culprit behind several high-profile browser exploits—Chromium (alongside Firefox’s Gecko and Safari’s WebKit) is removing it from the web platform.

• The Enterprise Escape Hatch: If your organisation still runs legacy internal XML portals that rely on client-side XSLT, you can use the temporary Enterprise Policy or Origin Trial to keep XSLT working until Chrome 176, when both fallbacks will be permanently removed.

3. Native Web App Installs: <install> HTML Tag & navigator.install()

For years, offering a Progressive Web App (PWA) install button meant developers had to wrestle with clunky beforeinstallprompt JavaScript events, and users couldn’t easily install a web app from a cross-origin app catalog or enterprise portal.

Chrome 158 launches two parallel improvements on desktop platforms (Windows, macOS, and Linux):

1. The <install> HTML Element: A declarative HTML tag that triggers a native browser install request given a manifest URL and optional manifest ID—no JavaScript required.
2. The Web Install API (navigator.install()): The imperative JavaScript method that enables clean, cross-origin web app installations.

IT admins can control both mechanisms via the WebAppInstallByUserEnabled enterprise policy or scope them to trusted internal origins and iframes using the web-app-installation permissions policy.

4. Gen AI & SaaS Usage Reporting Expands to ChromeOS and Mobile

As we covered in our deep dive on Chrome Enterprise’s Gen AI & SaaS App Usage Report, shadow AI visibility is top of mind for IT teams. After launching on desktop in Chrome 153, Gen AI and SaaS app usage reporting in the Google Admin console is rolling out to ChromeOS, Android, and iOS in Chrome 158.

Admins now get a single, unified view across Chromebooks, Googlebooks, phones, and desktops tracking:

• Total visits to generative AI tools and SaaS platforms.
• Unique managed profiles and managed browsers.
• Sensitive content transfer events, which can then be locked down using Chrome Enterprise Premium Data Loss Prevention (DLP) rules.

On the mobile side, Chrome 158 also extends built-in Chrome profile signal sharing to iOS, laying the groundwork for MDM-free Context-Aware Access (CAA) posture checks on iPhones and iPads.

5. What Happened in Chrome 157?

Because Chrome 157 (released October 28, 2026) was an odd-numbered browser release, it only introduced two notable updates:

• Dedicated Proxy Auth Policy (AllHttpAuthSchemesAllowedForProxies): Available starting in Chrome 157 on ChromeOS, Android, and desktop, this new policy separates proxy authentication from origin authentication (AllHttpAuthSchemesAllowedForOrigins). Proxy support will be stripped from the origin policy in Chrome 161.
• Chrome iOS “Level Up”: A new opt-in feature-discovery progress tracker on iOS, which admins will be able to disable via PromotionsEnabled in Chrome 160.

6. Roadmap Watch: What’s Coming in Chrome 159–168

The upcoming enterprise roadmap also flags several critical security and lifecycle changes every ChromeOS and Workspace admin should prepare for: