Hi there, Thanks for reaching out.
Andrew: Indeed, this was crbug.com/1329248, apologies for the oversight. The change has been rolled back on Friday. Chrome 102 should pick up the configuration change upon restart. cpmtatest: by default, script fetches are made in no-cors mode with credentials. I believe [1] and [2] are the relevant specification bits here. If you think this should not be how PNA works, please file an issue in the GitHub repo [3]. Cheers, Titouan [1] https://html.spec.whatwg.org/multipage/urls-and-fetching.html#create-a-potential-cors-request [2] https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-classic-script [3] https://github.com/WICG/private-network-access/issues On Mon, May 30, 2022 at 10:46 AM Who Cares <cpmtat...@gmail.com> wrote: > Hi, > Now when chrome 102 is out I wanted to test it so I ran it with > *--enable-features=PrivateNetworkAccessRespectPreflightResults* > There's one thing I'm trying to understand, > I have an HTML page with a script tag, the src of this tag points to a > more private network, the default behavior of script tags is not to trigger > CORS and since v102 they do trigger it which is expected. > My question is: > I'm getting this error: *"Response to preflight request doesn't pass > access control check: The value of the 'Access-Control-Allow-Credentials' > header in the response is '' which must be 'true' when the request's > credentials mode is 'include'."* > I never asked to send credentials in my script tag, I guess I can force > not send it by adding *crossorigin="" *to the tag but shouldn't the > default behavior be not to send it with credentials? > On Saturday, May 28, 2022 at 12:47:02 AM UTC+3 Andrew Boeger wrote: > >> Hi all - >> >> Just want to call out that this assumption... >> Chrome 102 should also not break anything, since we are sending >> preflights in warning-only mode. If the preflight fails, a warning is >> displayed in DevTools but the request proceeds as before >> ... turned out to be false. >> >> The change recently deployed DOES break things. It has broken our >> internal admin tool our CS teams use to manage customer accounts. >> >> Bug opened here > >> https://bugs.chromium.org/p/chromium/issues/detail?id=1329248 >> >> In meantime, I have my users moving to other browsers because this has >> broken a critical function for them. >> >> On Wednesday, April 20, 2022 at 3:47:36 AM UTC-5 Titouan Rigoudy wrote: >> >>> Hi there, >>> >>> John: that's due to another facet of Private Network Access (not this >>> intent) that started a deprecation trial in Chrome 94. See >>> https://chromestatus.com/feature/5436853517811712. Unless signed up for >>> the deprecation trial, HTTP websites are no longer allowed to make any >>> requests to private servers. >>> >>> Martin: there will be no breaking change in Chrome 101. I need to update >>> the blog post to make the new timeline clearer. >>> >>> Chrome 102 should also not break anything, since we are sending >>> preflights in warning-only mode. If the preflight fails, a warning is >>> displayed in DevTools but the request proceeds as before. As explained >>> above, this will remain the case until at least Chrome 105, at which point >>> we may turn on enforcement: when a preflight fails, the request should not >>> be sent and fail. That remains subject to compatibility risk evaluation. >>> >>> Cheers, >>> Titouan >>> >>> On Wed, Apr 20, 2022 at 3:06 AM Martin H <mrtn...@gmail.com> wrote: >>> >>>> Hi Titouan, Blink Devs, >>>> >>>> Thank you for this news above. >>>> I work for a software vendor affected by this change, our software >>>> installs a small (https://localhost:60500) web server on a users local >>>> machine and our https:// SAAS web application connects to this to >>>> hand off various features >>>> We were under the impression this change was to occur in Chrome 101 and >>>> have been moving to that timeline rapidly but reading the above I >>>> understand this has changed (confusingly though much of the documentation >>>> online still carries older dates and talks about the change as early as 101 >>>> or 102. ) >>>> >>>> Should I now understand that *if* this makes Chrome 102 as hoped, you >>>> will have 3 mile stone releases (aka 102, 103, 104 ) with an intent to ship >>>> "private network access" changes in 105? >>>> I would understand it's just an estimate based on feedback around this >>>> change but as it stands our business is anticipating change as early as >>>> next week as this is when 101 was due to ship production. >>>> it would therefore be extremely beneficial if we understand we have >>>> more time to work with customers around this, we have produced updated >>>> compliant local components on our end and released this in the past few >>>> weeks but as you might expect we need time to address this with every >>>> single one of our customers, as Chromium based browsers form the >>>> overwhelming majority of users. >>>> >>>> Ultimately my requirement is to advise customers on the change as best >>>> as possible, including how to ensure the change is not deployed as some >>>> will need time to update their entire fleets. >>>> When I install Chrome dev 102 build, it seems like our software still >>>> works as is today. I assume as it's not on yet. Would someone be able to >>>> state which flags I should enable to replicate what will happen when this >>>> change goes live? >>>> >>>> Is it just the #block-insecure-private-network-requests >>>> Do I need to >>>> configure #private-network-access-send-preflights or >>>> #private-network-access-respect-preflight-results >>>> Today all these settings are just "Default >>>> >>>> Thanks in advance, please let me know if there is a better forum for >>>> this request. >>>> Martin >>>> >>>> >>>> On Wednesday, April 20, 2022 at 3:28:37 AM UTC+10 John Doe wrote: >>>> >>>>> Sorry seems I accidently switched the S sides in the first question, I >>>>> meant from public HTTP to private HTTPS so it shouldn't be mixed content, >>>>> and in such case there's no preflight request. >>>>> As I mentioned I installed chrome 98 to test it, when accessing a >>>>> resource from public HTTPS to private HTTPS there's a preflight request >>>>> but >>>>> no such request on an access from public HTTP to private HTTPS. >>>>> >>>>> On Tuesday, April 19, 2022 at 7:27:42 PM UTC+3 Titouan Rigoudy wrote: >>>>> >>>>>> 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 <clas...@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/CAPATO9enAc0x9xe8X2_Cn14m2qs%2BwpJTNc1%2BGevABUE%2B5AP95A%40mail.gmail.com.
