LGTM1 On Thu, Oct 24, 2024, 11:39 AM Eric Lawrence <bay...@gmail.com> wrote:
> Okay, I've proposed a tweak. > > https://github.com/whatwg/fetch/pull/1781 > > On Thursday, October 24, 2024 at 1:13:18 PM UTC-5 Jeffrey Yasskin wrote: > >> Yes, exactly. >> >> On Thu, Oct 24, 2024 at 8:46 AM Chris Thompson <cth...@chromium.org> >> wrote: >> >>> I think this would be in Step 10 of Main Fetch (Step 5 is for >>> Upgrade-Insecure-Requests): >>>> >>>> Set request’s current URL >>>> <https://fetch.spec.whatwg.org/#concept-request-current-url>’s scheme >>>> <https://url.spec.whatwg.org/#concept-url-scheme> to "https" if all of >>>> the following conditions are true: >>>> >>>> - request’s current URL >>>> <https://fetch.spec.whatwg.org/#concept-request-current-url>’s >>>> scheme <https://url.spec.whatwg.org/#concept-url-scheme> is "http" >>>> - request’s current URL >>>> <https://fetch.spec.whatwg.org/#concept-request-current-url>’s host >>>> <https://url.spec.whatwg.org/#concept-url-host> is a domain >>>> <https://url.spec.whatwg.org/#concept-domain> >>>> - Matching request’s current URL >>>> <https://fetch.spec.whatwg.org/#concept-request-current-url>’s host >>>> <https://url.spec.whatwg.org/#concept-url-host> per Known HSTS Host >>>> Domain Name Matching >>>> <https://www.rfc-editor.org/rfc/rfc6797.html#section-8.2> results >>>> in either a superdomain match with an asserted includeSubDomains >>>> directive >>>> or a congruent match (with or without an asserted includeSubDomains >>>> directive) [HSTS] <https://fetch.spec.whatwg.org/#biblio-hsts>; or >>>> DNS resolution for the request finds a matching HTTPS RR per section >>>> 9.5 >>>> >>>> <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-9.5> >>>> of [SVCB] <https://fetch.spec.whatwg.org/#biblio-svcb>. [HSTS] >>>> <https://fetch.spec.whatwg.org/#biblio-hsts> [SVCB] >>>> <https://fetch.spec.whatwg.org/#biblio-svcb> >>>> >>>> So maybe just add a fourth condition "request's current URL's host is >>> not localhost"? >>> >>> >>> On Thu, Oct 24, 2024 at 8:42 AM Eric Lawrence <bay...@gmail.com> wrote: >>> >>>> > probably makes sense to start by suggesting a change to >>>> https://fetch.spec.whatwg.org/#concept-main-fetch, >>>> > but the editors there might ask you to write an update to the RFC. >>>> >>>> I don't think I understand what change to Fetch would be proposed. The >>>> section you flagged has two relevant clauses related to HTTPS upgrades: >>>> >>>> 5. Upgrade request to a potentially trustworthy URL, if appropriate. >>>> 6. Upgrade a mixed content request to a potentially trustworthy URL, >>>> if appropriate. >>>> >>>> Notably, [*.]localhost is already a potentially trustworthy URL: >>>> https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy, >>>> clause #5. >>>> >>>> ...which implies to me that the behavior I propose is already what >>>> Fetch asks for. >>>> On Wednesday, October 23, 2024 at 7:12:28 PM UTC-5 Jeffrey Yasskin >>>> wrote: >>>> >>>>> Can you propose a matching change to the relevant standard? It >>>>> probably makes sense to start by suggesting a change to >>>>> https://fetch.spec.whatwg.org/#concept-main-fetch, but the editors >>>>> there might ask you to write an update to the RFC. We can figure out the >>>>> cheapest way to get that done if they do ask. There's no need to block >>>>> shipping this on getting the updates finished, but the launch process >>>>> <https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship:~:text=propose%20that%20the%20feature%20migrate%20to%20a%20working%20group> >>>>> does >>>>> say to propose it first. >>>>> >>>>> Jeffrey >>>>> >>>>> On Wed, Oct 23, 2024 at 2:28 PM 'Eric Lawrence' via blink-dev < >>>>> blin...@chromium.org> wrote: >>>>> >>>>>> *Following up on an earlier thread >>>>>> here: >>>>>> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gGHOmFGEzQ0 >>>>>> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gGHOmFGEzQ0>* >>>>>> >>>>>> Contact emails: eri...@microsoft.com >>>>>> >>>>>> Explainer: None >>>>>> >>>>>> Specification: HSTS specification is at >>>>>> https://datatracker.ietf.org/doc/html/rfc6797; this feature proposes >>>>>> an improvement. >>>>>> >>>>>> Summary >>>>>> >>>>>> Strict-Transport-Security response headers can cause problems for >>>>>> localhost web servers because STS applies host-wide, across all ports. >>>>>> This >>>>>> causes compatibility problems for web developers testing locally as well >>>>>> as >>>>>> end-users who use software packages that commonly spin up localhost >>>>>> webservers for ephemeral reasons (e.g. communication of an auth token >>>>>> from >>>>>> a web login to a local software package). If one local listener sets >>>>>> Strict-Transport-Security on a localhost response, it will be applied to >>>>>> all subsequent localhost requests regardless of port. We resolve this >>>>>> problem by ignoring Strict-Transport-Security headers on responses from >>>>>> localhost URLs. >>>>>> >>>>>> Blink component: Internals>Network>DomainSecurityPolicy >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3EDomainSecurityPolicy> >>>>>> >>>>>> TAG review: None >>>>>> >>>>>> Risks >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> The expectation is that this will improve compatibility with services >>>>>> that run on localhost by avoiding unexpected interactions across >>>>>> unrelated >>>>>> packages. >>>>>> >>>>>> *Gecko*: Shipped/Shipping >>>>>> >>>>>> *WebKit*: No signal >>>>>> >>>>>> *Web developers*: Positive ( >>>>>> https://issues.chromium.org/issues?q=HSTS%20localhost) Web >>>>>> Developers who test their sites locally commonly report problems with >>>>>> Strict-Transport-Security headers applying unexpectedly across unrelated >>>>>> localhost services under tests. >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> 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? >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> HSTS upgrades show in the F12 Network pane as "307 Internal >>>>>> Redirect." In the absence of such an upgrade, the 307 is not shown. >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, 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> >>>>>> ? No, HSTS is not tested by Web Platform tests. The change is tested >>>>>> by Chrome unit and browser tests. >>>>>> >>>>>> Flag name on chrome://flags: None >>>>>> >>>>>> Finch feature name: None >>>>>> >>>>>> Non-finch justification: None >>>>>> >>>>>> Requires code in //chrome? All of the functional changes are in >>>>>> /net/ but tests under /chrome/ require updates to use non 'localhost' >>>>>> test >>>>>> endpoints. >>>>>> >>>>>> Tracking bug https://issues.chromium.org/issues/41251622; CL: >>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/5923046 >>>>>> <https://chromium-review.googlesource.com/c/chromium/src/+/5923046> >>>>>> >>>>>> Estimated milestones >>>>>> Shipping on desktop >>>>>> 132 >>>>>> Shipping on Android >>>>>> 132 >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> None >>>>>> >>>>>> Link to entry on the Chrome Platform Status: >>>>>> https://chromestatus.com/feature/5134293196865536?gate=5113092281991168 >>>>>> >>>>>> Links to previous Intent discussions: >>>>>> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gGHOmFGEzQ0 >>>>>> >>>>>> >>>>>> -- >>>>>> 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+...@chromium.org. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d6c447c-32ba-46af-b04e-828e69b38322n%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d6c447c-32ba-46af-b04e-828e69b38322n%40chromium.org?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+...@chromium.org. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b81818f0-73ef-4703-af4c-8f8fcefd93d2n%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b81818f0-73ef-4703-af4c-8f8fcefd93d2n%40chromium.org?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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7c28576e-bee4-430e-8a8d-40c9f23fd6c8n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7c28576e-bee4-430e-8a8d-40c9f23fd6c8n%40chromium.org?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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQgt3fZopgSBpkv2GxFr9fpOkCbSES6V0tAVK-Un%3DV-YzA%40mail.gmail.com.
