Intent to Prototype: Private Network Access permission to relax mixed content

218 views

Skip to first unread message

Yifan Luo

unread,

Jun 28, 2022, 10:28:23 AM6/28/22

to gle...@chromium.org, Camille Lamy, Titouan Rigoudy, Jonathan Hao, Mike West, chrome-security-owp-team

Summary

In order to establish connections to devices on a local network that do not have globally unique names, and therefore cannot obtain TLS certificates, this feature introduces a new option to `fetch()` to declare a developers' intent to talk to such a device, a new policy-controlled feature to gate each sites' access to this capability, and new headers for the server's preflight response to provide additional metadata.

Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

Motivation

We've gotten substantial negative feedback during our deprecation trial around the secure context restriction. Large group of local devices show out to be not able to obtain TLS certificates for various of reasons. With the interaction of mixed content restriction, we're left with two options: 1. Remove the restriction, which would give active network attackers the ability to initiate requests to network devices from user's machines. 2. Relax the mixed content restriction for the specific case of private network resources. The former would weaken everyone's security. The latter can be effectively governed by users, limiting the risk to those who need to accept it.

Initial public proposal

https://github.com/WICG/private-network-access/issues/23

TAG review

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

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: Positive (https://github.com/WICG/private-network-access/issues/23)

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

Relevant information (client and resource IP address space) is already piped into the DevTools network panel. We’ll likely also represent the permission state in the settings pages.

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

Flag name

Requires code in //chrome?

True

A new permission prompt is introduced which will show after a success PNA preflight response. An allowance will be permanently cached in the permission setting for a certain origin accessing a certain local device. Prompt will should a second time with a "Don't show again." check box after a denial.

Tracking bug

https://crbug.com/1338439

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5954091755241472

This intent message was generated by Chrome Platform Status.

Yifan

Reply all

Reply to author

Forward

0 new messages