Browser history sniffing is still a thing
A team of Stanford and UC San Diego researchers published the research paper Browser history re:visited recently in which four new, and working, browsing history sniffing attacks are revealed to the public.
Attacks that attempt to find out which sites a user visited are not anything new. Mozilla, for example, plugged a leak in 2010 that allowed site owners to use CSS to check a list of sites against a user's browsing history using CSS.
The researchers found attacks that date back to 2002 using the :visited selector to determine whether a user on the site visited a linked resource previously.
The leak attacks affect all modern browsers that don't block the storing of the browsing history; in other words, Firefox, Chrome, Internet Explorer and Microsoft Edge are vulnerable while Tor Browser is not.
Most web browsers keep track of the visited resources by default; this is a convenience feature that is baked into the browser. Browsers may suggest these resources again when users type into the address bar and users may search visited sites in case they need to revisit them but can't remember the exact URL anymore.
The first attack that the researchers discovered uses the CSS Paint API to determine whether a particular URL was visited by a user by "crafting a link element that gets re-painted only if its associated URL is visited" and monitoring timing information to determine if a re-paint event took place.
The second attack uses CSS 3D transforms, a technique introduced with CSS version 3. An attacker would stack 3D transforms on other CSS styles to create link elements and toggle "the link element between two different destination URLS" to identify re-paint operations.
The third attack uses SVG images and the CSS fill rule. The attack embeds a complex SVG image inside a link element and uses a "series of CSS fill rules under :visited selectors" to determine the visited status of a link.
The fourth and final attack uses Chrome's bytecode cache to determine whether a JavaScript source file was loaded previously in the browser as these files are shared between pages of different origins.
All four attacks have in common that they need to specify URLs to check; none manages to retrieve a user's entire browsing history.
How effective are these attacks? The researchers state that one of the attacks can determine the state of 6000 URLs per second; enough to check the most popular sites against the browsing history.
The researchers reported the issues to browser developers but patches for these attacks may take months to implement.
You can read or download the research paper in PDF format here.
there’s a mistake in this article.
it’s 3,000 URLs per second, not 6,000
Complete novice here. If you set rour browser up to highlight every Link, including unvisited sites. would that not make any data that was picked up by the sniffer redundant ? If you can do that that is.
Ask that question the other way around: What can the web developers do:
https://css-tricks.com/almanac/selectors/v/visited/
What does the browser vendor?
Read ☞ “Little White Lies (about history stealing)”
https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector#Little_white_lies
See also
https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector#See_also
AFAIK everything that can be deleted can be with the “Clear All History” panel and also from the Privacy & Security page in Options, when the right options are picked. IndexedDB and I believe the cache from service workers can be deleted with the panel entry “Offline Website Data” and also in the Options with “Cookies and Site Data”. But, I have service workers disabled and I don’t use any plugins in FF. I’m not aware of any bugs preventing cache or history items from being deleted but there were some in the past. If anyone knows otherwise I would definitely like to hear about it.
I’m not using any webextensions for cache, cookies or history deletion. I use exceptions and the dev tools for cookies, 3rd-party cookies are not allowed and the remainder are wiped at the end of each browser session. Layout.css.visited_links is disabled. And I had “places.history.expiration.max_pages” set to 1500 but my history rarely gets that big, so I just reduced it to 100 to see if it still works, don’t know yet. I try to wipe the history once a week or more but that often ends up being wishful thinking.
To be honest, I don’t worry too much about history sniffing. Who is going to bother, other than maybe some search engines like Google and Bing which I seldom use. And of course maybe/probably social media sites, don’t any accounts myself. I occasionally do visit some Mozilla Twitter accounts, if they sniff history I don’t care about Mozilla but I doubt if they bother. And for the most part, the only Instagram account I visit is from the MMA fighter Derrick Lewis which is Always good for a laugh, maybe once a month or so “https://www.instagram.com/thebeastufc/?hl=en”. And then maybe some e-commerce sites like Amazon might be sniffing history. Otherwise who would bother? Because I block most 3rd-party content on websites ad companies trying to sniff history should be a non-issue.
I’m using a couple userscripts available at the ghacks-user.js wiki, conceal.history.length and conceal.window.name. Thank You Pants. A couple other userscripts I use are General URL Cleaner and Redirect Away. Privacy Possum for e-tags and tracking headers. And then does anyone Not use uBO. ;)
By the way, does everyone know how to see their History item count? Ctrl+Shift+H then type a colon into the search box in the top right corner. Click on the top item in the history list to highlight it, then Ctrl+Shift+A to “select all” of the list, number count will be under the list. Also works in the Bookmarks window, Ctrl+Shift+B.
This is a problem that’s only going to get worse as time goes on and browsers get more complex and track more of your data. It’s the price you pay for “convenience”.
This sort of thing is why I intentionally avoid the use of “modern” browsers. They’re simply too dangerous.
The question is which of these addons are blocked by privacy-focused addons?
Hello found this in the research paper page 10
Turning off Firefox’s layout.css.visited.links.enabled
configuration flag should eliminate visited link styling
altogether. Not so: disabling the flag fails to
block either our visited-link attacks or Paul Stone’s
older one; we reported this bug to Mozilla.
Hello found this on page 10 in the research paper.
Turning off Firefox’s (layout.css.visited.links.enabled) configuration flag should eliminate visited link styling altogether. Not so: disabling the flag fails to block either our visited-link attacks or Paul Stone’s older one; we reported this bug to Mozilla.
Happy to report this exploit doesn’t work in any of my browsers, even though I only clear my browser once a week.
Tested on Microsoft Edge and Vivaldi, didn’t even bother Tor.
Set this prefs.js setting to false:
about:config?filter=layout.css.visited_links_enabled
I think it solves this issue but am unsure.
I believe I came across this setting by diffing prefs.js before/after setting the FF extension “Random Agent Spoofer”. But like so many other excellent FF extensions, the original author of RAS abandoned it, thanks Quantum.
@Pants, @Klaas, @Anonymous
Thank you for the follow-up and clarification to this setting.
@Anonymous #2, Thank you for the RAS fork link.
PS: RAS is a difficult extension to use because so many poorly written sites breaks under it. I always snapshot my prefs.js before installing RAS.
In my experience (and I have almost everything enabled), some sites break, but not that many (or that severely). In most cases, these options break sites:
Disable local dom storage
Spoof If-None-Match (ETags)
Enable script injection
Disable Referer (or alternatively, network.http.sendRefererHeader set to 0)
…sometimes individually, sometimes combined, and I disable those options as the need arises.
This might sound overkill, but I also use an add-on called Sticky Notes, for a few sites that have issues with multiple options, so that I don’t have to memorize which ones I have to disable.
Someone has forked RAS: https://github.com/gitbugged/random-agent-spoofer
I found it here: https://wiki.hyperbola.info/doku.php?id=en:project:iceweasel-uxp_addons
> I think it solves this issue but am unsure.
No, it doesn’t. Look at the picture in the article. See the line that says “Firefox (no visited links)”? This is Firefox with that pref. As you can see, these side-channel, pixel-stealing attacks are still effective.
@Pants: so is there another setting we can adjust to mitigate this threat?
“I think it solves this issue but am unsure.”
It doesn’t : see my reply above to Borgy.
Regarding a user’s Firefox history only there’s an interesting extension :
‘History AutoDelete’ at https://addons.mozilla.org/en-US/firefox/addon/history-autodelete/
I use it mainly with sites like Google Maps which add to the user’s history each and every move given the move is immediately translated to the urlbar… resulting in dozens of histories for the same site.
Also interesting for the basic purpose : hiding what was meant for the user’s eyes only, free of recall.
This is one reason why, for many years now, I have used the Firefox “Clear All History” function.
It has become ‘second nature’ to do so – just as easy as closing an open tab. After every few sites I clear it.
Clear All History
Time range to clear: Everything
Browsing & Download History
Active Logins
Form & Search History
Cookies
Cache
Site Preferences
Offline Website Data
@Vrai, this extension might interest you as well as others:
‘Clear Cookies and Storage Button’ at https://addons.mozilla.org/en-US/firefox/addon/clear-storage-button/
All cleaning features are optional of course.
@Tom Hawack: indeed, it is a joy to be able to clear everything with 1 click instead of having to drill down into the Firefox options page.
“instead of having to drill down into the Firefox options page.”
Since ages in Firefox Shift + Ctrl + Del
Hit Enter and you are done.
@manouche, Firefox’s ‘Clear Recent History’ (Shift + Ctrl + Del) indeed yet it’s won’t clean as much as some dedicated extensions. The ‘Clear Cookies and Storage’ extension for instance will include indexedDB, localStorage, Plugin data, Form data, Service workers … far more complete.
Even a Sardine Head will clean Firefox History “… far more complete” for Those Who Truly Believe.
@manouche: thanks for confirming that Shift + Ctrl + Del is not worth it and that Clear Cookies and Storage Button is superior :-)
What else can your super-duper superior “Clear Cookies and Storage Button” doing than clearing browsing data using the Firefox ‘browsingData API’ … ? At least it claims so, but utterly fails!
Recommending a pseudo addon – with no other capabilities than showing a fake message and pretending it did clear some storage – is truly a believe in a herrings head.
Dit you ever checked ‘about:cache’? I bet you never dit.
@manouche: if you would have bothered to read through the comments you would not need to pollute this thread with your venom because the question has been answered. If the answers aren’t satisfactory to you, then the solution is simple: don’t use the add-on. But please refrain spewing your vitriol here, it’s not funny and getting to be a nuisance.
Would you please so kind, to provide a proof of your allegation the addon is doing what it pretends to do “superior”. Will say, removing data of this types
• browser cache
• cookies
• downloads
• history
• local storage
• plugin data
• saved form data
• saved passwords
or any combination of these types in just One Click.
But Please, explained in a few easy step by steps for anyone, even for the non tech savvy readers, to replicate in just a couple of minutes with a non-outdated Firefox version.
Let anyone else have his fair chance to judge by themself.
In return – but only in case you are able to show up with a decent and reasonable reply – I provide just 7 easy steps to proof my counter argument for any honest[!] and at least a little up to date reader to follow. Plus one extra step for the ones. who dont believe in the Great Magic of the Herring Head.
I am so friendly, it’s your turn now …
Thanks
Thank you. I was looking for something like this.
Ghacks-user.js suggests changing layout.css.visited_links_enabled in Fx about:config to false.
Comments ?
> Ghacks-user.js suggests changing layout.css.visited_links_enabled in Fx about:config to false.
It also says: “* [NOTE] This has NEVER been fully “resolved”…”
We have seen recent fixes due to regressions (eg stylo) and other bugzillas. And we’ve been talking about it since June – see https://github.com/ghacksuserjs/ghacks-user.js/issues/448 , including earthlng creating a PoC that worked regardless of timing mitigations such as RFP, and the visited links pref.
The bugzilla to watch for all this is https://bugzilla.mozilla.org/show_bug.cgi?id=1398414 which would apply some sort of same origin policy to history
@Pants: so what is your suggestion for now?
user_pref((“layout.css.visited_links_enabledâ€, false)
or
user_pref((“layout.css.visited_links_enabledâ€, true)
> what is your suggestion for now
As per the ghacks user.js (i.e false). By not disabling :visited you increase the attack surface (i.e the OLD leaks still apply from 2010). This “new” lot of history scraping is from new methods due to new APIs etc over the years (such as CSS3). BTW, the bugzilla filed by the researchers was https://bugzilla.mozilla.org/show_bug.cgi?id=1477773 which was resolved in FF63, but earthlng’s PoC still works (he won’t share it with me!), no idea about the researchers’ PoC(s).
see: https://github.com/ghacksuserjs/ghacks-user.js/issues/448#issuecomment-435754742 < Tom Ritter is one of the Mozilla Tor Uplift guys (among other things) – he's my go-to contact at Mozilla (and Arthur Edelstein is the one at Tor), I email em a bit (they're probably sick of me, but I do effect change and get a lot of inside scoop).
@Pants: many thanks. Does that also mean that the add-on “HTTPS Everywhere” is still worth having as part of the defence?
@Borgy
Quote from the paper (at page 10) :
“Turning off Firefox’s layout.css.visited_links_enabled configuration flag should eliminate visited link styling altogether [5,46]. Not so: disabling the flag fails to block either our visited-link attacks or Paul Stone’s older one; we reported this bug to Mozilla.”
Better leave it on false anyway.
Indeed, Pants’ Ghacks-user.js includes
// 0805: disable CSS querying page history – CSS history leak – PRIVACY
lockPref(“layout.css.visited_links_enabled”, false);
I’ve always kept this setting to false accordingly to the recommendation and the only disturbance is obvious : you’ll have to recall the link you’ve clicked as the font color remains unchanged, which is a good exercise for memory (ours)!
Concerning wide spread browsers’ history sniffing, but another brick in the user sniffing-tracking saga, endless.
user_pref((“layout.css.visited_links_enabledâ€, false), not lockPref, sorry …
Again, Tor Browser king of privacy! It’s the Qubes OS equivalent of browsers.
Demo – http://diracdeltas.github.io/sniffly
Results can be tainted with the help of a content blocker like uBO/uMatrix, be sure to block third-party, connections.
Hi, I’m one of the authors on the paper. This is NOT a demo of one of our attacks. It is entirely unrelated to the work discussed in this article.
Nobody said it’s demo of one of your attacks, bud, No need to get triggered. Prove your claims by posting the demo of your attacks and I don’t see any demos posted by you or your team, so put money where your mouth is.
@SniffSniff – Writing “Demo – ” underneath an article on a series of attacks would typically imply that the link is to a demo of said attacks. I hope you can understand why I’d want to clarify that, regardless of whether it was your intention to give that impression.
@Evangelical – No need to be so confrontational. We included working exploits with each of our submissions to the respective browser vendors. Most of these are still restricted from public view, but the CSS Paint API demo can be accessed via the Chromium bug tracker, since that one’s been patched: https://bugs.chromium.org/p/chromium/issues/detail?id=835589. A further optimized version of that code (taking it from 3,000 URLs/sec to 6,000 URLs/sec) is here: https://gist.github.com/spinda/555d350ed6a89815358f617a63aa7873. Happy to answer any further questions!
Implication is subjective, don’t generalise it. It implies that to YOU only, nobody else. Read the title of the blog post, it’s about Brower history sniffing, not about your paper, which just happens to be mentioned in the article as you published it.
Secondly you wrote and I quote “It is entirely unrelated to the work discussed in this article” which is wrong because it is related to Browser sniffing which is what I meant, you took it upon yourself to confront me first thinking I was misleading people which was a terrible assumption. Don’t jump to conclusions next time.
Lastly, It’s you who shouldn’t confront people like that without being polite about it, otherwise you will get confronted and you won’t like it. I don’t care what you published, I’m only interested whether it affects my browser or not and to let the fellow folks in here know where to test the demos. You posted papers to the vendors and all that, that hardly helps the people who want to test as those vendors keep it restricted. You didn’t publish working demos online where I can test it, so end of story, also you clarify with politeness not with CAPS and statements like “It is entirely unrelated to the work discussed in this article”.
I think we’ve both simply misread the tone of each others’ posts. Easy to do on the internet! For example, I used caps for emphasis only because I didn’t think this comment form would support italics. And by “entirely unrelated”, I meant independently developed, not off-topic. My intent was to clarify, certainly not to insult or belittle your work – which, without the context of your follow-up posts, I thought was simply something you had found online and mistook for the attacks covered in the article.
> Read the title of the blog post, it’s about Brower history sniffing, not about your paper, which just happens to be mentioned in the article as you published it.
I’m super happy to see a broader conversation going on history sniffing attacks in general – it needs to happen! I will point out, though, that the text of the article is entirely paraphrased from sections of our paper.
Hi, I didn’t post to be related to your attacks mentioned in the papper, this demo is to check whether your browser history in chrome/firefox can be leaked or not. Not sure why would you think this was related to one of your attacks. And no, it’s NOT entirely unrelated to the subject discussed here in this article.
Today I noticed high CPU usage of around 50-60% and the culprit was nothing but Chrome Cleanup Tool process. At first I got angry since it was started automatically ad without my consent after launching Google Chrome (v70). I wanted to end/terminate it immediately but I decided to let it finish its scan. It was a shock to me that Chrome Cleanup Tool (powered by ESET) found a malware (suspicious file) called mgrjz.sys in ‘system32\drivers’.
It was quite a shock because I have complete (well, I believed) control on my system including Comodo Internet Security v11 installed and this file (digitally signed by pillactechnology) is also considered malware by Comodo (https://www.virustotal.com/#/file/ff14621f2bbfee623dad816398aee2899ad7275933da7e7af7dd508754bb30b9/detection).
I scanned ‘drivers’ folder with Comodo Internet Security and it labeled ‘mgrjz.sys’ as malware and cleaned it (that had a Date modified of 29.06.2018).
What is surprising is that how this malware entered my system in the first place and why CIS didn’t found it before a manual scan, and how Chrome decided to do a security scan (all of a sudden). CIS and Chrome have been installed (and kept updated) on my Win 7 system since several years before 29.06.2018 and I use Chrome every day. So why it decided to do a scan today? I remember I used Chrome Cleanup Tool about 1-2 month ago after reading an article about this new? tool (just to test it not as a serious malware scanning tool), and it found my system clean.
Now not only I’m puzzled and surprised, I also appreciate what Google has done with Chrome. Though installed and updated, I didn’t like Chrome and used it rarely until 6-7 month ago when I completely switched to Chrome due to high memory usage of Firefox (even Quantum) and the fact that it was impossible to have 20-30 tabs open and it wouldn’t crash and even cause the whole system freeze).
@SniffSniff
Ok I looked further and this test site uses timing, so to that extent it may be considered similar to the attacks described in the paper.
@SniffSniff
This test site says it’s using HSTS to sniff history, this problem is not new and I’m not sure it’s related to the paper ?
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#Privacy_issues
https://www.ghacks.net/2015/10/16/how-to-prevent-hsts-tracking-in-firefox/
For some reason it thinks I have visited all checked sites.
@SniffSniff: https settings need to be disabled for the test to work.
Works fine without that.