Contact emails...@chromium.org, cl...@chromium.org, tito...@chromium.org Explainer https://github.com/iVanlIsh/private-network-access/blob/main/explainer.md
Specificationhttps://wicg.github.io/private-network-access Design docs https://docs.google.com/document/d/1Q18g4fZoDIYQ9IuxlZTaItgkzfiz_tCqaEAI8J3Y1WY/edit 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 componentBlink>SecurityFeature>CORS>PrivateNetworkAccess <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess> 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 reviewhttps://github.com/w3ctag/design-reviews/issues/751 TAG review statusPending 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?No 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 bughttps://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 <https://chromestatus.com/>. -- Yifan -- 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/CAG-zKU8KUwkK_v0UW8oaGavcqN-4dUKxv0Nq4RL2osfQpRcn2Q%40mail.gmail.com.
