No worries, thanks for the reply! We'll announce that then. Cheers, Titouan
On Wed, Aug 25, 2021 at 12:41 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > 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/CAPATO9eDM1eK9fRSNHyHM81JRWyb0KXeG3POX%2Bq7Zvn0LHDnBw%40mail.gmail.com.
