Just checked the most recent trial registration data, and it seems like the overwhelming majority of origins signed up for the trial in October are still signed up today. In addition, there are two thirds more new registrations.
Cheers, Titouan On Fri, Mar 18, 2022 at 5:28 PM Titouan Rigoudy <tito...@google.com> wrote: > The exit strategy so far was to let developers try their hand at the > suggested workarounds and see whether those could support all legitimate > use cases. Once that is the case, we can leave a fixed number of milestones > for developers to adjust, then exit. > > We have made progress on determining whether the main workaround > (WebTransport) is a viable solution or not. Developers have tried to > re-architect to use that instead, and reported issues related to first-time > setup of IoT devices. We are discussing options that would allow those use > cases to keep functioning. The leading contender seems to be some kind of > permission prompt. > > I will look into the deprecation trial signup data to see if there has > been a reduction so far and report back. > > Cheers, > Titouan > > On Fri, Mar 18, 2022 at 4:12 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> Can you remind me what's the exit strategy from this deprecation trial? >> Are we making progress on that front? Do we see any reduction in the number >> of properties that need this deprecation trial? >> >> On Fri, Mar 18, 2022 at 4:04 PM 'Titouan Rigoudy' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> Contact emailstito...@chromium.org, cl...@chromium.org, >>> mk...@chromium.org, v...@chromium.org >>> >>> 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/ >>> >>> Reason this trial is being extended >>> 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. >>> >>> Previous experiment timeline: M94 to M101 >>> Requested extension timeline: M102 to M106 >>> >>> 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 the main issue. >>> UseCounters show ~0.1% of page visit making use of this feature. A few >>> hundred websites signed up to the deprecation trial. 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) >>> >>> WebKit: Positive ( >>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html) >>> >>> Web developers: Negative ( >>> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit) >>> Some websites, broadly falling in the category of controller webapps for >>> IoT devices, find this change incompatible with their use cases. While some >>> use cases can be solved with specific workarounds, many still require >>> further engagement. >>> >>> 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 >>> per https://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 >>> >>> This change is disabled on WebView due to its lack of support for >>> origin/deprecation trials. >>> >>> >>> >>> 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. 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/+/master/docs/testing/web_platform_tests.md> >>> ?Yes >>> >>> Flag nameBlockInsecurePrivateNetworkRequests >>> >>> Requires code in //chrome?False >>> >>> Tracking bughttps://crbug.com/986744 >>> >>> Launch bughttps://crbug.com/1129801 >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5436853517811712 >>> >>> Links to previous Intent discussionsIntent to prototype: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJ >>> 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 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/>. >>> >>> -- >>> 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/CAPATO9cCT6C7RLunP_%3Da0nuE1iM5EP48SZp%2BQqmrqhfqQDCL-A%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9cCT6C7RLunP_%3Da0nuE1iM5EP48SZp%2BQqmrqhfqQDCL-A%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/CAPATO9dpwzV49Y8gCphw76VHh50VqgVo-YfzN2PV%2BK1wbYsJjA%40mail.gmail.com.
