FYI, it looks like WebKit is trending supportive on this change:
https://github.com/WebKit/standards-positions/issues/462#issuecomment-2693662676
On 3/2/25 9:32 PM, Domenic Denicola wrote:
LGTM2.
I'm saddened by the way the implementer community has not been able to
converge upon and specify a unified keying scheme, but I agree we
shouldn't block further improvements on that, since none of the
browsers seem to be making movements toward such alignment. I
appreciate that you pinged
<https://github.com/whatwg/fetch/issues/1035#issuecomment-2658239821>
the relevant thread to see if there's any movement.
On Thursday, February 27, 2025 at 1:23:43 AM UTC+9 Chris Harrelson wrote:
LGTM1
On Tue, Feb 25, 2025 at 7:54 AM Mike Taylor
<miketa...@chromium.org> wrote:
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
<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
<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 <http://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
<mailto: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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e9fd7e0-87ba-4a07-ba77-2d4178ca881b%40chromium.org?utm_medium=email&utm_source=footer>.
--
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/c9e93ea5-0b83-4389-a8b5-d15a48e1153f%40chromium.org.
