Hi blink-dev, Just wanted to state here that we'll send a different intent to ship when we want to enforce that preflights succeed, instead of re-using this one (there is already an intent to deprecate thread [1]). PNA has been launching bit by bit to manage compatibility risk, and having a chromestatus entry / intents for each stage separately will help clarify the current status.
I've updated the associated chromestatus feature [2] to focus on warning-only preflights, as well. Cheers, Titouan [1] https://groups.google.com/a/chromium.org/g/blink-dev/c/FlenxUPCDec/m/T2YBn0kEBQAJ [2] https://chromestatus.com/feature/5737414355058688 On Fri, Oct 28, 2022 at 1:52 PM José Luis Campanello < jose.luis.campane...@gmail.com> wrote: > 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/CAPATO9cFi-LJwPGc%3Dv7BTsR76oG8WXw09QP%2BRi36qffYhbkB3Q%40mail.gmail.com.
