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.
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.
No. This feature attempt to bring developers an easier way to restrict Private Network Access with secure context.
This is a security positive feature.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
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.
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.
Shipping on desktop | 123 |
OriginTrial desktop last | 122 |
OriginTrial desktop first | 120 |
DevTrial on desktop | 120 |
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).
NoneHi!
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.
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)?
NoMac, 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
Flag name on chrome://flags
Finch feature name
NoneNon-finch justification
None
--
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.
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.
No. This feature attempt to bring developers an easier way to restrict Private Network Access with secure context.
This is a security positive feature.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
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.
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.
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).
NoneOT findings:https://docs.google.com/spreadsheets/d/15b2kCikEqw6P0xZFXQKMiKk_WnqnIZpT5p8nmLgc93Y/edit?usp=sharingThere 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=369270489RFPs: 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.org, cl...@chromium.org, tit...@chromium.org
Explainerhttps://github.com/WICG/private-network-access/blob/main/permission_prompt/explainer.md
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/de68b1f3-6ee6-4d3d-985e-d0ed8ac1dd87n%40chromium.org.
LGTM2
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKvXbbkZ-M%2BD%2BgspKuJDJXav93Z6t_fF7h9oq_2ZEc7eg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8100c652-cb13-45ef-8191-5f2c8b852356%40chromium.org.
LGTM1
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/de68b1f3-6ee6-4d3d-985e-d0ed8ac1dd87n%40chromium.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.