Intent to Ship: Private Network Access preflight requests for subresources

[Titouan Rigoudy]

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

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?

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.

[Joe Medley]

Titouan,

Will the default for the runtime flag be 'Enabled' in 98?

The DevTrial number should reflect when the flag was first available. 'Shipping' refers to when it can be used in production without web developers or users doing anything. This can mean the flag was removed or it can mean the flag's default was changed to 'Enabled'.

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--
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.

[Erik Anderson]

Given this specifically calls out subresources and the design doc lists “the case of navigations” as “followup work,” you’re explicitly not touching how navigations (top-level or an iframe) work at this stage, correct?

 

I expect the most significant compat impact to come from Windows apps that delegate to the default browser to do a login flow where the last step of the auth flow is making a request to a localhost HTTP server to pass back to the app an auth ticket.

 

I anticipate most of those are top-level navigations, but my experience with the first version of Microsoft Edge (pre-Chromium) which prevented localhost loopback for subresources (including iframes), there are apps that handle it some other way which we broke. Some of those may have been passing it back via an iframe navigation (I don’t recall—it was 6+ years ago) in which case they’ll potentially still work after this change.

 

The Microsoft Edge team will work to reach out to Microsoft teams that are potentially impacted. If the roadmap is going to eventually force a preflight before allowing a navigation to a private network origin, we would ideally include clear guidance on what’s likely coming there as well. Is there a general timeline you have in mind for expanding this to navigations as well?

--

[Titouan Rigoudy]

Thanks for the responses!

Joe: the `PrivateNetworkAccessSendPreflights` feature flag will be enabled by default in M98 (if this intent gets 3 LGTMs). The `PrivateNetworkAccessRespectPreflightResults` will be enabled by default later, I am aiming for M101.

On Tue, Nov 30, 2021 at 11:42 PM Erik Anderson <Erik.A...@microsoft.com> wrote:

Given this specifically calls out subresources and the design doc lists “the case of navigations” as “followup work,” you’re explicitly not touching how navigations (top-level or an iframe) work at this stage, correct?

That is correct.

 

I expect the most significant compat impact to come from Windows apps that delegate to the default browser to do a login flow where the last step of the auth flow is making a request to a localhost HTTP server to pass back to the app an auth ticket.

 

I anticipate most of those are top-level navigations, but my experience with the first version of Microsoft Edge (pre-Chromium) which prevented localhost loopback for subresources (including iframes), there are apps that handle it some other way which we broke. Some of those may have been passing it back via an iframe navigation (I don’t recall—it was 6+ years ago) in which case they’ll potentially still work after this change.

If they indeed use either top-level or iframe navigations, then they will be unaffected by this change.

 

The Microsoft Edge team will work to reach out to Microsoft teams that are potentially impacted. If the roadmap is going to eventually force a preflight before allowing a navigation to a private network origin, we would ideally include clear guidance on what’s likely coming there as well. Is there a general timeline you have in mind for expanding this to navigations as well?

I don't have a very clear timeline yet, but I wish to tackle nested navigations in particular in M100.

Cheers,

Titouan

[Yoav Weiss]

On Monday, November 29, 2021 at 4:37:24 PM UTC+1 Titouan Rigoudy wrote:

Contact emails

tit...@chromium.org, vahl@chromium.org, clamy@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

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.

Would that include deprecation reports?

 

2. Wait for 3 milestones. 3. Gate actual request on preflight request success, with deprecation trial for developers to buy some more time.

We'd also need to communicate this widely in order to get relevant developers to sign up for the deprecation trial. UKM investigation can help us focus efforts on that front.

 

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

That's a lot of usage :/ I remember you did a bunch of UKM investigations in the past. Did that include this case as well?

[Titouan Rigoudy]

Thanks for the response Yoav, answers inline.

On Wed, Dec 1, 2021 at 1:22 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Monday, November 29, 2021 at 4:37:24 PM UTC+1 Titouan Rigoudy 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

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.

Would that include deprecation reports?

Not so far. Blink is not made aware of the warnings yet, they go from the network service to the browser process and then straight to devtools. More wiring would be needed for Blink to notice the warning and send a deprecation report.

 

 

2. Wait for 3 milestones. 3. Gate actual request on preflight request success, with deprecation trial for developers to buy some more time.

We'd also need to communicate this widely in order to get relevant developers to sign up for the deprecation trial. UKM investigation can help us focus efforts on that front.

That is true. I am planning to write a blog post on web.dev or the chrome blog to help raise awareness.

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

