LGTM3 with the same conditions. Best,
Alex On Wednesday, December 17, 2025 at 8:10:08 AM UTC-8 Yoav Weiss wrote: > 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/f62e6252-d2d2-4f1c-8fe2-aa9966b70fbbn%40chromium.org.
