Hi Emily,
A few questions inline:
On 6/1/24 5:05 AM, Emily Stark wrote:
Contact emails
est...@google.com, jdebla...@google.com, dadr...@google.com,
l...@chromium.org, tito...@chromium.org, cl...@chromium.org,
mk...@chromium.org, v...@chromium.org
Explainer
https://github.com/WICG/private-network-access/blob/master/explainer.md
Specification
https://wicg.github.io/private-network-access
Design docs
https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64
Summary
Requires that private network requests for subresources from public
websites may only be initiated from a secure context. Examples include
internet to intranet requests and internet to loopback requests. This
is a first step towards fully implementing Private Network Access:
https://wicg.github.io/private-network-access/
Blink component
Blink>SecurityFeature>CORS>PrivateNetworkAccess
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess>
TAG review
https://github.com/w3ctag/design-reviews/issues/572
TAG review status
Issues addressed
Chromium Trial Name
PrivateNetworkAccessNonSecureContextsAllowed
Link to origin trial feedback summary
https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing&resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ
<https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing&resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ>
Origin Trial documentation link
https://developer.chrome.com/blog/private-network-access-update/
WebFeature UseCounter name
kPrivateNetworkAccessNonSecureContextsAllowedDeprecationTrial
Risks
Interoperability and Compatibility
No interoperability risks. Compatibility risk is small but
non-negligible. UseCounters show ~0.1% of page visit making use of
this feature. Direct outreach to the largest users per UKM data
revealed no objections to this launch. Rolling this deprecation out to
beta per the previous I2S resulted in more feedback about the
compatibility risk and the need for a time extension. See the
following doc for an extensive discussion:
https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit
Can you speak to the number of sites in the largest users group? Is it
dozens of sites? Hundreds? Presumably they're all enrolled in the DT?
/Gecko/: Closed Without a Position
(https://github.com/mozilla/standards-positions/issues/143)
Tentatively positive, but no formal position yet.
/WebKit/: Positive
(https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html)
/Web developers/: Mixed signals
(https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit)
In our recent survey, most of websites are able to migrate if our new
permission prompt can be landed as a way for them to relax mixed
content checks.
https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809 ------------
Some websites, broadly falling in the category of controller webapps
for IoT devices, find this change incompatible with their use cases.
While many use cases can be solved with specific workarounds, some
still require further engagement.
/Other signals/:
Activation
Developers of non-secure sites that rely upon local servers will need
to upgrade to HTTPS. This might cause some complications, as
mixed-content checks will begin to apply. Chrome carves out HTTP
access to loopback (as
perhttps://w3c.github.io/webappsec-secure-contexts/#localhost
<http://w3c.github.io/webappsec-secure-contexts/#localhost>), which is
a release valve for folks who don't want to go through the effort of
securely-distributing certs for local servers. The initial launch in
M92 was delayed due to compatibility risks surfaced during the rollout
to beta. See this doc for a lot more details:
https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit
Security
This change should be security-positive.
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?
Goals for experimentation
Reason this experiment is being extended
The blocker to shipping this feature is that some websites can't
create HTTPS connections to subresources on the private network due to
various constraints (e.g., unable to obtain a publicly trusted HTTPS
certificate). A permission prompt is in development
(https://groups.google.com/a/chromium.org/g/blink-dev/c/sL15TKGmXqM/m/rD0SF8sQBwAJ)
to allow such subresources to be loaded over HTTP (whereas they would
usually be blocked by mixed content rules). However, the permission
prompt currently only works for fetch() and does not work in iframes,
thus we need to investigate whether we need to support use cases not
supported by the current implementation. The overall Private Network
Access project is also currently being transitioned between teams, so
the extension request includes some time for handoff/rampup.
I'm slightly confused on the timing -
https://chromestatus.com/feature/5954091755241472 states that we shipped
the permission prompt in 124 - is that not the case?
What are the non-fetch cases that might need to be supported? XHR?
Sub-resource loads? Both? Something else? Is it feasible to design a DT
that addresses the non-fetch() use cases?
Also, could you clarify what milestones you're requesting a renewal for?
The table below is hard for me to parse (e.g., extension 5 ending in
132; extension 6 ending in 126).
Ongoing technical constraints
None.
Debuggability
When a request is made that violates this restriction and the feature
is not enabled, three things happen: 1. A warning message is logged to
the DevTools console. 2. A deprecation report is filed against the
initiator website's Reporting API, if so configured. 3. An issue is
surfaced in the DevTools Issues panel. Likewise, when the feature is
enabled and a request is blocked, the same happens except that the
message logged to the DevTools console is an error and its text is
slightly different. The devtools network panel shows information about
the source and remote address spaces at play.
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
https://wpt.fyi/results/fetch/private-network-access?label=master&label=experimental&aligned
<https://wpt.fyi/results/fetch/private-network-access?label=master&label=experimental&aligned>
Flag name on chrome://flags
BlockInsecurePrivateNetworkRequests
Finch feature name
None
Non-finch justification
None
Requires code in //chrome?
False
Tracking bug
https://crbug.com/986744
Launch bug
https://crbug.com/1129801
Estimated milestones
Shipping on desktop 127
Origin trial desktop first 94
Origin trial desktop last 126
Origin trial extension 1 end milestone 126
Origin trial extension 5 end milestone 132
Origin trial extension 6 end milestone 126
DevTrial on desktop 86
OriginTrial Android last 126
OriginTrial Android first 94
DevTrial on Android 86
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5436853517811712?gate=5187028487766016
Links to previous Intent discussions
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJ
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/vlDZXlPb00k/m/1421ACiuAAAJ
Intent to Extend Experiment 1:
https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck
Intent to Extend Experiment 6:
https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck
Intent to Ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck
Intent to Ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPP_2Sbhrsrmmk5ZTwkxkuwT6_iEs4QPNGNYTL9u_7ODmEb3Vw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPP_2Sbhrsrmmk5ZTwkxkuwT6_iEs4QPNGNYTL9u_7ODmEb3Vw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/24a3f919-373b-48c9-a7c5-25d26c9db547%40chromium.org.
