Thanks for the link! :) Do y'all have usage stats trends and/or insights into how far we are from being able to turn off the deprecation trial?
On Wed, Dec 7, 2022 at 3:02 PM Jonathan Hao <[email protected]> wrote: > Hi Yoav, > > Here's the "intent to extend experiment" thread to M109. > https://groups.google.com/a/chromium.org/g/blink-dev/c/PCfDnIV1cOw/ > > Best, > Jonathan > > On Wed, Dec 7, 2022 at 12:29 PM Yoav Weiss <[email protected]> wrote: > >> Can you clarify the deprecation trial timeline so far? The "intent to >> extend experiment" you linked to indicates experimentation until M106. Is >> that correct? >> >> On Tue, Dec 6, 2022 at 3:35 PM 'Yifan Luo' via blink-dev < >> [email protected]> wrote: >> >>> Contact [email protected], [email protected], >>> [email protected], [email protected], [email protected] >>> >>> Explainer >>> https://github.com/WICG/private-network-access/blob/master/explainer.md >>> >>> Specificationhttps://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 componentBlink>SecurityFeature>CORS>PrivateNetworkAccess >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess> >>> >>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572 >>> >>> TAG review statusIssues 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 >>> >>> 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. >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, Chrome OS, 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 >>> >>> Flag nameBlockInsecurePrivateNetworkRequests >>> >>> Requires code in //chrome?False >>> >>> Tracking bughttps://crbug.com/986744 >>> >>> Launch bughttps://crbug.com/1129801 >>> >>> Estimated milestones >>> OriginTrial desktop last 113 >>> OriginTrial desktop first 94 >>> DevTrial on desktop 86 >>> OriginTrial Android last 113 >>> 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 discussionsReady 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_1bPpOg-fexyo%2BXtMP%3D5_M4eKyeTPyWMD07EvUarogUA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG-zKU_1bPpOg-fexyo%2BXtMP%3D5_M4eKyeTPyWMD07EvUarogUA%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/CAL5BFfUsc49ppMPo1k7pS-KJhsE6jLgAYSfVgy_kyGid%3D4QYnw%40mail.gmail.com.
