Sure thing and no no worries at all. Thanks for your feedback. On Wednesday, May 28, 2025 at 11:52:10 PM UTC-4 Domenic Denicola wrote:
Thanks for picking this up, and sorry for adding friction to what I'm sure is already a tricky transition. On Wed, May 28, 2025 at 11:15 AM Ladan Khamnian <la...@chromium.org> wrote: -Domenic Steven is no longer on our team unfortunately so I am picking up this effort. Please find my answers to your questions inline. -Steven Thanks so much for all your efforts on this. On Tuesday, April 1, 2025 at 2:18:40 AM UTC-4 Domenic Denicola wrote: 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. This is a good idea. I will add this to my team's backlog and set a medium priority to it so we can get to it soon. - 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. Yes I will get on it. 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.) This is actually what the RFC <https://www.rfc-editor.org/rfc/rfc6797#section-5.3> mentions. It is not part of Steven's draft. I think it is part of Steven's draft, in section 3.1.3's first change to RFC6797 <https://sbingler.github.io/hsts-tracking-prevention-spec/draft-bingler-hsts-tracking-prevention.html#:~:text=In%20this%20case%20the%20UA%0A%20%20%20should%20store%20and%20index%20HSTS%20Policies%20within%20that%20partition%20based%20strictly%0A%20%20%20upon%20the%20domain%20names%20of%20the%20issuing%20HSTS%20Hosts.> . Ah what I meant is that storing and indexing HSTS Policies by the "domain name" and not "network partition key" is not part of his draft. It is part of the first line in section 5.3 <https://www.rfc-editor.org/rfc/rfc6797#section-5.3> of the RFC. In other words, his draft is not suggesting that the HSTS policies should be partitioned by the domain name, rather it is saying regardless of the key that is used for partitioning, within that partition the same mechanism of storing and indexing, domain name as described in the RFC, should be used. 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? Steven's draft mentions that as a suggestion. He left it open ended so Browsers can apply a their own solutions to it. In other words, Steven's draft modifies it to allow Browsers to do so without prescribing a specific method. Our solution and implementation is to "Only apply HSTS upgrades to top-level navigation requests". Can you point to which part of Steven's draft mentions the top-level navigation requests-only strategy as a suggestion? I cannot find it. In Steven's draft in section 3 <https://sbingler.github.io/hsts-tracking-prevention-spec/draft-bingler-hsts-tracking-prevention.html#name-hsts-tracking-prevention> he mentioned that there are three ways to prevent HSTS tracking, one of them is partitioning and the other two are "Prevent servers from setting tracking data" and "Prevent servers from retrieving tracking data". We are choosing to go with "Prevent servers from setting tracking data". 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? Based on "Safari blocks third-party HSTS responses <https://webkit.org/blog/8146/protecting-against-hsts-abuse/>" Safari limit HSTS State to the Hostname, or the Top Level Domain + 1 and also Ignore HSTS State for Subresource Requests to Blocked Domains (This is the part we do not do). Based on "Firefox blocks third-party HSTS responses <https://bugzilla.mozilla.org/show_bug.cgi?id=1701192#c15>" If there is a third-party response with HSTS header Firefox will ignore the HSTS header. 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. I think Steven made these tests specific to our solution. Since other browsers have a different solution to mitigate this problem it might not work for them. Can you give a bit more detail on what part of the test is testing behavior that Safari and Firefox do not agree with us on? I can't figure out from looking at the test code, and the failure, why they would not pass. The differences you mention above don't seem like they would cause step 3 to timeout. I think this is important because, in the absence of a strict specification, we need some guarantee that we're moving toward interoperability, on at least a subset of cases. Tests that pass in all browsers, showing that common interoperable subset, is the best way to lock that in. I do see your point. My answer was based on my conversations with Steven. I will get back to you on this, I need some time to familiarize myself with the two other browser solutions a bit more deeply to see what is going on here. I wanted to clarify the other two questions you had in this reply. 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/a895e5b7-d6d7-45e1-add3-fe7dd31832c2n%40chromium.org.
