On Friday, March 21, 2025 at 5:22:57 PM UTC+9 Steven Bingler wrote:
Contact emailsbing...@chromium.org, miketa...@chromium.org, la...@chromium.org Explainer https://github.com/explainers-by-googlers/HSTS-Tracking-Prevention Specification Draft-bingler-hsts-tracking-prevention <https://sbingler.github.io/hsts-tracking-prevention-spec/draft-bingler-hsts-tracking-prevention.html> Neither of the following concerns are blocking approving this I2S, since we're following other browsers and you have a draft spec that's good enough for interoperable implementation. But in the interest of long-term spec ecosystem health, I want to ask: - I see that this is an individual draft in monkeypatch form. Do you plan to eventually produce something in the IETF that supersedes RFC6797? That would help avoid confusion where people accidentally implement against the old RFC instead of against the new state of the art. - Could you send a spec PR to Fetch, to modify the current HSTS reference <https://fetch.spec.whatwg.org/#:~:text=Matching%20request%E2%80%99s%20current%20URL%E2%80%99s%20host,9.5%20of%20%5BSVCB%5D.%20%5BHSTS%5D%20%5BSVCB%5D> to require that browsers implement the modifications in your draft? I think that might also be a good way to get cross-browser discussion started. The following concern is potentially more serious: The spec draft says "In this case the UA should store and index HSTS Policies within that partition based strictly upon the domain names of the issuing HSTS Hosts." Why the domain name, instead of the network partition key <https://fetch.spec.whatwg.org/#network-partition-keys>? (In general I find the proliferation of keying schemes confusing and would like to ensure we are careful about introducing new, different ones.) SummaryOnly apply HSTS upgrades to top-level navigation requests. By not applying HSTS upgrades to any sub-resources it will be impossible for any stored identity to be read unless the browser is navigated to every applicable url. This makes tracking via the HSTS significantly more difficult for third-party trackers. I'm confused on how this description matches the spec draft's strategy. The draft (combined with the Fetch spec) applies HSTS to all fetches, except tracking domains, and then partitions HSTS status by domain. Whereas, the description here only applies it to top-level navigation requests. Which one are you shipping? Blink componentBlink>SecurityFeature>HSTS TAG reviewNone TAG review status N/A - This is a change to existing API and follows other Browsers’ related changes. Risks Interoperability and Compatibility This change is expected to have minimal interoperability and compatibility impact due to Chrome’s existing mixed content upgrading and blocking which prevents insecure resources from loading on secure sites. This means that the user experience on secure sites is unchanged. Gecko: Shipped - Similar design Firefox blocks third-party HSTS responses <https://bugzilla.mozilla.org/show_bug.cgi?id=1701192#c15>. WebKit: Shipped - Similar design Safari blocks third-party HSTS responses <https://webkit.org/blog/8146/protecting-against-hsts-abuse/>. Can you give more detail on their designs, so we can understand how interoperable they are? In particular, are they doing top-level only, or partitioning? If partitioning, by what key? Web developers: No signals WebView application risks Little to none, after consulting with the WebView team. Urls specified by the App for HSTS usage will also be subject to the top-level navigation requirement but because these apps are also subject to mixed content blocking and upgrading by default this is not expected to be an issue. DebuggabilityIn general, there's already little to no visibility into how or why a connection is changed. On insecure top-level pages dev can check if the request was loaded over http. We don’t think any special devtools are needed for this, but for more advanced debugging netlogs do exist. 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> ?Yes <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/hsts/only-top-level-navigation-hsts-upgrade.tentative.sub.html> No other browser appears to pass this test <https://wpt.fyi/results/hsts/only-top-level-navigation-hsts-upgrade.tentative.sub.html?label=master&label=experimental&aligned>, so I am worried that the interoperability concerns are not as small as you suggested above. Flag name on chrome://flagsNone Finch feature name HstsTopLevelNavigationsOnly Requires code in //chrome?False Launch bughttps://launch.corp.google.com/launch/4344691 Estimated milestones Shipping on desktop 135 Shipping on Android 135 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5072685886078976 Links to previous Intent discussions Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/ cvzGZoulIeY/m/gkLRo4LQBQAJ?e=48417069 -- 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/6bf7e522-67c8-4dc3-90c6-f7d512a94ac3n%40chromium.org.
