Contact [email protected] Explainer https://github.com/WICG/private-network-access/blob/main/explainer.md
Specificationhttps://github.com/WICG/private-network-access Summary This ships Private Network Access restrictions to Android Automotive (if BuildInfo::is_automotive), including: - Private Network Access preflight requests for subresources. See https://chromestatus.com/feature/5737414355058688, and - Private Network Access for Workers. See https://chromestatus.com/feature/5742979561029632 Note that the two above features were shipped in warning only mode, but this features will enforce the restriction, i.e. failing the main request if restrictions are not satisfied. Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess> Motivation In https://chromestatus.com/feature/5737414355058688 and https://chromestatus.com/feature/5737414355058688 we shipped private network restrictions for subresources and workers in warning-only mode. The next step was to get to the enforcement mode, i.e. failing the main requests if restrictions are not satisfied. However, we haven't been able to do that on existing platforms because there's still a fair amount of warnings being generated, and thus a considerable compatibility risk. Soon, Chrome will support a new platform, Android Automotive. The private network security is critical on this platform because it can affect users' physical safety. Since it's a new platform for Chrome, we'd like to have private network restrictions in place from the very beginning. We also don't expect any legitimate private network access use case at the moment, so we can safely ignore the compatibility risks. Initial public proposalhttps://wicg.github.io/private-network-access/ TAG reviewNone TAG review statusPending Risks Interoperability and Compatibility None *Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/143 ) *WebKit*: Positive (https://github.com/WebKit/standards-positions/issues/163 ) *Web developers*: Mixed 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*: Security This change aims to be security-positive, preventing CSRF attacks against soft and juicy targets such as router admin interfaces. It does not cover navigation requests and workers, which are to be addressed in followup launches. 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 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? None 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/+/main/docs/testing/web_platform_tests.md> ?Yes Flag name on chrome://flagsNone Finch feature nameNone Non-finch justificationNone Requires code in //chrome?False Estimated milestones Shipping on Android 119 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5082807021338624 This intent message was generated by Chrome Platform Status <https://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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiP%2BXS9J%3D8TjxQaPyEwyw7nJ7zzUZXHnXLOWNG5UuV5unUQ%40mail.gmail.com.
