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/21b56d48-59c7-4934-86ef-336f8a0e7fcen%40chromium.org.