That's a lot of usage :/ I remember you did a bunch of UKM investigations in the past. Did that include this case as well?

I did not look at these metrics during my previous UKM analysis - I was focusing on non-secure contexts initiating private network requests. I can look into them again however, and try to reach out to the biggest users before enforcement is turned on.

Cheers,

Titouan

[Daniel Bratell]

This sounds like a change that would disproportionately affect "enterprise" so it's probably best to involve the Chrome enterprise team sooner rather than later. The numbers are higher than I would have expected. Makes me wonder if there is some specific source of those. I would have expected it to be rarer than that to embed a resource from a private network.

/Daniel

--

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/CAPATO9f6QS%3D4oJqnJg6NR%3DpoKcT149h8LeiSzkfd%3Dqq8qV6pLA%40mail.gmail.com.

[Titouan Rigoudy]

Good idea, I will alert the enterprise team of the upcoming change.

There are also existing enterprise policies [1] [2] introduced for the previous change (secure context restriction) that also work in this context to disable the new behavior entirely. Their descriptions need a little updating for it to be clear that they apply to this change as well. Filed crbug.com/1275567 to fix that.

As for specific sources: UKM data might not tell us unfortunately, since AFAIU that data is not reported by enterprise deployments?

Cheers,

Titouan

[1] https://chromeenterprise.google/policies/#InsecurePrivateNetworkRequestsAllowed

[2] https://chromeenterprise.google/policies/#InsecurePrivateNetworkRequestsAllowedForUrls

[Yoav Weiss]

https://groups.google.com/a/chromium.org/g/blink-dev/c/xWVtdGDLz_Q/m/kyofZuRfBAAJ may be a relevant conversation on that front. It may be worthwhile to talk to Andrew to see what they did on that front.

[Titouan Rigoudy]

Thanks for the pointer! I've reached out and will see what I can do.

Cheers,

Titouan

[Mike Taylor]

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

--
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.

[Titouan Rigoudy]

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

[Mike West]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%40mail.gmail.com.

[Mike Taylor]

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).

[Mike West]

_I_ don't think we should do that, but I'd defer to Titouan's preference. :)

-mike

[Titouan Rigoudy]

I agree!

Cheers,

Titouan

[Titouan Rigoudy]

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

[Yoav Weiss]

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.

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.

[Titouan Rigoudy]

Thanks! I'll come back for further discussion with UKM data in hand.

Cheers,

Titouan

[Titouan Rigoudy]

*assuming I get 2 more LGTMs, that is.

[Mike Taylor]

LGTM2 for step 1.

[Chris Harrelson]

LGTM3 for step 1.

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.

[Titouan Rigoudy]

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

[Mike Taylor]

Thanks for the update Titouan. Looking forward to reading your doc.

[Titouan Rigoudy]

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

[Logan Wei]

Hello,  is there now an updated timeline to roll out this change?  Will the trial restart in Chrome 102 or a later version?  

[Titouan Rigoudy]

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

[John Doe]

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 ?

[Titouan Rigoudy]

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

[John Doe]

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.

[Martin H]

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

[Titouan Rigoudy]

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

[Andrew Boeger]

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. 

[Titouan Rigoudy]

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?

[Who Cares]

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:

[José Luis Campanello]

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?

[Titouan Rigoudy]

