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/CAPATO9eonNqQNS_NdmsWctt6W8yQyRWhH6cbytU%2BEifF_1iM5A%40mail.gmail.com.
