LGTM2 conditional on answers to the questions around tests On Wednesday, December 17, 2025 at 5:08:57 PM UTC+1 Chris Harrelson wrote:
> LGTM1 > > On Mon, Dec 15, 2025 at 5:40 PM Reilly Grant <[email protected]> wrote: > >> IWA OWNER LGTM, this is an extension to an existing IWA-specific feature. >> Thank you for finding a solution which fits within the existing Web Request >> API. >> >> Note, this still needs 3 LGTMs from Blink OWNERS. >> Reilly Grant | Software Engineer | [email protected] | Google Chrome >> <https://www.google.com/chrome> >> >> >> On Tue, Dec 9, 2025 at 4:17 AM Chromestatus < >> [email protected]> wrote: >> >>> *Contact emails* >>> [email protected] >>> >>> *Explainer* >>> https://github.com/explainers-by-googlers/security-info-web-request >>> >>> *Specification* >>> https://github.com/WICG/controlled-frame/pull/151 >>> >>> *Design docs* >>> >>> https://github.com/explainers-by-googlers/security-info-web-request >>> >>> *Summary* >>> This proposal introduces a WebRequest.SecurityInfo API for >>> ControlledFrame. It allows a web app to intercept an HTTPS, WSS or >>> WebTransport request to a server, retrieve the server's certificate >>> fingerprint (as verified by the browser), and then use that fingerprint to >>> manually verify the certificate of a separate raw TCP/UDP connection to the >>> same server. This provides a simple way for the app to confirm it's talking >>> to the correct server. >>> >>> *Blink component* >>> Blink >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%22> >>> >>> *Web Feature ID* >>> Missing feature >>> >>> *Motivation* >>> Web apps sometimes need to establish secure raw TCP/UDP connections >>> (e.g., via Direct Sockets) for custom protocols, often to support legacy >>> servers that cannot be updated to modern alternatives like WebTransport. >>> Unlike standard HTTPS, these raw sockets don't have a built-in mechanism to >>> verify the server's TLS certificate against a trusted root store. This >>> proposal introduces a WebRequest SecurityInfo API for ControlledFrame. It >>> allows a web app to intercept an HTTPS, WSS or WebTransport request to a >>> server, retrieve the server's certificate fingerprint (as verified by the >>> browser), and then use that fingerprint to manually verify the certificate >>> of a separate raw TCP/UDP connection to the same server. This provides a >>> simple way for the app to confirm it's talking to the correct server. >>> >>> *Initial public proposal* >>> https://github.com/WICG/proposals/issues/245 >>> >>> *TAG review* >>> Tag does not review Isolated Web Apps. It was stated publicly here >>> https://github.com/w3ctag/design-reviews/issues/842#issuecomment-2917031448 >>> >>> *TAG review status* >>> Pending >>> >>> *Risks* >>> >>> >>> *Interoperability and Compatibility* >>> Other browsers may choose to implement this API. >>> >>> *Gecko*: No signal >>> >>> *WebKit*: No signal >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> *Security* >>> This API exposes the server's leaf certificate and fingerprint to the >>> web app. This is not considered a new security or privacy risk. A web app >>> with Isolated Context and the direct-sockets permission can already open a >>> raw TCP connection to any server, perform a (D)TLS handshake using a WASM >>> library, and retrieve the exact same server certificate. >>> >>> *WebView application risks* >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> *No information provided* >>> >>> >>> *Debuggability* >>> There's no devTools support for this feature. Since, this feature itself >>> does not modify any web requests, it gives read-only view into server >>> certificate. >>> >>> *Will this feature be supported on all six Blink platforms (Windows, >>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>> No >>> This feature is implemented on desktop platforms, although it will only >>> be available to the end users on platforms that support Isolated Web Apps, >>> which is currently only ChromeOS. Android is excluded for historical >>> reasons, although there are no apparent interoperability blockers here. >>> >>> *Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> No >>> >>> >>> *Flag name on about://flags* >>> controlled-frame-web-request-security-info >>> >>> *Finch feature name* >>> kControlledFrameWebRequestSecurityInfo >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> True >>> >>> *Tracking bug* >>> https://g-issues.chromium.org/issues/462114142 >>> >>> *Launch bug* >>> https://launch.corp.google.com/launch/4436388 >>> >>> *Measurement* >>> Added new values to Extensions.WebRequest.EventListenerFlag which are >>> securityInfo, securityInfoRawDer >>> >>> *Availability expectation* >>> Feature is available only in Isolated Web Apps on desktop platforms. >>> https://chromestatus.com/feature/5146307550248960 >>> >>> *Adoption expectation* >>> Expected to be used initially by a small number of developers inside >>> Isolated Web Apps. >>> >>> *Adoption plan* >>> Working directly with developers that are planning to rely on the API. >>> >>> *Estimated milestones* >>> Shipping on desktop 147 >>> DevTrial on desktop 145 >>> >>> *Anticipated spec changes* >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> *No information provided* >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5076692209106944?gate=6523426508505088 >>> >>> *Links to previous Intent discussions* >>> Intent to Prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/691df8c4.050a0220.2a427a.06b0.GAE%40google.com >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com>. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6938134e.050a0220.1dd095.0001.GAE%40google.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6938134e.050a0220.1dd095.0001.GAE%40google.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMa%3DyZM2rOO3v4BwThnPs7LtGz03OZF9HVom2djt2M-9AQ%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMa%3DyZM2rOO3v4BwThnPs7LtGz03OZF9HVom2djt2M-9AQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b73fa7ce-e7bd-458e-a339-4af687dabc3en%40chromium.org.
