In your slides you write:
const handle = window.open(“a.com/”)
...
<Use timing to infer prior visit>
I assume here that you can poll "handle" to see when it changes from a
document you can access to one you cannot access? Could that information
leakage have been fixed instead of making a.com load slower?
/Daniel
On 2025-02-24 19:58, Andrew Williams wrote:
Hey everyone,
We ran this experiment and found no significant changes for the core
web vital metrics or for the Chrome Guardrail metrics. We also
conducted an in-depth analysis of multiple internal performance
metrics and the results from that support moving forward with adding
the "is-cross-site-main-frame-navigation" boolean to the HTTP cache.
We will follow-up with an Intent-to-Ship for this soon. :)
If anyone has any questions about this experiment please let me know.
Thanks!
-Andrew
On Fri, Sep 13, 2024 at 10:51 AM Andrew Williams
<awil...@chromium.org> wrote:
> I'd love to better understand the attack scenario.
I recently put together the following presentation that
illustrates the attack scenarios this aims to mitigate:
https://docs.google.com/presentation/d/1xnGpRCyLQnLjvGLMqKZUUDCKZANFhedJyF063S7ifLE/edit?usp=sharing
TL;DR: the attacks involve a malicious site triggering a
navigation to a cross-site document and/or resource and using
timing to leak state.
> I understand that this experiment is going to collect data for
presenting potential changes to the behaviour.
That is correct, the goal of the experiment is to collect data so
that we can decide whether/how to proceed w.r.t. addressing
cross-site leaks from navigations. We would continue to use the
blink-dev process for actually shipping changes related to this.
Thank you!
-Andrew
On Wed, Sep 11, 2024 at 5:53 PM Alex Russell
<slightly...@chromium.org> wrote:
Per today's API OWNERS conversation, I understand that this
experiment is going to collect data for presenting potential
changes to the behaviour. Assuming that's right, LGTM1.
Best,
Alex
On Wednesday, September 11, 2024 at 6:17:26 AM UTC-7 Yoav
Weiss wrote:
I'd love to better understand the attack scenario.
On Friday, September 6, 2024 at 5:40:55 AM UTC+2 Andrew
Williams wrote:
Contact emails
miketa...@chromium.org, awil...@chromium.org
Explainer
None yet.
Specification
https://fetch.spec.whatwg.org/#http-cache-partitions
<https://fetch.spec.whatwg.org/#http-cache-partitions>
Summary
We aim to experiment with utilizing the initiator site
when caching the responses of cross-site navigations
in the HTTP cache. This experiment is intended to test
a potential mitigation for cross-site leak 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.
bad.com <http://bad.com> navigates the user to victim.com
<http://victim.com> (at the top-level??). What happens then?
The tested mitigation is also intended as a privacy
improvement since it will make it more difficult for a
malicious site to use navigations to infer whether a
user has visited a given site previously.
But if one site navigated to another, it doesn't get any
timing info about the "navigated to" site, right?
Blink component
Internals>Network>Cache
<https://bugs.chromium.org/p/chromium/issues/list?q=component%3AInternals%3ENetwork%3ECache&can=2>
TAG review
Not requested yet.
Risks
Interoperability and Compatibility
We do not expect compatibility impacts here, but there
may be some performance implications. Safari and
Firefox currently ship some notion of partitioned HTTP
caches. We will seek their input once we have a better
idea of the tradeoffs between security/privacy and
performance.
Gecko: No signal requested yet.
WebKit: No signal requested yet.
Web developers: No 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
Goals for experimentation
We would like to run a 1% stable experiment to
understand the performance implications of several
approaches to implementing this HTTP cache security
improvement. We expect 6 weeks to be sufficient for
analysis, beginning in M129, but are requesting
permission to run from M129 to M131 inclusive in case
we run into any delays.
The approaches we’d like to experiment with are:
*
Adding a boolean value to the HTTP cache key that
is set to true for top-level navigations to a URL
that is cross-site from the initiator site of the
navigation
*
Adding the initiator site into the HTTP cache key
for top-level navigations to a URL that is
cross-site from the initiator site of the
navigation. If the initiator has an opaque origin
(for instance, if the initiating page was loaded
from a data: URL or is a sandboxed iframe) then no
caching of the navigation response will occur.
*
Adding the initiator site into the HTTP cache key
for all navigations (including subframe
navigations) in the same way as the previous
approach. With this scheme we’d also replace use
of an existing HTTP cache key component (called
the “is-subframe-document-resource” boolean, set
to true for all subframe navigations) designed to
mitigate related attacks from malicious subframes.
This scheme is expected to have similar
performance characteristics to the previous
approach but would make Chromium’s handling of
main frame and subframe navigations consistent.
Incorporating the initiator into the HTTP cache key
will mean that the responses from renderer-initiated
navigations will not be re-used across contexts with
different frame sites or top-frame sites. This could
affect the page load times for previously visited
sites in cases where loading a page over the network
is slower than loading the page from the local disk
cache. Renderer-initiated navigations corresponding
to, for example, clicking links on a site, site
redirects, and link prefetches that use
“as=’document’”. Incorporating the
‘is-cross-site-top-level-navigation’ boolean is
expected to have the least impact on performance since
it allows the most amount of response re-use.
Incorporating the full initiator site is expected to
have the most impact since there is less re-use with
these cache partitioning schemes, but this approach
may enable future HTTP cache performance optimizations
that are not possible today due to cross-site leak risks.
Debuggability
No special needs.
Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, ChromeOS, Android, and
Android WebView)?
No
All 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
Flag name on chrome://flags
None
Finch feature name
There are several feature flags, one per experiment
partition key format:
*
SplitCacheByCrossSiteMainFrameNavigationBoolean -
Enables use of the is-cross-site-navigation
boolean in the HTTP cache key for main frame
navigations with cross-site initiators
*
SplitCacheByMainFrameNavigationInitiator - Enables
use of the initiator site in the HTTP cache key
for main frame navigations with cross-site initiators
*
SplitCacheByNavigationInitiator - Enables use of
the initiator site in the HTTP cache key for all
navigations with cross-site initiators and
disables use of the existing
“is-subframe-document-resource” boolean.
Requires code in //chrome?
To facilitate conducting the experiment we have code
to clear chrome’s HTTP cache when the experiment is
conducted, but otherwise no code in //chrome is needed.
Estimated milestones
M129 to M131 inclusive.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5190577638080512
<https://chromestatus.com/feature/5190577638080512?gate=5181053938171904>
--
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/CAEa0%2BkWHa_GyD6%3Du7emyXTOxWwrRvM%2B_xXSUCiVUHod9ihsEnQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkWHa_GyD6%3Du7emyXTOxWwrRvM%2B_xXSUCiVUHod9ihsEnQ%40mail.gmail.com?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/f4419d38-36bc-4170-ba02-d324cbab516b%40gmail.com.
