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.> . > > > > > 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. > > > > 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. > > > > > > 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/ch > romium.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/CAM0wra82TCsvZxT14z-01eAmGUrNUDcUGrOQCEROqOWrqdF8Ng%40mail.gmail.com.
