Intent to Ship: Local Network Access allowing same-origin fetches to potentially trustworthy origins

[Jonathan Hao]

Note that Private Network Access is in the process of being renamed to Local Network Access, so you may see inconsistent names for the time being.

Explainer

https://github.com/WICG/local-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/local-network-access/#secure-context-restriction

Design docs

Local Network Access: Allow Potentially Trustworthy Same-Origin Fetches

Private Network Access: Preflight requests for subresources

Summary

Allow same-origin local network fetches to potentially-trustworthy origins and do not send preflights for them. We currently send preflights before all local network requests, but ignore the results, as proposed in Intent to Ship: Private Network Access preflight requests for subresources.

Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

TAG review

https://github.com/w3ctag/design-reviews/issues/572

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

This change reduces the compatibility risk of enforcing preflight results on private network requests as we now send fewer preflights for private network requests, so it’s less likely to break websites.

Gecko: No signal about this specific change.

WebKit: No signal about this specific change.

Web developers: No signal about this specific change, but they should be happy since this reduces compatibility risks.

Other signals:

Ergonomics

None.

Activation

We plan to ship this change directly to M114 as this relaxes the previous restrictions.

Security

This change is limited to potentially trustworthy origins. Proof of certificate protects users from DNS rebinding.

WebView application risks

There’s no plan to ship Local Network Access on WebView.

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.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

Not on Android WebView given previous difficulty in supporting PNA changes due to the lack of support for deprecation trials. Support for WebView will be considered separately.

Is this feature fully tested by web-platform-tests?

No

DevTrial instructions

No DevTrial for this change

Flag name

LocalNetworkAccessAllowPotentiallyTrustworthySameOrigin

Requires code in //chrome?

Only for metric logging

Tracking bug

https://crbug.com/1382068

Launch bug

https://crbug.com/1274149

Estimated milestones

DevTrial on desktop

114

DevTrial on Android

114

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

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/ArrhiKB8XF0/m/cGO-5B1IAwAJ

Intent to prototype (all preflights): https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ

Intent to Experiment (all preflights): https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiP%2Bew8hADZkdQ3AO6P9WzfGuzLPp9JjJZqztV5oZmaK8oQ%40mail.gmail.com

This intent message was generated by Chrome Platform Status.v

[Jonathan Hao]

Sorry for the confusion about the spec name.  We've recently changed our stance https://github.com/WICG/local-network-access/issues/91#issuecomment-1494704528 and the spec name is still unsettled until we hear back from other browser vendors. Both Private Network Access and Local Network Access mean the same thing for now.

[Yoav Weiss]

On Wed, Apr 5, 2023 at 2:02 PM Jonathan Hao <ph...@chromium.org> wrote:

Sorry for the confusion about the spec name.  We've recently changed our stance https://github.com/WICG/local-network-access/issues/91#issuecomment-1494704528 and the spec name is still unsettled until we hear back from other browser vendors. Both Private Network Access and Local Network Access mean the same thing for now.

On Wed, Apr 5, 2023, 12:22 Jonathan Hao <ph...@chromium.org> wrote:

Note that Private Network Access is in the process of being renamed to Local Network Access, so you may see inconsistent names for the time being.

Explainer

https://github.com/WICG/local-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/local-network-access/#secure-context-restriction

Design docs

Local Network Access: Allow Potentially Trustworthy Same-Origin Fetches

Private Network Access: Preflight requests for subresources

Summary

Allow same-origin local network fetches to potentially-trustworthy origins and do not send preflights for them. We currently send preflights before all local network requests, but ignore the results, as proposed in Intent to Ship: Private Network Access preflight requests for subresources.

Can you expand on this change? Would this result in not sending preflights IFF their origin is the same as the document's origin?

Would this also work for embedded documents? (resulting in a single preflight for the document's resource, but not subresource)

Or would it be restricted to cases where the user explicitly went to a local network top-level document? (Or something else entirely, and I misunderstood)

 

--
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/CABsQ2jGAcTV4CUKKwsYYfnQRiQ_W6KK9L4OQ5uNHNGn3WMhZ5Q%40mail.gmail.com.

[Jonathan Hao]

On Wed, Apr 12, 2023, 12:45 Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, Apr 5, 2023 at 2:02 PM Jonathan Hao <ph...@chromium.org> wrote:

Sorry for the confusion about the spec name.  We've recently changed our stance https://github.com/WICG/local-network-access/issues/91#issuecomment-1494704528 and the spec name is still unsettled until we hear back from other browser vendors. Both Private Network Access and Local Network Access mean the same thing for now.

On Wed, Apr 5, 2023, 12:22 Jonathan Hao <ph...@chromium.org> wrote:

Note that Private Network Access is in the process of being renamed to Local Network Access, so you may see inconsistent names for the time being.

Explainer

https://github.com/WICG/local-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/local-network-access/#secure-context-restriction

Design docs

Local Network Access: Allow Potentially Trustworthy Same-Origin Fetches

Private Network Access: Preflight requests for subresources

Summary

Allow same-origin local network fetches to potentially-trustworthy origins and do not send preflights for them. We currently send preflights before all local network requests, but ignore the results, as proposed in Intent to Ship: Private Network Access preflight requests for subresources.

Can you expand on this change? Would this result in not sending preflights IFF their origin is the same as the document's origin?

Yes. Preflights will not be sent iff the origin is the same as the documents' origin and the origin is potentially trustworthy.

Would this also work for embedded documents? (resulting in a single preflight for the document's resource, but not subresource)

Or would it be restricted to cases where the user explicitly went to a local network top-level document? (Or something else entirely, and I misunderstood)

Yes it works for embedded documents too. The preflight for iframe navigation is being worked on separately in https://crbug.com/1291252.  If the subresource is same origin to the embedded document then it doesn't require additional preflights.

[Yoav Weiss]

LGTM1

Thanks for explaining! :)

[Jonathan Hao]

Hi Yoav,

It's been 2 weeks but no other API owners have replied.  Do you know if there's any blockers?  Should we ping the other API owners or could you help us?

Best,

Jonathan

[Mike Taylor]

LGTM2 (sorry for the delay, it seems this fell out of our review queue).

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

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/288b0a13-287a-0716-13a6-d878bbf73fe4%40chromium.org.