Thanks for the response!!! Have a nice weekend! On Friday, October 28, 2022 at 7:25:20 AM UTC-3 Titouan Rigoudy wrote:
> 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 <tit...@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....@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/962ce389-9f7f-42f2-91b4-cc8c9e6a0220n%40chromium.org.
