LGTM to extend the deprecation trial till M113.
On Tue, Dec 13, 2022 at 3:11 PM Yifan Luo <[email protected]> wrote: > I'm currently requesting opt-in/opt-out data from origin trial team and > see how's the data looks like. Will send it in the thread after I have it. > > The situation is that some of the local devices are not able to migrate to > HTTPS. In this case, we introduced a permission prompt in the middle to > relax mixed-content checks here and our current expectation is to ship it > on M111. > > However, some websites recently reached us and said even we shipped it, if > the other browsers don't, it is still hard, even not possible, for them to > migrate their public websites to HTTPS. > That's indeed a tricky situation. I wonder if we could add some form of content negotiation (e.g. a request header) that would enable such sites to redirect to HTTPS in the interim. Or maybe even tell them to use UA-CH for that purpose.. > > I'm currently writing the permission part of the spec and asking for > positions from other browser vendors. ( I talked with anne@ from webkit > once about it and he was at least interested in the spec at the time ) Even > though, it might take long for all the browsers be able to ship it and as > though websites able to migrate it. > Getting positions from other browsers sounds like a good next step. > > So that I'm not able to give you any estimation on it at this point, but > hopefully we can after gain the position from other browser vendors on it. > > best, > Yifan > > On Wednesday, December 7, 2022 at 4:29:23 PM UTC+1 [email protected] > wrote: > >> 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/CAL5BFfVk-tygG6c3JzYWRrRuKy2sPA4%2BmtwB1Sy4oQBpYFu-Dw%40mail.gmail.com.
