(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. > *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_2SYOfRZmy1DiSkDXbPb%3D63ZTF1%3DmtfxW4vRPas54x0g5xg%40mail.gmail.com.
