1. In Chrome 98, there were no preflight requests when accessing from public HTTPS to private HTTP, will the same be true in the final version? 2. In the case when I have a private HTTPS server that I want everyone to have access to (also via public HTTP), what options do I have ?
On Wednesday, April 6, 2022 at 8:23:58 PM UTC+3 Titouan Rigoudy wrote: > Hi all, > > Thanks for the timely question, I was about to send an update here. > > We have fixed nearly all of the blockers identified in the above doc. The > only outstanding issue is the aforementioned crash, which required a bit > more design work than the rest. That work has been completed and CLs to fix > the problem are now in review; they should land shortly and make it in > Chrome 102. > > We would like to ship again in Chrome 102 in warning-only mode, just as we > last tried in Chrome 98. Preflights will be sent but their results will not > be enforced. Failed preflights will show warnings in DevTools, but requests > will otherwise continue unimpeded. > > Things will stay that way for at least 3 milestones. We will gather > compatibility data by monitoring failed preflights, then circle back here > to garner approvals to turn on enforcement. That launch will be accompanied > by a deprecation trial for web developers to sign up for a time extension > if they failed to notice the warnings in time. > > Cheers, > Titouan > > On Wed, Apr 6, 2022 at 3:29 AM Logan Wei <shapi...@gmail.com> wrote: > >> 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/0f40e36e-2103-420c-ae04-5f8d5c54c818n%40chromium.org.
