Thanks Mike! On Tue, Mar 21, 2023 at 10:25 PM Mike Taylor <[email protected]> wrote:
> Thanks Titouan. > > LGTM to extend to 116 inclusive. > On 3/21/23 6:31 AM, Titouan Rigoudy wrote: > > 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/CAPATO9fhmY4bc_eufhdAgpNg8bbfHvec7WjehoVQTRyqaZ7ozA%40mail.gmail.com.
