FPI & Cache Occupancy Channel FP'ing [Tor 28621]

[Thorin-Oakenpants]

Paper: https://arxiv.org/abs/1811.07153
Article: https://www.theregister.co.uk/2018/11/21/unmasking_browsers_side_channels/

@tomrittervg : does FPI mitigate this, or what about disabling cache(s) (disk, memory)? Or is this something that can only be blocked by timing, eg FuzzyFox down the track? Or is this a bit old and we're already OK? Asking for a friend 😁

edit: ok, spose I better read it first

But this latest browser fingerprinting technique doesn't need a high-precision timer because it focuses on processor cache occupancy

[earthlng]

what about disabling cache(s) (disk, memory)?

page 11:

When we keep the browser’s response cache, the advan-
tage of cache-based website fingerprinting starts to emerge.
As Table 6 shows, the accuracy of the standard network-
based methods degrades when the response caching is en-
abled. We can see a degradation in accuracy of over 20% in
the fingerprinting accuracy.
In contrast, the cache-based methods are largely unaf-
fected by the reduction in network traffic, achieving high
accuracy rates. This result supports the conclusion that the
cache-based detection methods are not simply detecting the
CPU activity related to the handling of network traffic, mak-
ing them essentially a special case of network-based clas-
sifiers, but are rather detecting rendering activities of the
browser process.

so no, disabling disk or memory cache does not mitigate it

They're measuring rendering "time" (not really but let's go with that for simplicity) of sites loaded in other tabs/windows or even other browsers and comparing it against a pre-generated "table" of rendering times for certain sites. I don't see how FPI would have any effect on that at all.

It's definitely interesting but not very practical for a general purpose, wide-range attack. Different hardware will produce very different "times" and even using something simple like blocking all 3rd-party request will have a major impact on rendering times. So basically they can't just use one table to attack normies and power-users alike.
Could be very effective in targeted attacks though but I'm not worried about that.

[earthlng]

ps: blocking workers will almost certainly make this attack impossible

[Thorin-Oakenpants]

blocking workers will almost certainly make this attack impossible

workers cannot be blocked (unless via an extension?). Do you mean service workers?

[earthlng]

no-workers: * true in uMatrix

[Thorin-Oakenpants]

so do you mean workers, or service workers (yup, I know SW's requires workers)? The description from uM says "web workers"

[earthlng]

of sites loaded in other tabs/windows or even other browsers

page 5:

In this work we discuss a different attack model, presented
in Figure 2. In this model, the target user has two concur-
rent browsing sessions. In one session, the user browses to
an adversary-controlled site, which contains some malicious
JavaScript code. In the other session, the user browses to
some sensitive web site. These two sessions can be carried
out on the same browser, on two different browsers belong-
ing to the same user, or even on two browsers residing in
two completely isolated virtual machines which share the
same underlying hardware.

[earthlng]

FFS! duckduckgo -> mozilla workers

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
... has examples and everything!
demo for what I called workers and they call "Dedicated workers": https://mdn.github.io/simple-web-worker/
demo for shared workers: https://mdn.github.io/simple-shared-worker/

they call both of these things "web workers" so uM is totally correct in its description

[earthlng]

thanks btw for linking all these interesting research papers here though, much appreciated 💋

[earthlng]

uMatrix uses the worker-src CSP to block

Worker, SharedWorker, or ServiceWorker scripts

[Thorin-Oakenpants]

uMatrix uses the worker-src CSP to block

Worker, SharedWorker, or ServiceWorker scripts

That's what I assumed (and probably knew), but I wanted you to be more EXPLICIT in your definition, which is why I asked, TWICE. Thanks for finally getting around to it 💋

PS: Don't assume anything (from your now edited comment) - I do things for a reason, mostly .. at night, mostly

[Thorin-Oakenpants]

FYI: https://trac.torproject.org/projects/tor/ticket/28621

[Atavic]

Countermeasures in JavaScript. [...] now all mainstream browsers incorporate this
countermeasure.

We have these:

// privacy.reduceTimerPrecision
// privacy.resistFingerprinting.reduceTimerPrecision.microseconds

Table 5 has a Firefox 59 with time resolution of 2.0 ms, that corresponds to a
privacy.resistFingerprinting.reduceTimerPrecision.microseconds value of 2000

See: #448 (comment)

[Thorin-Oakenpants]

update: email from Tom Ritter

I skimmed it. This one kind of sucks. There are no reasonable countermeasures. Page coloring looked interesting, but AFAICT that was an idea from the early 2000s that hasn't been revisited?

The 100ms resolution helps; but it isn't the complete answer (and I want to reduce it anyway if we can achieve the same security boundary using fuzzyfox.)

Maybe the answer is something more complicated? Degrading it dynamically (throttling) if we detect repeated calls and throw a permission prompt (with or without the doorhanger)?

Just follow the relevant Tor ticket 28621 - I don't think there is a corresponding bugzilla