Hi Yifan,
Could you clarify the current deprecation timeline, and the requested
extension milestones? I think you're requesting to 116, with the current
DT expiring in 113 - can you confirm?
Are metrics moving in the direction we want them to? Do you think 3
milestones is realistic to move the needle?
thanks,
Mike
On 3/17/23 6:40 AM, 'Yifan Luo' via blink-dev wrote:
Contact emails
[email protected], [email protected], [email protected],
[email protected], [email protected]
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
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
/Gecko/: Worth prototyping
(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
User feedbacks collection:
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>
------------ It seems that many developers have not noticed the
upcoming launch despite outreach efforts, and will likely only notice
once Chrome ships the secure context restriction. Thus delaying the
launch by a few milestones to offer more breathing room to the
currently-aware developers would not mitigate the risk when we ship
the next time. A Deprecation Trial seems like the logical next step.
This would allow us to protect the vast majority of users of the web
by at least requiring attackers to sign up for the trial, itself a
deterrent. Simultaneously, it would give enough time to legitimate
websites to work around the new restriction. Finally, it would allow
more time for discussions should our planned solutions fail to
adequately address developers’ concerns.
Reason this experiment is being extended
The permission prompt approach has been changed a bit according to
developers' feedback, we would like to support frames/iframes with
permission policy in the future.
Meanwhile, to avoid further confusion and back and forth work, the
launching process for permission prompt has been postponed for
Private Network Access project renaming process.
Link to the previous intend:
https://groups.google.com/a/chromium.org/g/blink-dev/c/IK-Q7wnLqvo?pli=1
----------
We have collected 20+ developers' feedback since the last milestone.
85.7% developers said that they are still migrating to HTTPS, 50% said
they need more time and 50% said they are not able to migrate local
devices for various reasons and need future help. In the meanwhile, we
are also collecting developers' feedback on our future plan for
websites that cannot migrate their private devices to HTTPS but would
like to migrate their public websites. 11.1% websites answered
probably yes to our new feature and 72.2% responded might or might
not. The major considers are they also need the allowance on
frames/iframes (Q8 64.7%), want to use IP address as ids in permission
(Q12 82.3%), too many permission prompt might be a spam (2 answers)
and need to wait for other browsers supporting Private Network Access.
In this case, we are also actively changing our further plan and
collaborating with other browsers at the same time. ------------ The
main workaround suggested to impacted websites was to use
WebTransport's serverCertificateHashes feature. That is only shipping
in Chrome 100; developers need more time to try it out. In addition,
some issues have been identified with WebTransport that are prompting
us to re-evaluate alternatives. In the meantime, keeping the trial
going helps "staunch the bleeding" and provides a channel for
discussing plans with affected web developers.
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.
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
BlockInsecurePrivateNetworkRequests
Requires code in //chrome?
False
Tracking bug
https://crbug.com/986744
Launch bug
https://crbug.com/1129801
Estimated milestones
OriginTrial desktop last 116
OriginTrial desktop first 94
DevTrial on desktop 86
OriginTrial Android last 116
OriginTrial Android first 94
DevTrial on Android 86
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5436853517811712
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:
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/cPiRNjFoCag/m/DxEEN9-6BQAJ
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.
--
Yifan
--
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/CAG-zKU_8FqDuDJv7c1dx6s83cwBz%3DYnwF6gSqtcxBZCi_KeFUQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG-zKU_8FqDuDJv7c1dx6s83cwBz%3DYnwF6gSqtcxBZCi_KeFUQ%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a27b3b53-5580-27d1-038f-6c7dd967354f%40chromium.org.
