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/b1999eef-ae5c-4d90-85c0-bbcc8ddc8334n%40chromium.org.
