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 <miketa...@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 <chris...@chromium.org> > wrote: > >> LGTM3 for step 1. >> >> On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor <miketa...@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 <tito...@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 <yoavwe...@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 < >>>>> blink-dev@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 <tito...@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 <miketa...@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 < >>>>>>>>> blink-dev@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 < >>>>>>>>>> miketa...@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 tito...@chromium.org, v...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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/CAPATO9doJNfQ%2BAn0%2BSLRWvU7SNmqpem0njYw66wosZwjLhC3qA%40mail.gmail.com.
