[blink-dev to bcc] Hi José,
Thanks for reaching out, and sorry for the confusion! To be clear, the blog post states that this would be enabled in 107 *at the earliest*, which reflected our best estimate back when we wrote the post. We are now aiming to ship and start a deprecation trial in 109 at the earliest, if this thread gets 3 LGTMs by the end of next week. You can stay tuned here to know when this will ship, or follow along on Chromestatus [1]. The deprecation trial would allow you to request an extension until 113. Happy to answer any other questions you may have! Cheers, Titouan [1] https://chromestatus.com/feature/5737414355058688 On Mon, Oct 24, 2022 at 3:31 PM José Luis Campanello < jose.luis.campane...@gmail.com> wrote: > Hi all, > > i've been working to fix an application that will be affected by PNA > preflights (we have an application that talks to a private server and a > local -127.0.0.1- server). > > As I understood from this blog post ( > https://developer.chrome.com/blog/private-network-access-preflight/#rollout-plan), > it seems PNA preflights will be enabled starting with release 107, but i > can't find any reference as to whether it is being actually released in 107 > or later (I've seen 109, 112 and shipping on 113). I think I'm probably not > understanding correctly all the details of what I'm reading. > > Can you confirm when this feature will enabled in the standard chrome? > > > On Monday, May 30, 2022 at 6:12:42 AM UTC-3 Titouan Rigoudy wrote: > >> 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 <cpmt...@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/CAPATO9eqmxub83u9ZZiwfzdFEp0Gd3cta%2BhGXgXAWUPZtiq6Fg%40mail.gmail.com.
