LGTM2 On Fri, Oct 25, 2024 at 8:48 PM Eric Lawrence <bay...@gmail.com> wrote:
> > This seems like a good change, but I notice that it has no flag > associated with it > > Okay, patchset 8. > https://chromium-review.googlesource.com/c/chromium/src/+/5923046 > > BASE_FEATURE(kIgnoreHSTSForLocalhost, > "IgnoreHSTSForLocalhost", > base::FEATURE_ENABLED_BY_DEFAULT); > > > On Friday, October 25, 2024 at 4:15:14 AM UTC-5 Daniel Bratell wrote: > > This seems like a good change, but I notice that it has no flag associated > with it. Is there a reason for that (i.e. very hard to implement) or > something similar? If not, we should play it safe and have one just in case > there are unforeseen consequences. > > /Daniel > On 2024-10-24 23:56, Mike Taylor wrote: > > Can we request reviews for Security, Privacy, Enterprise, etc in the > chrome status entry? > > thx > On 10/24/24 5:42 PM, Alex Russell wrote: > > 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+...@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+...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA44PQgt3fZopgSBpkv2GxFr9fpOkCbSES6V0tAVK-Un%3DV-YzA%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 blink-dev+...@chromium.org. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1ce4f44c-fde8-4c96-9611-b1a101e4ab3d%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1ce4f44c-fde8-4c96-9611-b1a101e4ab3d%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/83d14c46-ac56-4820-84b1-09db6e686d90n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/83d14c46-ac56-4820-84b1-09db6e686d90n%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/CAOmohSKy_48KSkiUqyc-ChOMSULByxHNOAKX0%3DTGAnRb%3D5FAfQ%40mail.gmail.com.