[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

[Titouan Rigoudy]

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

[José Luis Campanello]

Thanks for the response!!! Have a nice weekend!

[Titouan Rigoudy]

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

[Scott Weber]

Forgive me if this is not the correct place to ask... 

I seem to have stumbled across this conversation trying to find answers (this thread looks like an email archive chain).

I am new to this platform of getting early information about upcoming changes.

Originally, PNA was supposed to "go live" in Version 113.  When I heard about it back in Nov '22, we tested it in Chrome v104 and placed support in our firmware back then.

So, is this now what could be called "on hold" ? 

(while we updated our firmware, there is no assurance the 1000's and 1000's of devices in the wild are being updated in a timely manner)

On Thursday, April 6, 2023 at 3:58:02 AM UTC-5 Titouan Rigoudy wrote:

Just wanted to state here that we'll send a different intent to ship 

What is "intent to ship" ?   And what is meant my "send"?  Send to who?  Is there a mailing list?

Titouan and others mention things like M100, M101.  Is this the same designation as version number (v104, and v113).

In summary, my supervisor is asking me to find out if we need to be ready to tell a plethora of customers they have to upgrade our firmware when it stops working in the next day or two  (or have doc ready telling them how to disable this requirement).

Please, could someone give a brief tutorial to a newbie on PNA and how to be "in the loop" on these things?

Thanks.

[Scott Weber]

Grammar correction, sorry:

"a brief tutorial to a newbie on the status of PNA and..."

[Titouan Rigoudy]

[blink-dev@ to bcc]

Hi Scott,

Thanks for reaching out. Answers inline below.

On Mon, Apr 24, 2023 at 9:32 PM Scott Weber <scott...@gmail.com> wrote:

Grammar correction, sorry:

"a brief tutorial to a newbie on the status of PNA and..."

On Monday, April 24, 2023 at 2:13:59 PM UTC-5 Scott Weber wrote:

Forgive me if this is not the correct place to ask... 

I seem to have stumbled across this conversation trying to find answers (this thread looks like an email archive chain).

I am new to this platform of getting early information about upcoming changes.

Originally, PNA was supposed to "go live" in Version 113.  When I heard about it back in Nov '22, we tested it in Chrome v104 and placed support in our firmware back then.

So, is this now what could be called "on hold" ? 

The timeline has been paused, but work has not. We are currently working on reducing the compatibility impact of the change, i.e. the amount of websites that would be broken by it. Were we to enforce that PNA preflights must succeed tomorrow, too many existing websites would experience issues.

 

(while we updated our firmware, there is no assurance the 1000's and 1000's of devices in the wild are being updated in a timely manner)

On Thursday, April 6, 2023 at 3:58:02 AM UTC-5 Titouan Rigoudy wrote:

Just wanted to state here that we'll send a different intent to ship 

What is "intent to ship" ?   And what is meant my "send"?  Send to who?  Is there a mailing list?

This email thread is entitled "Intent to ship". I sent it to this mailing list (blin...@chromium.org) to announce that we were planning to change Chromium's web-facing behavior, and to get approval for this change.

See this blog post for an in-depth explanation of Chromium's launch process: https://blog.chromium.org/2019/11/intent-to-explain-demystifying-blink.html

 

Titouan and others mention things like M100, M101.  Is this the same designation as version number (v104, and v113).

That's right. M stands for milestone.

 

In summary, my supervisor is asking me to find out if we need to be ready to tell a plethora of customers they have to upgrade our firmware when it stops working in the next day or two  (or have doc ready telling them how to disable this requirement).

Please, could someone give a brief tutorial to a newbie on PNA and how to be "in the loop" on these things?

My previous email was trying to clarify that there will be no further changes to PNA preflights without a new Intent to Ship thread and associated chromestatus.com feature. Nothing will change in 113, and there is no emergency for you to jump on right now. You can stay in the loop either by looking at chromestatus.com or by following along on this mailing list (blin...@chromium.org).

Cheers,

Titouan

 

Thanks.

[Scott Weber]

Titouan, 

Excellent.  

Since I am now subscribed to this blog, I will be aware of these changes. ( although google SSO used my personal email, not my employer)

I was (and still am) cautious about getting ALL the changes, since I'm sure there are hundreds.  And our little embedded web server doesn't have to be concerned with most of them...  but that's off topic :-)

 Thanks for the details in my other, off topic, questions as well.

-Scott 

[Scott Weber]

Titouan,  et.al.

Is this still awaiting more feedback, and/or another intent to ship?

This post:  https://developer.chrome.com/blog/private-network-access-update/ was brought to my attention by our marketing department, but appears to be concerned with mixed content.  (I do not expect our market department to be tech-savy enough to understand the difference)

But that update does mention that RFC1918 also addresses 

"websites now have to explicitly request a grant from servers on private networks before being allowed to send arbitrary requests."

which would also include this topic.

Mixed content won't be an issue our company, but preflight will.

Since we have a large installation of devices already out in the wild, our support and marketing team are watching carefully to see if 'preflight' becomes implemented.  Because it will generate breakage at a level of a hundred thousand or more, resulting in companies having to re-certify firmware before deploying it (a process that can take up to 9 months).

And since I'm still trying to learn how to filter all the groups emails, I'm not sure I understand that I will see when preflight is ready for the next phase.

So that is why I ask :-)

Thanks.

[Titouan Rigoudy]

[blink-dev@ to bcc]

Hi Scott,

I'll reply off list.

Cheers,

Titouan

[Paweł Badeński]

Do I understand correctly that access to access to private network endpoints from secure contexts (https) is currently not in scope? That's my interpretation of https://developer.chrome.com/blog/private-network-access-update/#cors-preflight-requests which is in "Plans for the future" section. Is there any more clarity of the timeline?