On 2/25/25 2:55 AM, Yoav Weiss (@Shopify) wrote:
Thanks for pushing this!
On Monday, February 24, 2025 at 8:04:31 PM UTC+1 Andrew Williams wrote:
Contact emailsmiketa...@chromium.org, awil...@chromium.org
Explainer
HTTP cache partitioning in general is covered by
https://github.com/shivanigithub/http-cache-partitioning
<https://github.com/shivanigithub/http-cache-partitioning>, and
this proposal extends partitioning to navigations. This I2S and
the linked resources discuss the partitioning scheme changes and
the specific attack scenarios that are mitigated.
Specificationhttps://fetch.spec.whatwg.org/#http-cache-partitions
<https://fetch.spec.whatwg.org/#http-cache-partitions>
The spec doesn't seem to indicate any of this logic (nor does it
include triple keying AFAIU).
I don't think it's a blocker, but it'd be nice to get
cross-implementer alignment on the strategy here, or barring that, add
UA-defined conditions.
Triple-keying should be covered by
https://fetch.spec.whatwg.org/#determine-the-network-partition-key (see
"an implementation-defined value). There's ongoing discussion in
https://github.com/whatwg/fetch/issues/1035 as well.
A TPAC or three ago we had some conversations in on this topic, and IMO
there is interest in perhaps converging on the perfect design one day,
but I don't see cross-implementer alignment on a single keying scheme
coming any time soon. I think gsnedders also makes a good point in the
fetch issue that experimentation on keying schemes by UAs for different
modes is also useful to consider.
SummaryChrome’s HTTP cache keying scheme will be updated to
include an “is-cross-site-main-frame-navigation” boolean to
mitigate cross-site leak attacks involving top-level navigation.
Specifically, this will prevent cross-site attacks in which an
attacker can initiate a top-level navigation to a given page and
then navigate to a resource known to be loaded by the page in
order to infer sensitive information via load timing. This change
also improves privacy by preventing a malicious site from using
navigations to infer whether a user has visited a given site
previously.
For an overview of the attacks mitigated by the
“is-cross-site-main-frame-navigation” boolean, see:
-
https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass
<https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass>
-
https://docs.google.com/presentation/d/1StMrI1hNSw_QSmR7bg0w3WcIoYnYIt5K8G2fG01O0IA/edit?usp=sharing
<https://docs.google.com/presentation/d/1StMrI1hNSw_QSmR7bg0w3WcIoYnYIt5K8G2fG01O0IA/edit?usp=sharing>
Do I understand correctly that this will prevent "Attack 1" and
"Attack 2", but "Attack 3" is already mitigated by triple keying?
While attack 1 is clear, I'm not sure how come attack 2 isn't
mitigated by the fact that a.com/img is already partitioned.
Blink componentInternals>Network>Cache
<https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3ENetwork%3ECache%22>
TAG reviewHTTP cache partitioning was originally reviewed in
https://github.com/w3ctag/design-reviews/issues/424
<https://github.com/w3ctag/design-reviews/issues/424>. We did not
submit for a new TAG review since cache partitioning
standardization hasn’t changed much since then, and since it’s
unclear whether there’s support for updating standards to
partitioning by more than just top-level site.
TAG review statusNot applicable
Risks
Interoperability and CompatibilityInterop risk: We do not expect
compatibility impacts here since the behavior is not web-visible
(other than affecting navigation completion times), and our
earlier 1% experiment didn’t indicate any significant changes to
performance as a result of this. Regarding interop, Safari and
Firefox currently ship partitioned HTTP caches but with different
partitioning schemes that don’t partition navigations differently
from other network requests.
Gecko: https://github.com/mozilla/standards-positions/issues/1177
<https://github.com/mozilla/standards-positions/issues/1177>
WebKit: https://github.com/WebKit/standards-positions/issues/462
<https://github.com/WebKit/standards-positions/issues/462>
Web developers: No signals
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?No - cache partitioning is not enabled for WebView
DebuggabilityPartition keys are visible in net logs, and whether
something was served from the HTTP cache is visible in DevTools.
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?No,
it will be supported on all platforms except WebView, which does
not currently partition its HTTP cache.
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?No,
this isn’t web visible.
Flag name on chrome://flagsNone
Finch feature nameSplitCacheByCrossSiteMainFrameNavigationBoolean
Requires code in //chrome?False
Launch bughttps://launch.corp.google.com/launch/4345002
<https://launch.corp.google.com/launch/4345002>
Estimated milestones
Shipping on desktop
135
Shipping on Android
135
Anticipated spec changesOpen 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).The spec already leaves the
HTTP cache key as implementation-defined apart from partitioning
by top-level site. It's unclear whether other browsers support
standardizing any portion of what we are shipping.
Link to entry on the Chrome Platform
Statushttps://chromestatus.com/feature/5190577638080512
<https://chromestatus.com/feature/5190577638080512?gate=5181053938171904>
Links to previous Intent discussions
Intent to Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkV1oQg2cc_MWW_RtG9de%3DVk2i1rUv8MrQ49GV0yWZwy_w%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkV1oQg2cc_MWW_RtG9de%3DVk2i1rUv8MrQ49GV0yWZwy_w%40mail.gmail.com>
--
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/0e9fd7e0-87ba-4a07-ba77-2d4178ca881b%40chromium.org.
