Hi all -- As M132 has now branched I wanted to follow up here with an update on our plan going forward.
We are choosing to allow this deprecation trial to expire and we will *not* be moving forward with these restrictions as currently proposed at this time. While we still want to remove the risk of private network access on the web, the current approach has run into a number of challenges that make it difficult to move forward as-is (particularly, despite the deprecation trial we still see a large ecosystem lift for adopting secure contexts and the new preflights). Currently, we are regrouping and working on an updated proposal, which we hope to be able to share publicly soon. While undoing the deprecation trial and disabling the underlying enforcement may allow some new usage from insecure contexts, we are working towards a solution and accepting this small risk of new breakage seems on the whole better than continuing to run this deprecation trial indefinitely. - Chris On Tue, Jun 18, 2024 at 8:09 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLHdO_ZTKr6XoYK1pyTpoo6j9x_YQUY6hqWW_ee5xWU4A%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46T7WXG5xm_feint7t0%3D%3DCf5gSri4ZR8FTju1Li1oW5HaQ%40mail.gmail.com.
