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

314 views
Skip to first unread message

Yifan Luo

unread,
Jan 26, 2024, 5:08:00 AMJan 26
to gle...@chromium.org, Jonathan Hao, Camille Lamy

Contact emails

l...@chromium.orgcl...@chromium.org

Explainer

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

Specification

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

Design docs


https://docs.google.com/document/d/1Q18g4fZoDIYQ9IuxlZTaItgkzfiz_tCqaEAI8J3Y1WY/edit
https://github.com/WICG/private-network-access/blob/main/permission_prompt/security_privacy_self_review.md

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

TAG review

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

TAG review status

Issues addressed

Chromium Trial Name

PrivateNetworkAccessPermissionPrompt

Origin Trial documentation link

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

WebFeature UseCounter name

kPrivateNetworkAccessPermissionPrompt

Risks



Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

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

Other signals:

Ergonomics

This new feature requires users to click on the new permission. This may lead users to spamming on some websites. However, this is an intentional move to encourage the websites to provide security context. The origin trial also aimed to measure the frequency of users getting the permissions.



Activation

No. This feature attempt to bring developers an easier way to restrict Private Network Access with secure context.



Security

This is a security positive feature.



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. We’ll likely also represent the permission state in the settings pages.



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

No

Mac, Windows, Linux, Chrome OS, Fuchsia, Android, WebLayer. Not Android WebView because of the absence of deprecation trial integration (though that may be changing soon, see https://crbug.com/1308425). Not iOS because this requires changes in Blink and the network service, neither of which are used on iOS.



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

No

https://wpt.fyi/results/fetch/private-network-access/mixed-content-fetch.tentative.https.window.html?label=master&label=experimental&aligned&q=private-network-access



Flag name on chrome://flags



Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

True

Tracking bug

https://crbug.com/1338439

Sample links


https://drive.google.com/file/d/1pnyQfIsXdtJnZoCBVSt4xim0yXjZ0Aqc/view?usp=sharing

Estimated milestones

Shipping on desktop123
OriginTrial desktop last122
OriginTrial desktop first120
DevTrial on desktop120


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/5954091755241472

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/6MczoSFGiHo/m/IigYuhu7AwAJ Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG-zKU_ZS1ibT9H7e5UmoUF2OfCUq5ocsDHaCoJ2rShmPmAejQ%40mail.gmail.com


This intent message was generated by Chrome Platform Status.

--
Yifan

Mike Taylor

unread,
Jan 26, 2024, 5:24:56 AMJan 26
to Yifan Luo, gle...@chromium.org, Jonathan Hao, Camille Lamy

Hi!

Could you please request the various approval bits for the review gates in your chromestatus entry?

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

Vladimir Levin

unread,
Jan 26, 2024, 12:34:49 PMJan 26
to Yifan Luo, gle...@chromium.org, Jonathan Hao, Camille Lamy
Could you file RFPs for this?
 

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

Other signals:

Ergonomics

This new feature requires users to click on the new permission. This may lead users to spamming on some websites. However, this is an intentional move to encourage the websites to provide security context. The origin trial also aimed to measure the frequency of users getting the permissions.


Apologies if I missed this, but is there a document somewhere summarizing the OT findings?
 


Activation

No. This feature attempt to bring developers an easier way to restrict Private Network Access with secure context.



Security

This is a security positive feature.



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. We’ll likely also represent the permission state in the settings pages.



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

No

Mac, Windows, Linux, Chrome OS, Fuchsia, Android, WebLayer. Not Android WebView because of the absence of deprecation trial integration (though that may be changing soon, see https://crbug.com/1308425). Not iOS because this requires changes in Blink and the network service, neither of which are used on iOS.



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

No

https://wpt.fyi/results/fetch/private-network-access/mixed-content-fetch.tentative.https.window.html?label=master&label=experimental&aligned&q=private-network-access  



Flag name on chrome://flags



Finch feature name

None

Non-finch justification

None

Does this mean the feature is not flag guarded, or is this just an omission in chromestatus? 
 
--

Yifan Luo

unread,
Feb 13, 2024, 11:02:38 AMFeb 13
to blink-dev, Vladimir Levin, gle...@chromium.org, Jonathan Hao, Camille Lamy, Yifan Luo
Contact emailsl...@chromium.orgcl...@chromium.orgtit...@chromium.org

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

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


Design docs
https://docs.google.com/document/d/1Q18g4fZoDIYQ9IuxlZTaItgkzfiz_tCqaEAI8J3Y1WY/edit
https://github.com/WICG/private-network-access/blob/main/permission_prompt/security_privacy_self_review.md

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

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/751

TAG review statusIssues addressed

Chromium Trial NamePrivateNetworkAccessPermissionPrompt

Origin Trial documentation linkhttps://github.com/WICG/private-network-access/blob/main/permission_prompt/explainer.md

WebFeature UseCounter namekPrivateNetworkAccessPermissionPrompt

Risks


Interoperability and Compatibility



Gecko: Positive (https://github.com/mozilla/standards-positions/issues/143) Worth prototyping.

WebKit: Positive (https://github.com/WebKit/standards-positions/issues/163)


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

Other signals:

Ergonomics

This new feature requires users to click on the new permission. This may lead users to spamming on some websites. However, this is an intentional move to encourage the websites to provide security context. The origin trial also aimed to measure the frequency of users getting the permissions.



Activation

No. This feature attempt to bring developers an easier way to restrict Private Network Access with secure context.



Security

This is a security positive feature.



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. We’ll likely also represent the permission state in the settings pages.



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

Mac, Windows, Linux, Chrome OS, Fuchsia, Android, WebLayer. Not Android WebView because of the absence of deprecation trial integration (though that may be changing soon, see https://crbug.com/1308425). Not iOS because this requires changes in Blink and the network service, neither of which are used on iOS.



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

https://wpt.fyi/results/fetch/private-network-access/mixed-content-fetch.tentative.https.window.html?label=master&label=experimental&aligned&q=private-network-access



Flag name on chrome://flags#private-network-access-permission-prompt

Finch feature namePrivateNetworkAccessPermissionPrompt

Requires code in //chrome?True

Tracking bughttps://crbug.com/1338439


Sample links
https://drive.google.com/file/d/1pnyQfIsXdtJnZoCBVSt4xim0yXjZ0Aqc/view?usp=sharing

Estimated milestones
Shipping on desktop

123

OriginTrial desktop last

122

OriginTrial desktop first

120

DevTrial on desktop

120


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 Statushttps://chromestatus.com/feature/5954091755241472

Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/6MczoSFGiHo/m/IigYuhu7AwAJ Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG-zKU_ZS1ibT9H7e5UmoUF2OfCUq5ocsDHaCoJ2rShmPmAejQ%40mail.gmail.com



This intent message was generated by Chrome Platform Status.

Yifan Luo

unread,
Feb 15, 2024, 3:51:40 AMFeb 15
to blink-dev, Yifan Luo, Vladimir Levin, gle...@chromium.org, Jonathan Hao, Camille Lamy
OT findings: 
There are 7 OT users and most of them (6/7) mentioned they will keep using this new feature.

We aimed to use this feature to make it possible for developers to drop the non-secure context deprecation trial, which currently got 1000+ registrations: https://docs.google.com/spreadsheets/d/1yTjZs3yvTFwn0SupdBmzZiOQ_A3Auvg_Qrp3DwOKBNw/edit?pli=1#gid=369270489

RFPs: This feature is a sub-feature of Private Network Access: filled in the previous RFP of PNA.
Flag: Sorry for the missing, there's a finch flag "PrivateNetworkAccessPermissionPrompt"

Yoav Weiss (@Shopify)

unread,
Feb 15, 2024, 4:56:09 AMFeb 15
to Yifan Luo, blink-dev, Vladimir Levin, Jonathan Hao, Camille Lamy
LGTM1

On Thu, Feb 15, 2024 at 9:51 AM 'Yifan Luo' via blink-dev <blin...@chromium.org> wrote:
OT findings: 
There are 7 OT users and most of them (6/7) mentioned they will keep using this new feature.

We aimed to use this feature to make it possible for developers to drop the non-secure context deprecation trial, which currently got 1000+ registrations: https://docs.google.com/spreadsheets/d/1yTjZs3yvTFwn0SupdBmzZiOQ_A3Auvg_Qrp3DwOKBNw/edit?pli=1#gid=369270489

RFPs: This feature is a sub-feature of Private Network Access: filled in the previous RFP of PNA.
Flag: Sorry for the missing, there's a finch flag "PrivateNetworkAccessPermissionPrompt"

On Tuesday, February 13, 2024 at 5:02:38 PM UTC+1 Yifan Luo wrote:
Contact emailsl...@chromium.orgcl...@chromium.orgtit...@chromium.org

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

I had a minor concern after reading the explainer about the lack of a preflight and opt-in requirement. Turns out that those are already required as part of the broader PNA feature.

Mike Taylor

unread,
Feb 15, 2024, 10:57:00 AMFeb 15
to Yoav Weiss (@Shopify), Yifan Luo, blink-dev, Vladimir Levin, Jonathan Hao, Camille Lamy

Chris Harrelson

unread,
Feb 21, 2024, 11:46:38 AMFeb 21
to Mike Taylor, Yoav Weiss (@Shopify), Yifan Luo, blink-dev, Vladimir Levin, Jonathan Hao, Camille Lamy

Alex Russell

unread,
Feb 21, 2024, 11:47:18 AMFeb 21
to blink-dev, Mike Taylor, blink-dev, vmp...@google.com, ph...@google.com, Camille Lamy, Yoav Weiss, l...@google.com
LGTM3

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages