Hi Mike, The current trial is indeed ending with 113. We would like to extend it 3 more milestones.
We are working to ship a permission-based API [1] as a replacement mechanism for the behavior deprecated here. We are aiming to have an MVP on all platforms in 114. Until we ship, we do not expect much movement in metrics. Most folks in the trial are still there because this prompt is their only alternative, others have had plenty of time to migrate. Cheers, Titouan [1] https://chromestatus.com/feature/5954091755241472 On Fri, Mar 17, 2023 at 3:31 PM Mike Taylor <[email protected]> wrote: > 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), 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 > ------------ 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/CAPATO9df8DAcJ6wR%2Br8cDXNeMBmX_HL79HZmXJDJGtaQ2TNeww%40mail.gmail.com.
