This JavaScript can snoop on other browser tabs to work out what you're visiting
theregister.co.uk
theregister.co.uk
[1] https://arxiv.org/abs/1811.07153 Robust Website Fingerprinting Through the Cache Occupancy Channel
Not everything is some clinically cynical attempt to con the contemporary reader — sometimes such effort is intentionally tongue-in-cheek for a knowing readership.
* 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...)
That's a great headline. What's your problem with it? Does IT journalism need to be dry and purely technical?
[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 "[co-founder Mike] Magee left in 2001 to start competing publications The Inquirer, and later the IT Examiner and TechEye."
They use UK tabloid newspaper style headings, have always used this style, and probably will always use this style. It's not clickbaiting, it's a parody on UK newspapers then with an informative article, usually with plenty of sarcasm.
I don't think The Register is looking for Google click-through revenue for people with a search phrase consisting 'cacheflow', 'javascript', and 'browser tabs'.
The article explicitly mentions
> Side-channel attacks on other tabs have been known
Yes, it mentions that, and
> one of the legitimate reasons why the NoScript plugin was developed
It didn't mention NoScript, indeed it didn't. But it did mention the general case
> Disabling JavaScript completely will kill off the attack,
I (and most other people?) have NO IDEA what the "Cache Occupancy Channel" is, nor is it clear from the title of original source article that this is about a technique that allows an attacker to potentially determine what websites the target is visiting on other tabs in target's browser.
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.
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.
But yes I can disable javascript on HN.
There is no site so wonderful and special that I'll tailor my operating environment to suit their business model for the privilege of viewing it.
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.
https://addons.mozilla.org/en-US/firefox/addon/umatrix/
https://chrome.google.com/webstore/detail/umatrix/ogfcmafjal...
or:
"Hi! It seems you have Javascript enabled by default. While on this site, Javascript enables [features], it's a good security practice to use [browser extensions] to enable it on a per-site basis.
Many malicious practices depend on Javascript, and can leave you open to damage to your things like leaking of personal information (including any site knowing what other browser tabs you have open), and combining that information with other information ad trackers have gathered on you to be used by who knows who for who knows what reasons. One thing is sure, it likely won't be anything you initiated or wanted.
For any site that requires you to expose yourself to harm to get content, you might be able find one that has the better content and respects you, if you look some more. If it's not made from 100% ethical craftsmanship, you deserve better! So check out our web ring; we're the good guys, and you're a bad person if you don't agree.
[web ring stuff]"
Well, roughly like that :P And yeah, I know it all falls down when the banner keeps showing up when a user enabled Javascript with an extension :(
Seriously though, I agree with you, and I think it's silly to be on the defensive. Bring back web mastery, at least as a niche, that people who want that can find, and where people give each other shit for sites not being "ethical" (for lack of a better shorthand) or backwards-compatible enough, too bloated, bad with screen-readers etc.. I would find that refreshing, actually. It technically never went away, the universe just expanded so quickly. There's still sites made like that, there's still good tutorials, but they're in the backseat of the huge "world of web dev", and could be be actually driving in their own niche. Confidence, maybe some principles and a way to affirm them, and users to find or recognize sites that affirm them, is really all that's needed.
I guess calling it "ethical" is not great branding, but surely people have already come up with (and maybe organized) what I mean, with a better phrase for it? If anything comes to mind, just shout it out please.
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.
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...
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?
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 ...
[1] https://arxiv.org/abs/1811.07153 (thanks leni536)
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?
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.
Not sure there's a lot they could do, short of apis that actively tell lies or introduce deliberate random pauses.
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?
The attack uses the CPU cache, not the browser cache.
Or just visit them one after the other, one tab at a time right?
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...
Firefox Focus [1], my most used browser (single tab only), seems to be safe from this attack.
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.
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
If JS still had high-precision timing, then side-channel attacks with better information resolution are possible.
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.