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.
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.
Somewhat ironically, The Register has a misbegotten step-sibling, 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 "[co-founder Mike] Magee left in 2001 to start competing publications The Inquirer, and later the IT Examiner and TechEye."
They are not 'clickbaiting' it in the web-sense, they're just doing what they do with all stories:
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,
No. The Register's "clickbait" title is better and more descriptive.
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.
“Robust Website Fingerprinting“ sounds like something that is done to a website, not a user. It depends on your audience. I don’t think HN is quite that specialized.
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...
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?
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.
> 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.
My Firefox Klar (Focus in German market) does have multiple tabs. But since the entire application is shorter-lived, I never tend to have many tabs open.
From my usage the "tabs" appear to be more like temporary bookmarks. When you switch between them, the page loads from scratch. So even when using tabs it might be protected against.
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".
Maybe you're in a different platform and/o country? It doesn't and hasn't had more than one tab on iOS for me from the time it launched till now. I'm typing this comment from Firefox Focus and a long press on any link shows "Open" as an option, but nothing related to tabs.
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.
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.
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.
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.
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.
I agree on the unnecessary use of javascript and the madness of inviting anyone to run code on your own machine, but not on the browsing experience with js off. I used to do that but stopped given the high number of websites that are dysfunctional or simply show a blank page with js off. Why some developers think they need js to display a blog article is beyond me (well, web "developers") but the web is now pretty unusable without javascript. Even adblockers break many websites.
Hah, I'm thinking of making a little banner that says something like
"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.
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 ;)
>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?
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.
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
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?
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).
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" ...
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.
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.
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.
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.
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
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.
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.
Useful for advertisers. If you have amazon.com open that good to know. But if you have amazon.com, sears.com, and appliances.com, then I know you are actively researching major appliances and I need to advertise my brand to you ASAP.
67 comments
[ 7.1 ms ] story [ 183 ms ] threadNot sure there's a lot they could do, short of apis that actively tell lies or introduce deliberate random pauses.
[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."
As for your earnest insistence — I'd perhaps loosen literality a touch ;)
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.
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...
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.
If JS still had high-precision timing, then side-channel attacks with better information resolution are possible.
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
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.
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.
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:
https://addons.mozilla.org/en-US/firefox/addon/noscript/
"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.
[1]: https://www.gnu.org/software/librejs/
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?
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
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...
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.
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.
[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.