Meant to link to this other thread [1] as the one on which we need 3 LGTMs.
Cheers, Titouan [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/FlenxUPCDec/m/T2YBn0kEBQAJ On Fri, Oct 28, 2022 at 6:22 AM Titouan Rigoudy <tito...@google.com> wrote: > [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/CAPATO9eR0jcRsXRRi8t_ntrSfBkPQYJawOSRtwCmyJGW3n%2BGmA%40mail.gmail.com.
