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+unsubscr...@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/CANh-dXkh%3D7bFAXmeW1os%2BTdZaAcoG-%2B0z7nh3nowjkGZAbTJqQ%40mail.gmail.com.
