9 ms·
This JavaScript can snoop on other browser tabs to work out what you're visiting
- montenegrohugo 8y agoThis sounds worrying. Shouldn't your browser prevent this from happening?
- tyingq 8y ago"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 8y agoThat works for throwing Shai Hulud off the track.
- leni536 8y agoI 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 8y agoLeave 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 8y agoIt'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 8y agoI can't be the only one who feels The Register _IS_ a tabloid. Not tongue-in-cheek.
- crankylinuxuser 8y agoYep. 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 8y ago> 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 8y agoSomewhat 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."
- ccnafr 8y agoIt's still clickbait, dear The Register employee.
- detritus 8y ago
- zhte415 8y agoThey 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,
- crispyambulance 8y agoNo. 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.
- code_duck 8y ago“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.
- Santosh83 8y ago""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?
- krig 8y ago”at the same time”
- indigochill 8y agoOr just disable Javascript.
- godshatter 8y agoOr use two different browsers.
- bzbarsky 8y agoWouldn'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...
- anyzen 8y agoNot 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?
- z3t4 8y agoI always thought timing in JS was very imprecise, so "timing attacks" wouldn't work!?
- shakna 8y agoThis 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.
- newscracker 8y ago> 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
- alceta 8y agoMy 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.
- cyphar 8y agoFrom 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.
- nuxi 8y agoFirefox Focus does have multiple tabs - long press on a link, then select "Open link in new tab".
- Groxx 8y agoTho 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".
- newscracker 8y agoMaybe 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.
- aidos 8y agoReading 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.
- travisoneill1 8y agoWould ad blockers block this attack by changing the signature of other open tabs?
- mettamage 8y agoIt'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.
- userbinator 8y agoDisabling 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 8y agoI'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.
- _jal 8y agoYeah, screw those sites. I do toggle JS on for select places that I have more trust in, but generally most places I browse work fine. 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.
- jniedrauer 8y agoEven 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.
- cm2187 8y agoI 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.
- tannhaeuser 8y agoJust 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/
- dandare 8y ago>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 8y agoIt'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.
- exabrial 8y ago> 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
- dahart 8y agoI 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 8y agoChrome 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_tabs https://developers.google.com/web/updates/2017/03/background...
- buboard 8y agoLots 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 8y agoThat already exists. <iframe name="my-iframe"></iframe><a href="/mycontent" target="my-iframe">load it!</a>
- eeZah7Ux 8y agoBrowsers 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.
- yawz 8y agoWhat 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 8y agoI 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 8y agoOnce you start using uMatrix, be prepared to never view the internet the same way again. The sheer quantity of malicious clientside traffic is stunning.
- yawz 8y agoThank you!
- dejaime 8y agoWell, anyone using Tor won't have JavaScript enabled anyway.
- tejtm 8y agoFinally, 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
- abetusk 8y agoFrom 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 8y agoIt 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?
- soared 8y agoUseful 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.
- theWheez 8y agoFor 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.
- ktosobcy 8y agoAll 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.