
This JavaScript can snoop on other browser tabs to work out what you're visiting - AndrewDucker
https://www.theregister.co.uk/2018/11/21/unmasking_browsers_side_channels/
======
leni536
I think it would be more appropriate to link the paper[1] and use its title
(as it's much more descriptive).

[1] [https://arxiv.org/abs/1811.07153](https://arxiv.org/abs/1811.07153)
Robust Website Fingerprinting Through the Cache Occupancy Channel

~~~
ccnafr
Leave it to The Register to clickbait the research. This is nothing new btw.
Side-channel attacks on other tabs have been known for more than a decade, and
is one of the legitimate reasons why the NoScript plugin was developed, among
others.

~~~
detritus
It's not ‘clickbait’, it's a headline. It's meant to attract attention and
engage the user. See the red top header The Register uses? That's a nod to
British tabloid newspaper mastheads going back decades, and The Register
likens itself to similar hovels of deplorable journalist talent-waste.

Not everything is some clinically cynical attempt to con the contemporary
reader — sometimes such effort is intentionally tongue-in-cheek for a knowing
readership.

~~~
efdee
I can't be the only one who feels The Register _IS_ a tabloid. Not tongue-in-
cheek.

~~~
crankylinuxuser
Yep. It feels like the "IT National Enquirer".

* SEE WHAT INTERNET EXPLORDED DID BEHIND THE SCENES!

* 10 SECRETS FIREFOX DOESN'T WANT YOU TO KNOW

* USING A FREE VPN? WHY NOT SKIP THE MIDDLEMAN AND SEND YOUR DATA TO XI JINGPING?

* MICROSOFT: YOU LOOKIN AT ME FUNNY? OH, YOU JUST WANT TO SIGN IN

(Btw, the last 2 are legit, from the website right now...)

~~~
admax88q
> USING A FREE VPN? WHY NOT SKIP THE MIDDLEMAN AND SEND YOUR DATA TO XI
> JINGPING?

That's a great headline. What's your problem with it? Does IT journalism need
to be dry and purely technical?

~~~
detritus
Somewhat ironically, The Register has a misbegotten step-sibling,
[https://www.theinquirer.net/](https://www.theinquirer.net/) [1], which tends
towards the dry and purely technical and I've always found it thoroughly
unenjoyable.

[1] I can't remember the history [2], but long ago there was some disagreement
and subsequent parting of ways and The Inquirer was born

[2] Wikipedia does though, obviously:
[https://en.wikipedia.org/wiki/The_Register](https://en.wikipedia.org/wiki/The_Register)
"[co-founder Mike] Magee left in 2001 to start competing publications The
Inquirer, and later the IT Examiner and TechEye."

------
aidos
Reading the paper it seems that this effectively messes with the cache to see
how much it's being accessed generally, and based on that access pattern
creates a fingerprint that can be matched against the way another website uses
the cache generally.

Presumably, having several tabs open makes it pretty hard to distinguish one
site through the noise. Unless it's Slack, then the fingerprint looks like a
giant blob of constant data access...I jest I jest.

From the paper:

 _The main difference is that the Prime+Probe attack measures contentions in
specific cache sets, whereas our attack measures contention over the whole
cache. Specifically, our JavaScript attack allocates an LLCsized buffer and
measures the time to access the entire buffer.

The victim’s access to memory evicts the contents of our buffer from the
cache, introducing delays for our access. Thus, the time to access our buffer
is roughly proportional to the number of cache lines that the victim uses._

------
userbinator
_Disabling JavaScript completely will kill off the attack, but also kill off a
lot of websites, which rely on JS functionality to work._

All the more reason to not have JS on by default, and oppose the growing
population of sites which unnecessarily use it. That's been my configuration
for many years, and in my experience the vast majority of sites I visit do not
require it; in fact, contrary to the frequent "please enable JavaScript for a
better experience" banners I see, they're better off without. I'm not against
JS in general because there are useful "appsites" that can't serve their
purpose without it; just against the practice of allowing your machine to run
arbitrary untrusted code by default.

~~~
ic4l
I'm not sure what sites you're visiting but most sites i have attempted to use
with JS disabled simply did not function and thought I was a robot. I was then
presented with a human verification process that required javascript to run.

But yes I can disable javascript on HN.

~~~
jniedrauer
Even more irritating are sites that just appear as a blank page with
javascript disabled. If your site requires javascript to load _any_ content
then you've done something wrong.

Fortunately these tend to be clickbait type sites which I am visiting against
my better judgement. Not being able to load them without javascript is a good
reminder to not load them at all.

------
mettamage
It's always the cache. Caches are evil! (security) No! Caches are amazing
(speed). Fun fact: I never understood caches that well, until I learned about
geo-caching and learned what caches were used for back in the day of yore!

Inclusive caches are a huge culprit security wise. If you can perform any
variation on the clflush instruction by building eviction sets [1] then you
are good to go to perform somekind of operation you're not allowed to do.

I feel that processor vendors are using their undocumented security by
obscurity too much. Though I don't know if they do it intentionally or that
these things happen merely via company processes and it's just tough to build
a reliable safe processor.

Safe cache design simply ain't easy, not even in 2018. The hype is attacking
inclusive caches in most cache attacks, but even when you build other things,
hardware hackers will basically look at the computer schematics of everything
again and they'll ask themselves how they're able to get that nice primitive
back of inclusive caches [2].

[1] Algorithmically defined memory addresses that will kick your target
cacheline out by flooding the same space.

[2] The primitive is: an inclusive cache by current design standards has a
shared last level cache. Kick target cachelines out there and you're flushing
a part of private caches from other processor cores as well.

~~~
finchisko
I wouldn't say caches are evil. Shared caches are.

------
dahart
I see a lot of suggestions to throttle or randomize the cache somehow, and
none to stop JavaScript for background tabs. What are the reasons that
disallowing background JS might not be preferable? Doesn’t Safari do this by
default? And I’m not sure but I imagine that even allowing a background
timeslice every once in a while would allow for background notifications and
connections while preventing timing attacks?

~~~
MuppetMaster42
Chrome throttles background JavaScript by default (disables
requestAnimationFrame entirely, reduces allowed runtime to around 1% of real
time, etc) [1].

However disabling it entirely would break a lot of use cases.

Chat apps would stop working, push notifications would no longer come, web
sockets would stop getting processed, feeds would not get refreshed. You'd
break a lot of the web.

Doing so would force more companies to push out their own separate apps...
Which would probably be electron (and I know how much HN hates electron).

[1]
[https://developers.google.com/web/updates/2017/03/background...](https://developers.google.com/web/updates/2017/03/background_tabs)

------
dandare
>This fingerprinting attack involves using JavaScript to measure processor
cache access latency over time as websites are loaded

Can someone explain to me how exactly can JavaScript measure processor cache
access latency? Also, isn't the performance of inactive tab supposed to be
throttled?

~~~
gowld
It's not a direct measurement, but a program can request an action ("get data
from a website") and measure how long it takes. Short time implies cached.

------
abetusk
From the paper [1]:

    
    
        Each round of attack consists of three steps.
        In the first step, the cache is primed, i.e.,
        the attacker completely fills some of the
        cache sets with its own data.  The attacker
        then waits some  time  to  allow  the
        victim to execute. Finally, the attacker
        probes the  cache  by  measuring  the  time
        it takes to access the previously-cached
        data ...
    

From a brief glance, it looks like they then use the timing to feed into a
deep neural network classifier.

[1] [https://arxiv.org/abs/1811.07153](https://arxiv.org/abs/1811.07153)
(thanks leni536)

~~~
crispyambulance
It seems like a very difficult and iffy technique to get NOT a lot of
information.

We're talking here about an attacker finding out what website domain names are
open in other tabs on a target's browser? Is that a big deal?

~~~
theWheez
For you and me, probably not, but perhaps of interest to a state agency to
attempt to profile the use of sites by a foreign intelligence's members.

It is probably difficult to say which sites one is using, but an easier task
would be to profile by time and IP address that it seems that this group of
people visits site A a lot around X time.

------
tannhaeuser
Just another reason to use noscript or other blockers. Why was it a good idea
to turn browsers into receivers for arbitrary script code again? I guess we
should at least endorse GNU's LibreJS [1] and enforce subresource integrity to
check the script executed by your browser is verifiable, even though LibreJS
aims for OSS principles. As a bonus, you'll find that web sites sending crap
script aren't worth visiting anyway ;)

[1]:
[https://www.gnu.org/software/librejs/](https://www.gnu.org/software/librejs/)

------
travisoneill1
Would ad blockers block this attack by changing the signature of other open
tabs?

------
montenegrohugo
This sounds worrying. Shouldn't your browser prevent this from happening?

~~~
tyingq
_" we simply do not need high-resolution timers for the attack"_

Not sure there's a lot they could do, short of apis that actively tell lies or
introduce deliberate random pauses.

~~~
unknownkadath
That works for throwing Shai Hulud off the track.

------
anyzen
Not sure if I understand this correctly, but the attacker's JS must load the
pages in question to see if they are in cache, right?

Wouldn't that put also them in cache, which means that next time this
technique is used it will not work? Even more, there is now plausible
deniability: "I never saw these pages, I guess some JS must have been snooping
around and put them to my cache..."

And the logical workaround is disabling cache, which helps fight against other
tracking techniques too.

All in all, this doesn't sound so worrying. Unless I missing something?

~~~
leni536
> _And the logical workaround is disabling cache,..._

The attack uses the CPU cache, not the browser cache.

~~~
anyzen
Thank you for the clarification!

------
tejtm
Finally, my lazy habit of ending up with several hundred open tabs may be
considered a safety feature, diluting the cache fingerprints to a faint
whisper

------
Santosh83
""If you want to visit sensitive and non-sensitive websites at the same time,
use two different computers," they said."

Or just visit them one after the other, one tab at a time right?

~~~
godshatter
Or use two different browsers.

~~~
bzbarsky
Wouldn't matter, if the attack works as described. It's already exfiltrating
data cross-process due to the processes sharing a resource (the CPU cache). It
doesn't matter whether the processes are the same browser or different
browsers.

Now the actual "cache fingerprint" of a particular pageload might be different
in different browsers, so it might not be possible to differentiate "site A
loaded in Firefox" and "site B loaded in Chrome". Or it might be, and then you
know not only what sites the user is visiting but what browser they're using
to do it...

------
buboard
Lots of single-page websites could be remade without javascript if only there
was a way to do ajax requests with html tags e.g. <a axref="" target="my-div"
...

~~~
unilynx
That already exists. <iframe name="my-iframe"></iframe><a href="/mycontent"
target="my-iframe">load it!</a>

------
newscracker
> _The takeaway, they contend, is that anything short of running a single
> browser tab at any one point in time poses a privacy risk: if you open a
> second tab, JavaScript in it can snoop on the other tab. Disabling
> JavaScript completely will kill off the attack, but also kill off a lot of
> websites, which rely on JS functionality to work._

Firefox Focus [1], my most used browser (single tab only), seems to be safe
from this attack.

[1]:
[https://en.wikipedia.org/wiki/Firefox_Focus](https://en.wikipedia.org/wiki/Firefox_Focus)

~~~
nuxi
Firefox Focus does have multiple tabs - long press on a link, then select
"Open link in new tab".

~~~
Groxx
Tho if you switch between tabs, you'll see a full load of the tabbed page. I
suspect it doesn't actually have "tabs" (i.e. running in the background like
basically every other browser tab), just "saved URLs".

------
ktosobcy
All more joy that I took the plunge and went JS-off by default with a couple
of exceptions. Majority of the web works just fine, if not better.

------
yawz
What is the most intuitive Chrome extension that you've used to block
JavaScript on every site and to create a whitelist as you went?

~~~
whitelister
I recommend uMatrix. At first it will take a few minutes to understand how it
works, though.

You can turn on and off images, css, scripts, XHR, etc, for individual sites
or globally.

I use it in that manner, with scripting off by default. If I am visiting a new
site that needs javascript, I gradually whitelist specific bits until it works
and then "save" those settings for that domain.

~~~
jniedrauer
Once you start using uMatrix, be prepared to never view the internet the same
way again. The sheer quantity of malicious clientside traffic is stunning.

------
exabrial
> processor cache occupancy

Shoot, why not just browser cache occupancy? Is it possible to fingerprint the
New York times as JavaScript and check to see if it's loaded out of the cache?

> Boffins

Ah the register... Always gives me a chuckle, especially the never ending beer
'curing' everything series

------
dejaime
Well, anyone using Tor won't have JavaScript enabled anyway.

------
z3t4
I always thought timing in JS was very imprecise, so "timing attacks" wouldn't
work!?

~~~
shakna
This particular attack doesn't rely on high-precision timing, or cache layout.
It measures CPU cache latency, and that's enough to create a fingerprint.

If JS still had high-precision timing, then side-channel attacks with better
information resolution are possible.

------
eeZah7Ux
Browsers and javascript has been security disasters for decades and yet the
web crowd perpetuates this model and even plans for webassembly.

Large webassembly applications will make it extremely difficult to inspect
suspicious code for this kind of attacks.

Dodgy ad providers will exploit similar vulnerabilities to better track user
behavior or worse.

Yet, there isn't an ongoing discussion on limiting the resources available to
random websites. The idea of not enabling js by default is seen as absurd.

Good luck to all of us: browsers are developed by companies selling ads.

EDIT: Judging by the downvotes looks like I struck a nerve.

~~~
gowld
This isn't a language problem, it's a computers and networking problem.

~~~
eeZah7Ux
I didn't say it's a language problem. The problem is having to run arbitrary,
not vetted code from random sources just to book a flight or order a pizza.

