Contact emailstit...@chromium.org, cl...@chromium.org, mk...@chromium.org, va...@chromium.org
Requires that private network requests for subresources may only be initiated from a secure context. "Private network requests" are those initiated from a public network, targeting a private network. Examples include internet to intranet requests and intranet loopbacks.
This is a first step towards fully implementing Private Network Access: https://wicg.github.io/private-network-access/
TAG review statusUnder way
Since this deprecation only affects non-secure contexts, however, this Deprecation Trial would need to allow non-secure/HTTP origins to sign up. This is a departure from established practice where Origin Trials are scoped to secure/HTTPS origins only. While this may open the door to silliness due to the lack of authentication, it seems inevitable that Deprecation Trials allow HTTP origins to sign up. Indeed more and more features of the Web Platform will be deprecated over time as their access is restricted to secure contexts. Each of those deprecations will require a similar setup. Note that there is no technical obstacle to this, see the discussion here.
Goals for experimentation
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.
Ongoing technical constraints
The Origin Trial will only support setting tokens via headers, and not via a <meta> tag. This is because the opt-in status of a given document must be known at commit time, before the document has started being parsed. This is similar to the existing SharedArrayBuffer deprecation trial
. See also details here
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, Chrome OS, Android, and Android WebView)?YesNot yet. Implementation is being finalized, now that WPT RFC 72 has finally been implemented with WPT PR #28870.
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5436853517811712
Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJReady for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJIntent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/cPiRNjFoCag/m/DxEEN9-6BQAJ