I am updating here on behalf of Steven since he is OOO. We have updated the chrome status gates <https://chromestatus.com/feature/5072685886078976>.
On Monday, March 24, 2025 at 1:53:46 AM UTC-4 [email protected] wrote: > Can you request privacy, WP security, enterprise, debuggability, and > testing gates on Chrome Status? > > On Friday, March 21, 2025 at 5:22:57 PM UTC+9 Steven Bingler wrote: > >> Contact [email protected], [email protected], >> [email protected] >> 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> >> >> 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. >> 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/>. >> >> 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> >> 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/78af0afc-9c00-4bab-b148-5e259b068214n%40chromium.org.
