Apologies for the delay.. LGTM to run the deprecation trial M94-M101
On Wed, Aug 25, 2021 at 10:09 AM Titouan Rigoudy <tito...@google.com> wrote: > 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/CAL5BFfW8Rbxrc9Q13TsB7UhO3hfseJjeTdTtaDB39QsmhfBT5A%40mail.gmail.com.
