LGTM to extend the deprecation trial M127-132, but it'd be good to have meaningful progress by then to reduce the number of folks that use it..
On Fri, Jun 14, 2024 at 8:48 PM Emily Stark <est...@chromium.org> wrote: > > > On Fri, Jun 14, 2024 at 10:36 AM Emily Stark <est...@chromium.org> wrote: > >> (Apologies for the slow response, we had some OOOs) >> >> On Mon, Jun 3, 2024 at 7:55 PM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> Hi Emily, >>> >>> A few questions inline: >>> On 6/1/24 5:05 AM, Emily Stark wrote: >>> >>> Contact emails est...@google.com, jdebla...@google.com, >>> dadr...@google.com, l...@chromium.org, tito...@chromium.org, >>> cl...@chromium.org, mk...@chromium.org, v...@chromium.org >>> >>> Explainer >>> https://github.com/WICG/private-network-access/blob/master/explainer.md >>> >>> Specification https://wicg.github.io/private-network-access >>> >>> Design docs >>> >>> https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64 >>> >>> Summary >>> >>> Requires that private network requests for subresources from public >>> websites may only be initiated from a secure context. Examples include >>> internet to intranet requests and internet to loopback requests. This is a >>> first step towards fully implementing Private Network Access: >>> https://wicg.github.io/private-network-access/ >>> >>> >>> Blink component Blink>SecurityFeature>CORS>PrivateNetworkAccess >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess> >>> >>> TAG review https://github.com/w3ctag/design-reviews/issues/572 >>> >>> TAG review status Issues addressed >>> >>> Chromium Trial Name PrivateNetworkAccessNonSecureContextsAllowed >>> >>> Link to origin trial feedback summary >>> https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing&resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ >>> >>> Origin Trial documentation link >>> https://developer.chrome.com/blog/private-network-access-update/ >>> >>> WebFeature UseCounter name >>> kPrivateNetworkAccessNonSecureContextsAllowedDeprecationTrial >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> No interoperability risks. Compatibility risk is small but >>> non-negligible. UseCounters show ~0.1% of page visit making use of this >>> feature. Direct outreach to the largest users per UKM data revealed no >>> objections to this launch. Rolling this deprecation out to beta per the >>> previous I2S resulted in more feedback about the compatibility risk and the >>> need for a time extension. See the following doc for an extensive >>> discussion: >>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit >>> >>> Can you speak to the number of sites in the largest users group? Is it >>> dozens of sites? Hundreds? Presumably they're all enrolled in the DT? >>> >> I've requested access to the OT data so I can't say for sure yet, but in >> the meantime, my impression is that we're roughly talking about hundreds of >> sites. The breakage of ending the deprecation trial would be quite small in >> terms of affected page loads, but there are legitimate use cases >> <https://github.com/WICG/private-network-access/issues/23#:~:text=in%20order%20for%20a%20device%20to%20get%20a%20coveted%20MFi%20(%E2%80%9CWorks%20with%20HomeKit%E2%80%9D)%20certification%20from%20Apple%2C%20it%20must%20not%20require%20direct%20internet%20access%20for%20the%20initial%20setup> >> for nonsecure subresource requests to the private network that we're trying >> to accomodate because they don't have an alternative/workaround. >> > > Update: it looks like there are ~1000 sites registered in the DT. > > >> *Gecko*: Closed Without a Position ( >>> https://github.com/mozilla/standards-positions/issues/143) Tentatively >>> positive, but no formal position yet. >>> >>> *WebKit*: Positive ( >>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html) >>> >>> *Web developers*: Mixed signals ( >>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit) >>> In our recent survey, most of websites are able to migrate if our new >>> permission prompt can be landed as a way for them to relax mixed content >>> checks. >>> https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809 >>> ------------ >>> Some websites, broadly falling in the category of controller webapps for >>> IoT devices, find this change incompatible with their use cases. While many >>> use cases can be solved with specific workarounds, some still require >>> further engagement. >>> >>> *Other signals*: >>> >>> Activation >>> >>> Developers of non-secure sites that rely upon local servers will need to >>> upgrade to HTTPS. This might cause some complications, as mixed-content >>> checks will begin to apply. Chrome carves out HTTP access to loopback (as >>> perhttps://w3c.github.io/webappsec-secure-contexts/#localhost), which >>> is a release valve for folks who don't want to go through the effort of >>> securely-distributing certs for local servers. The initial launch in M92 >>> was delayed due to compatibility risks surfaced during the rollout to beta. >>> See this doc for a lot more details: >>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit >>> >>> >>> Security >>> >>> This change should be security-positive. >>> >>> >>> 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? >>> >>> >>> Goals for experimentation >>> >>> Reason this experiment is being extended >>> >>> The blocker to shipping this feature is that some websites can't create >>> HTTPS connections to subresources on the private network due to various >>> constraints (e.g., unable to obtain a publicly trusted HTTPS certificate). >>> A permission prompt is in development ( >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/sL15TKGmXqM/m/rD0SF8sQBwAJ) >>> to allow such subresources to be loaded over HTTP (whereas they would >>> usually be blocked by mixed content rules). However, the permission prompt >>> currently only works for fetch() and does not work in iframes, thus we need >>> to investigate whether we need to support use cases not supported by the >>> current implementation. The overall Private Network Access project is also >>> currently being transitioned between teams, so the extension request >>> includes some time for handoff/rampup. >>> >>> I'm slightly confused on the timing - >>> https://chromestatus.com/feature/5954091755241472 states that we >>> shipped the permission prompt in 124 - is that not the case? >>> >>> What are the non-fetch cases that might need to be supported? XHR? >>> Sub-resource loads? Both? Something else? Is it feasible to design a DT >>> that addresses the non-fetch() use cases? >>> >> The permission prompt for fetch() requests did indeed ship in M124, but >> there are feature requests to support subresouce loads from HTML tags >> (<img>, <iframe>, etc.) as well as to support permission delegation to >> iframes. These outstanding feature requests are described in this >> (Google-internal) doc: >> https://docs.google.com/document/d/1r4MnGtCmXvt-sDdp3RiaYLkdTcLKPjmmL4ky4TCOMS0/edit?tab=t.0#heading=h.1fxgtnya8b50 >> >> So we're requesting an extension to this DT (which allows enrolled >> nonsecure origins to make private network requests) to give us time to >> implement those feature requests. That will allow the origins enrolled in >> this DT to migrate to secure origins and use the permission prompt (and >> related feature requests) to make private network requests to nonsecure >> origins. >> >> I don't think I understand your last question ("Is it feasible to design >> a DT...?"), could you clarify? >> >>> Also, could you clarify what milestones you're requesting a renewal for? >>> The table below is hard for me to parse (e.g., extension 5 ending in 132; >>> extension 6 ending in 126). >>> >> I've been staring at Chrome Status for a while and am honestly pretty >> confused as to how that table came to be. We're requesting a renewal in >> M127, to last until M132. >> >>> >>> Ongoing technical constraints >>> >>> None. >>> >>> >>> Debuggability >>> >>> When a request is made that violates this restriction and the feature is >>> not enabled, three things happen: 1. A warning message is logged to the >>> DevTools console. 2. A deprecation report is filed against the initiator >>> website's Reporting API, if so configured. 3. An issue is surfaced in the >>> DevTools Issues panel. Likewise, when the feature is enabled and a request >>> is blocked, the same happens except that the message logged to the DevTools >>> console is an error and its text is slightly different. The devtools >>> network panel shows information about the source and remote address spaces >>> at play. >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)? Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? Yes >>> >>> >>> https://wpt.fyi/results/fetch/private-network-access?label=master&label=experimental&aligned >>> >>> >>> Flag name on chrome://flags BlockInsecurePrivateNetworkRequests >>> >>> Finch feature name None >>> >>> Non-finch justification None >>> >>> Requires code in //chrome? False >>> >>> Tracking bug https://crbug.com/986744 >>> >>> Launch bug https://crbug.com/1129801 >>> >>> Estimated milestones >>> Shipping on desktop 127 >>> Origin trial desktop first 94 >>> Origin trial desktop last 126 >>> Origin trial extension 1 end milestone 126 >>> Origin trial extension 5 end milestone 132 >>> Origin trial extension 6 end milestone 126 >>> DevTrial on desktop 86 >>> OriginTrial Android last 126 >>> OriginTrial Android first 94 >>> DevTrial on Android 86 >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5436853517811712?gate=5187028487766016 >>> >>> Links to previous Intent discussions Ready for Trial: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJ >>> Intent to Experiment: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vlDZXlPb00k/m/1421ACiuAAAJ >>> Intent to Extend Experiment 1: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck >>> Intent to Extend Experiment 6: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck >>> Intent to Ship: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck >>> Intent to Ship: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck >>> >>> >>> 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 blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPP_2Sbhrsrmmk5ZTwkxkuwT6_iEs4QPNGNYTL9u_7ODmEb3Vw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPP_2Sbhrsrmmk5ZTwkxkuwT6_iEs4QPNGNYTL9u_7ODmEb3Vw%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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPP_2SaQKCfQCsMpcJUHDYU%3Dx%3Dc5uuwBVyesqeBheMrAma%2B7Zg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPP_2SaQKCfQCsMpcJUHDYU%3Dx%3Dc5uuwBVyesqeBheMrAma%2B7Zg%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLHdO_ZTKr6XoYK1pyTpoo6j9x_YQUY6hqWW_ee5xWU4A%40mail.gmail.com.
