Intent to Prototype: Private Network Access restrictions for automotive

[Jonathan Hao]

Contact emails

ph...@chromium.org

Explainer

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

Specification

https://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 component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

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 proposal

https://wicg.github.io/private-network-access/

TAG review

None

TAG review status

Pending

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?

Yes

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

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.