Hi there, Any thoughts? We'd like to announce this trial in a blog post prior to beta promotion tomorrow.
Cheers, Titouan On Fri, Aug 13, 2021 at 12:06 PM Titouan Rigoudy <tito...@google.com> wrote: > Hi API owners, > > We hit a snag trying to roll ship this trial in M93, and delayed to M94. > Details at the end for those interested. > > Separately, given the switch from a 6-week to a 4-week release cadence, I > believe the maximum trial length in milestones should be extended to keep a > similar length in calendar days. Instead of 5 milestones, it seems logical > to allow for 7 milestones instead. > > In addition, WebTransport implementers tell me that the server-side > situation is not yet sorted out. There is no easy off-the-shelf > WebTransport server for developers to use just yet. It will take some time > for the ecosystem to converge on a standard solution or two. > > Overall, *I would like to request approval to run this deprecation trial > from 94 to 101 (inclusive).* This would give developers until the end of > March 2022 to migrate. > > Details about the delay follow: > > The reason is that some developers run web apps inside intranets that > clients access through literal IP addresses (e.g. http://192.168.1.42). A > Deprecation Trial would require them to register tokens for each and every > deployment with a distinct IP address, then update the servers to serve > those tokens. This being in healthcare, updating servers is hard and comes > with a lot of red tape. In effect, it was practically impossible for them > to integrate with the trial framework in time. > > This deprecation has thus been down-scoped to cover only private network > requests made from *public* websites. Requests made from *private* > websites, such as the ones described above, can be tackled later. > > Cheers, > Titouan > > On Tue, Jun 29, 2021 at 11:09 AM Titouan Rigoudy <tito...@google.com> > wrote: > >> On Mon, Jun 28, 2021 at 4:18 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> LGTM to run a deprecation trial M93-M98 (inclusive). >>> >> >> Thanks! >> >> On Mon, Jun 28, 2021 at 4:13 PM Titouan Rigoudy <tito...@google.com> >>> wrote: >>> >>>> On Mon, Jun 28, 2021 at 3:27 PM Yoav Weiss <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> Do I understand correctly that in parallel to this deprecation trial, >>>>> you'd also remove the private network access to non-secure contexts from >>>>> origins that aren't part of the trial? (per the I2S) >>>>> >>>> >>>> Exactly. This trial would preserve the ability for certain signed-up >>>> websites to delay the deprecation for a few milestones. >>>> >>>> >>>>> Also, what are the experimentation timelines? >>>>> >>>> >>>> +Yutaka Hirano <yhir...@google.com> from WebTransport tells me they >>>> are aiming to ship in M96. I think it would be reasonable to run the trial >>>> for 2 more milestones after that. So, we would run this trial until M99 >>>> (exclusive). >>>> >>> >>> IIRC, WebTransport would provide the alternative implementation. Is that >>> correct? >>> >> >> Exactly. >> >> Cheers, >> Titouan >> >> >>> >>>> >>>>> On Mon, Jun 28, 2021 at 12:48 PM 'Titouan Rigoudy' via blink-dev < >>>>> blink-dev@chromium.org> wrote: >>>>> >>>>>> Contact emailstito...@chromium.org, cl...@chromium.org, >>>>>> mk...@chromium.org, v...@chromium.org >>>>>> >>>>>> Explainer >>>>>> https://github.com/WICG/private-network-access/blob/master/explainer.md >>>>>> >>>>>> Specificationhttps://wicg.github.io/private-network-access/ >>>>>> >>>>>> API specYes >>>>>> >>>>>> Design docs >>>>>> >>>>>> https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64 >>>>>> >>>>>> Summary >>>>>> >>>>>> Requires that private network requests for subresources may only be >>>>>> initiated from a secure context. "Private network requests" are those >>>>>> initiated from a public network, targeting a private network. Examples >>>>>> include internet to intranet requests and intranet loopbacks. This is a >>>>>> first step towards fully implementing Private Network Access: >>>>>> https://wicg.github.io/private-network-access/ >>>>>> >>>>>> >>>>>> Blink componentBlink>SecurityFeature>CORS >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS> >>>>>> >>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572 >>>>>> >>>>>> TAG review statusUnder way >>>>>> >>>>> >>>>> Seems like it's resolved :) >>>>> >>>> >>>> Mostly, indeed. It reminds me that I should poke them now that the IETF >>>> and Martin Thomson's concerns are resolved. >>>> >>>> >>>>> >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> No interoperability risks. Compatibility risk is small but >>>>>> non-negligible. UseCounters show ~0.1% of page visits 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 >>>>>> >>>>>> >>>>>> Gecko: Under consideration ( >>>>>> 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: Negative ( >>>>>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit) >>>>>> Some websites, broadly falling in the category of controller webapps for >>>>>> IoT devices, find this change incompatible with their use cases. While >>>>>> most >>>>>> use cases can be solved with tailored workarounds, some may still require >>>>>> further engagement. >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> Since this deprecation only affects non-secure contexts, however, >>>>>> this Deprecation Trial would need to allow non-secure/HTTP origins to >>>>>> sign >>>>>> up. This is a departure from established practice where Origin Trials are >>>>>> scoped to secure/HTTPS origins only. While this may open the door to >>>>>> silliness due to the lack of authentication, it seems inevitable that >>>>>> Deprecation Trials allow HTTP origins to sign up. Indeed more and more >>>>>> features of the Web Platform will be deprecated over time as their access >>>>>> is restricted to secure contexts. Each of those deprecations will >>>>>> require a >>>>>> similar setup. Note that there is no technical obstacle to this, see the >>>>>> discussion here >>>>>> <https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit#heading=h.spjnqwrphxwv> >>>>>> . >>>>>> >>>>>> >>>>>> Goals for experimentation >>>>>> >>>>>> It seems that many developers have not noticed the upcoming launch >>>>>> despite outreach efforts, and will likely only notice once Chrome ships >>>>>> the >>>>>> secure context restriction. Thus delaying the launch by a few milestones >>>>>> to >>>>>> offer more breathing room to the currently-aware developers would not >>>>>> mitigate the risk when we ship the next time. A Deprecation Trial seems >>>>>> like the logical next step. This would allow us to protect the vast >>>>>> majority of users of the web by at least requiring attackers to sign up >>>>>> for >>>>>> the trial, itself a deterrent. Simultaneously, it would give enough time >>>>>> to >>>>>> legitimate websites to work around the new restriction. Finally, it would >>>>>> allow more time for discussions should our planned solutions fail to >>>>>> adequately address developers’ concerns. >>>>>> >>>>>> >>>>>> Ongoing technical constraints >>>>>> >>>>>> The Origin Trial will only support setting tokens via headers, and >>>>>> not via a <meta> tag. This is because the opt-in status of a given >>>>>> document >>>>>> must be known at commit time, before the document has started being >>>>>> parsed. >>>>>> This is similar to the existing SharedArrayBuffer deprecation trial >>>>>> <https://developer.chrome.com/origintrials/#/view_trial/303992974847508481>. >>>>>> See also details here >>>>>> <https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit#heading=h.spjnqwrphxwv> >>>>>> . >>>>>> >>>>>> 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, Chrome OS, Android, and Android WebView)?Yes >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>> ?Not yet. Implementation is being finalized, now that WPT RFC 72 >>>>>> <https://github.com/web-platform-tests/rfcs/blob/master/rfcs/address_space_overrides.md> >>>>>> has finally been implemented with WPT PR #28870 >>>>>> <https://github.com/web-platform-tests/wpt/pull/28870>. >>>>>> >>>>>> Flag nameBlockInsecurePrivateNetworkRequests >>>>>> >>>>>> Tracking bughttps://crbug.com/986744 >>>>>> >>>>>> Launch bughttps://crbug.com/1129801 >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/5436853517811712 >>>>>> >>>>>> Links to previous Intent discussionsIntent to prototype: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJ >>>>>> Ready for Trial: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJ >>>>>> Intent to Ship: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/cPiRNjFoCag/m/DxEEN9-6BQAJ >>>>>> >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://www.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/CAPATO9eQJqk4Uss3_3fVmskEsPfVXF404Jfgp-17k60kkJkA5g%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9eQJqk4Uss3_3fVmskEsPfVXF404Jfgp-17k60kkJkA5g%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/CAPATO9eDT5RNoeTLcs_vLYzWDyDnz_t6XdEx5kVLze4R_FzLeg%40mail.gmail.com.
