demo · v132
What history-sniff attacks does partitioning kill?
Eight classic history-sniff techniques. Six are now dead. Two are inherent to the platform and live on. Triple-keying does most of the work; the rest needed other mitigations years ago.
| attack | status | why |
|---|---|---|
getComputedStyle(a).color | BROKEN since 2010 | Mozilla bug 147777 — computed style for :visited returns the :link version |
| SVG background-image fetch in :visited | BROKEN since 2010 | same fix — no network requests differ by :visited |
| same-site, same-page brute-force scan | LIVES | partitioning doesn't help when the attacker IS the top-level site |
| cross-site sidechannel via layout (paint timing) | KILLED v132 | cross-site keys differ — nothing to time |
| cross-site CSS prefetch / link rel=prerender | KILLED v132 | cross-site key partition; not visited in this context |
| cross-site, paint-pixel cache-timing | KILLED v132 | same |
| same-site image with subresource integrity bypass | KILLED v132 (self carve-out is intentional) | own-site links DO leak own history — you already have it |
| history.length probing | LIVES | partitioning doesn't change history object — mitigations are separate |
two surviving attacks — what to know
Same-site brute force still works
If news.example is malicious, it can use :visited to figure out which of its OWN articles you've visited — that's the self carve-out. Partitioning protects you from other-site.example learning your news history; it cannot protect you from news.example learning its own history.
history.length probing
Reading window.history.length tells an attacker how many entries are on the stack (not what they are). This is a long-standing footprint vector that partitioning doesn't fix. Mitigations live elsewhere (browser caps, fingerprint protection).
see also
scenario focus
Select a scenario to focus its rendered example and summary.