Late to the party. My thoughts are as follows: 1. This proposal introduces a lot of complexity to other parts, like proxy application, service worker, CORS. 2. It is difficult to upgrade all LAN services to https or add new CORS headers, or it will take many years. 3. This limits the capabilities of web applications. For example, a public PWA Web console app, which allows users to configure the local service address(and username/password) in a LAN network by users themselves, and then communicate with it. For example, various services deployed in a NAS device. 4. The original intention of this proposal is to protect LAN services, but I think the right direction should be to make these LAN services improve their own security.
Jackie On Wednesday, December 14, 2022 at 1:46:27 PM UTC+8 [email protected] wrote: > 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/df3dc0d4-adb5-411a-99dd-a676dbec9b31n%40chromium.org.
