Hi there, 1. Such requests are blocked by mixed content. This launch does not change that. 2. You will want to respond 200 OK to PNA preflight requests to your private HTTPS server with the right headers. See the blog post [1] for details.
Cheers, Titouan [1] https://developer.chrome.com/blog/private-network-access-preflight/#server-side-requests On Sun, Apr 17, 2022 at 4:56 PM John Doe <class...@gmail.com> wrote: > 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/CAPATO9c3CFqFtMaYn-PuJQwKKyQCsjH8f5FPvzoDVo5yF7b%3Diw%40mail.gmail.com.
