Hello, is there now an updated timeline to roll out this change? Will the trial restart in Chrome 102 or a later version?
On Wednesday, March 2, 2022 at 6:36:21 PM UTC+8 Titouan Rigoudy wrote: > Hi all, > > Here's the promised doc: > https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit > > (public, comment access for committers only) > > Cheers, > Titouan > > On Thu, Feb 17, 2022 at 3:29 PM Mike Taylor <mike...@chromium.org> wrote: > >> Thanks for the update Titouan. Looking forward to reading your doc. >> >> On 2/17/22 9:25 AM, Titouan Rigoudy wrote: >> >> Hi all, >> >> Just to let you know that due to a couple issues, chief among which a >> renderer crash (crbug.com/1279376), we are rolling this feature back >> from Chrome 98. >> >> A few issues have been identified and will block our next attempt at >> shipping this. In the meantime, we gathered some useful information about >> impact and notified developers of the upcoming change. I'll write a doc >> summarizing the timeline and lessons learned, then share as appropriate >> here. >> >> Cheers, >> Titouan >> >> On Mon, Dec 6, 2021 at 5:26 PM Chris Harrelson <chri...@chromium.org> >> wrote: >> >>> LGTM3 for step 1. >>> >>> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor <mike...@chromium.org> wrote: >>> >>>> LGTM2 for step 1. >>>> >>>> On 12/6/21 5:31 AM, Titouan Rigoudy wrote: >>>> >>>> *assuming I get 2 more LGTMs, that is. >>>> >>>> On Mon, Dec 6, 2021 at 11:31 AM Titouan Rigoudy <tit...@google.com> >>>> wrote: >>>> >>>>> Thanks! I'll come back for further discussion with UKM data in hand. >>>>> >>>>> Cheers, >>>>> Titouan >>>>> >>>>> On Mon, Dec 6, 2021 at 10:58 AM Yoav Weiss <yoav...@chromium.org> >>>>> wrote: >>>>> >>>>>> I agree UKM analysis should not block step 1, as it holds little >>>>>> risk. (There's still some risks that servers will choke in the face of >>>>>> preflights, but that seems minor compared to the enforcement risk) >>>>>> >>>>>> Therefore,* LGTM1 for step 1* (preflights with no enforcement), but >>>>>> not further (yet). Please come back to this thread with any data you may >>>>>> have as a result of adding UKMs. >>>>>> >>>>>> On Fri, Dec 3, 2021 at 6:44 PM 'Titouan Rigoudy' via blink-dev < >>>>>> blin...@chromium.org> wrote: >>>>>> >>>>>>> Yoav, do you think UKM analysis should block sending preflights >>>>>>> without enforcing their success? I believe sending these will allow us >>>>>>> to >>>>>>> get more precise information on the affected websites through the >>>>>>> usecounter recorded in crrev.com/c/3310846. I can then analyze UKM >>>>>>> data and use the results to inform the decision whether and when to >>>>>>> switch enforcement on? >>>>>>> >>>>>>> Cheers, >>>>>>> Titouan >>>>>>> >>>>>>> On Thu, Dec 2, 2021 at 5:19 PM Titouan Rigoudy <tit...@google.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I agree! >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Titouan >>>>>>>> >>>>>>>> On Thu, Dec 2, 2021 at 5:17 PM Mike West <mk...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> _I_ don't think we should do that, but I'd defer to Titouan's >>>>>>>>> preference. :) >>>>>>>>> >>>>>>>>> -mike >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Dec 2, 2021 at 5:14 PM Mike Taylor <mike...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thanks - I also don't think there's a lot of value in this >>>>>>>>>> particular header being the odd-one-out, just wanted to confirm >>>>>>>>>> we're not >>>>>>>>>> going to ship "true" first and try to change that to ?1 later (which >>>>>>>>>> is >>>>>>>>>> always challenging). >>>>>>>>>> >>>>>>>>>> On 12/2/21 11:11 AM, Mike West wrote: >>>>>>>>>> >>>>>>>>>> I'm not sure it makes sense to introduce a structured header >>>>>>>>>> here, given that it's layering on top of CORS headers that I don't >>>>>>>>>> think >>>>>>>>>> there's substantial interest in changing. >>>>>>>>>> >>>>>>>>>> -mike >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Dec 2, 2021 at 4:55 PM 'Titouan Rigoudy' via blink-dev < >>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Mike, >>>>>>>>>>> >>>>>>>>>>> There is no support for structured headers so far, for >>>>>>>>>>> consistency reasons, and there has been no movement to deprecate >>>>>>>>>>> the "true" >>>>>>>>>>> value for Access-Control-Allow-Credentials. The value of such a >>>>>>>>>>> deprecation >>>>>>>>>>> seems minimal. >>>>>>>>>>> >>>>>>>>>>> I could pretty easily add support for the structured "?1" value >>>>>>>>>>> on top of the "true" token for the new >>>>>>>>>>> Access-Control-Allow-Private-Network >>>>>>>>>>> header, and specify that, but I'm not sure it would be terribly >>>>>>>>>>> useful. Do >>>>>>>>>>> you think otherwise? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Titouan >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 2, 2021 at 4:45 PM Mike Taylor <mike...@chromium.org> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Titouan, >>>>>>>>>>>> >>>>>>>>>>>> I'm curious what the plan is for structured headers. >>>>>>>>>>>> https://github.com/WICG/private-network-access/issues/45 is >>>>>>>>>>>> marked as blocked - has there been other progress or thinking >>>>>>>>>>>> behind the >>>>>>>>>>>> scenes? >>>>>>>>>>>> >>>>>>>>>>>> thanks, >>>>>>>>>>>> Mike >>>>>>>>>>>> >>>>>>>>>>>> On 11/29/21 10:36 AM, 'Titouan Rigoudy' via blink-dev wrote: >>>>>>>>>>>> >>>>>>>>>>>> Contact emails tit...@chromium.org, va...@chromium.org, >>>>>>>>>>>> cl...@chromium.org >>>>>>>>>>>> >>>>>>>>>>>> Explainer >>>>>>>>>>>> https://github.com/WICG/private-network-access/blob/main/explainer.md >>>>>>>>>>>> >>>>>>>>>>>> Specification https://wicg.github.io/private-network-access/ >>>>>>>>>>>> >>>>>>>>>>>> Design docs >>>>>>>>>>>> >>>>>>>>>>>> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit >>>>>>>>>>>> >>>>>>>>>>>> Summary >>>>>>>>>>>> >>>>>>>>>>>> Sends a CORS preflight request ahead of any private network >>>>>>>>>>>> requests for subresources, asking for explicit permission from the >>>>>>>>>>>> target >>>>>>>>>>>> server. A private network request is any request from a public >>>>>>>>>>>> website to a >>>>>>>>>>>> private IP address or localhost, or from a private website (e.g. >>>>>>>>>>>> intranet) >>>>>>>>>>>> to localhost. Sending a preflight request mitigates the risk of >>>>>>>>>>>> cross-site >>>>>>>>>>>> request forgery attacks against private network devices such as >>>>>>>>>>>> routers, >>>>>>>>>>>> which are often not prepared to defend against this threat. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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 Pending >>>>>>>>>>>> >>>>>>>>>>>> Risks >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>> >>>>>>>>>>>> The main interoperability risk, as always, is if other browser >>>>>>>>>>>> engines do not implement this. Compat risk is straightforward: web >>>>>>>>>>>> servers >>>>>>>>>>>> that do not handle the new preflight requests will eventually >>>>>>>>>>>> break, once >>>>>>>>>>>> the feature ships. The plan to address this is as follows: 1. Send >>>>>>>>>>>> preflight request, ignore result, always send actual request. >>>>>>>>>>>> Failed >>>>>>>>>>>> preflight requests will result in a warning being shown in >>>>>>>>>>>> devtools. 2. >>>>>>>>>>>> Wait for 3 milestones. 3. Gate actual request on preflight request >>>>>>>>>>>> success, >>>>>>>>>>>> with deprecation trial for developers to buy some more time. 4. >>>>>>>>>>>> End >>>>>>>>>>>> deprecation trial 4 milestones later. UseCounters: >>>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/3753 >>>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/3755 >>>>>>>>>>>> https://chromestatus.com/metrics/feature/timeline/popularity/3757 >>>>>>>>>>>> The above measure pages that make at least one private network >>>>>>>>>>>> request for >>>>>>>>>>>> which we would now send a preflight request. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Gecko: Worth prototyping ( >>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/143) >>>>>>>>>>>> >>>>>>>>>>>> WebKit: No signal ( >>>>>>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-November/032040.html) >>>>>>>>>>>> >>>>>>>>>>>> Pending response. >>>>>>>>>>>> >>>>>>>>>>>> Web developers: No signals Anecdotal evidence so far suggests >>>>>>>>>>>> that most web developers are OK with this new requirement, though >>>>>>>>>>>> some do >>>>>>>>>>>> not control the target endpoints and would be negatively impacted. >>>>>>>>>>>> >>>>>>>>>>>> Other signals: >>>>>>>>>>>> >>>>>>>>>>>> Ergonomics >>>>>>>>>>>> >>>>>>>>>>>> None. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Activation >>>>>>>>>>>> >>>>>>>>>>>> Gating access to the private network overnight on preflight >>>>>>>>>>>> requests would likely result in widespread breakage. This is why >>>>>>>>>>>> the plan >>>>>>>>>>>> is to first send requests but not act on their result, giving >>>>>>>>>>>> server >>>>>>>>>>>> developers time to implement code handling these requests. >>>>>>>>>>>> Deprecation >>>>>>>>>>>> warnings will be surfaced in DevTools to alert web/client >>>>>>>>>>>> developers when >>>>>>>>>>>> the potential for breakage later on is detected. Enforcement will >>>>>>>>>>>> be turned >>>>>>>>>>>> on later (aiming for 3 milestones), along with a deprecation trial >>>>>>>>>>>> for >>>>>>>>>>>> impacted web developers to buy themselves some more time. >>>>>>>>>>>> Experience >>>>>>>>>>>> suggests a large fraction of developers will not notice the >>>>>>>>>>>> advance >>>>>>>>>>>> deprecation warnings until things break. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Security >>>>>>>>>>>> >>>>>>>>>>>> This change aims to be security-positive, preventing CSRF >>>>>>>>>>>> attacks against soft and juicy targets such as router admin >>>>>>>>>>>> interfaces. DNS >>>>>>>>>>>> rebinding threats were of particular concern during the design of >>>>>>>>>>>> this >>>>>>>>>>>> feature: >>>>>>>>>>>> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Debuggability >>>>>>>>>>>> >>>>>>>>>>>> Relevant information (client and resource IP address space) is >>>>>>>>>>>> already piped into the DevTools network panel. Deprecation >>>>>>>>>>>> warnings and >>>>>>>>>>>> errors will be surfaced in the DevTools issues panel explaining >>>>>>>>>>>> the problem >>>>>>>>>>>> when it arises. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>> ? Yes >>>>>>>>>>>> >>>>>>>>>>>> DevTrial instructions >>>>>>>>>>>> https://github.com/WICG/private-network-access/blob/main/HOWTO.md >>>>>>>>>>>> >>>>>>>>>>>> Flag name PrivateNetworkAccessRespectPreflightResults >>>>>>>>>>>> >>>>>>>>>>>> Requires code in //chrome? False >>>>>>>>>>>> >>>>>>>>>>>> Tracking bug https://crbug.com/591068 >>>>>>>>>>>> >>>>>>>>>>>> Launch bug https://crbug.com/1274149 >>>>>>>>>>>> >>>>>>>>>>>> Estimated milestones >>>>>>>>>>>> DevTrial on desktop 98 >>>>>>>>>>>> DevTrial on android 98 >>>>>>>>>>>> >>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>> https://chromestatus.com/feature/5737414355058688 >>>>>>>>>>>> >>>>>>>>>>>> Links to previous Intent discussions Intent to prototype: >>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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+...@chromium.org. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%40mail.gmail.com >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%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+...@chromium.org. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%40mail.gmail.com >>>>>>>>>>> >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%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+...@chromium.org. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9ePgpof%2BBDWS9X7sfHHAqgc6Arem3b78ZGC%3D%2Bp4jB6_AQ%40mail.gmail.com >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9ePgpof%2BBDWS9X7sfHHAqgc6Arem3b78ZGC%3D%2Bp4jB6_AQ%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+...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e557fb7-5b1d-20bc-aae5-65526ca8efb7%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e557fb7-5b1d-20bc-aae5-65526ca8efb7%40chromium.org?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/d4d6be2a-bd24-40c1-b682-3d2c32b508d9n%40chromium.org.
