Browser history sniffing is still a thing - gHacks Tech News

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.

browsing history attacks

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.

Summary
Browser history sniffing is still a thing
Article Name
Browser history sniffing is still a thing
Description
A team of researchers revealed four new, and working, browsing history sniffing attacks recently to the public in a new research paper.
Author
Publisher
Ghacks Technology News
Logo
Advertisement

We need your help

Advertising revenue is falling fast across the Internet, and independently-run sites like Ghacks are hit hardest by it. The advertising model in its current form is coming to an end, and we have to find other ways to continue operating this site.

We are committed to keeping our content free and independent, which means no paywalls, no sponsored posts, no annoying ad formats or subscription fees.

If you like our content, and would like to help, please consider making a contribution:


Previous Post: «
Next Post: »

Comments

  1. SniffSniff said on November 4, 2018 at 8:11 am
    Reply

    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.

    1. Klaas Vaak said on November 4, 2018 at 4:04 pm
      Reply

      @SniffSniff: https settings need to be disabled for the test to work.

      1. SniffSniff said on November 4, 2018 at 7:12 pm
        Reply

        Works fine without that.

    2. user17843 said on November 4, 2018 at 4:37 pm
      Reply

      For some reason it thinks I have visited all checked sites.

    3. Anonymous said on November 4, 2018 at 5:20 pm
      Reply

      @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/

    4. Anonymous said on November 4, 2018 at 5:48 pm
      Reply

      @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.

    5. MeH said on November 4, 2018 at 7:27 pm
      Reply

      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).

    6. Michael Smith said on November 5, 2018 at 6:24 pm
      Reply

      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.

      1. SniffSniff said on November 6, 2018 at 5:30 am
        Reply

        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.

      2. Evangelical said on November 6, 2018 at 5:40 am
        Reply

        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.

      3. Michael said on November 6, 2018 at 7:51 am
        Reply

        @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!

      4. Sniff said on November 6, 2018 at 6:46 pm
        Reply

        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”.

      5. Michael said on November 7, 2018 at 1:35 am
        Reply

        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.

  2. Kazakhstani said on November 4, 2018 at 9:03 am
    Reply

    Again, Tor Browser king of privacy! It’s the Qubes OS equivalent of browsers.

  3. Borgy said on November 4, 2018 at 11:47 am
    Reply

    Ghacks-user.js suggests changing layout.css.visited_links_enabled in Fx about:config to false.
    Comments ?

    1. Tom Hawack said on November 4, 2018 at 12:36 pm
      Reply

      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.

      1. Tom Hawack said on November 4, 2018 at 12:38 pm
        Reply

        user_pref((“layout.css.visited_links_enabled”, false), not lockPref, sorry …

    2. Anonymous said on November 4, 2018 at 5:26 pm
      Reply

      @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.

    3. Pants said on November 4, 2018 at 8:06 pm
      Reply

      > 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

      1. Klaas Vaak said on November 5, 2018 at 6:59 am
        Reply

        @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)

      2. Pants said on November 5, 2018 at 8:26 am
        Reply

        > 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).

      3. Klaas Vaak said on November 5, 2018 at 11:56 am
        Reply

        @Pants: many thanks. Does that also mean that the add-on “HTTPS Everywhere” is still worth having as part of the defence?

  4. Vrai said on November 4, 2018 at 2:32 pm
    Reply

    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

    1. Tom Hawack said on November 4, 2018 at 2:48 pm
      Reply

      @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.

      1. Krauther said on November 4, 2018 at 3:27 pm
        Reply

        Thank you. I was looking for something like this.

      2. Klaas Vaak said on November 4, 2018 at 4:02 pm
        Reply

        @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.

      3. manouche said on November 4, 2018 at 9:28 pm
        Reply

        “instead of having to drill down into the Firefox options page.”

        Since ages in Firefox Shift + Ctrl + Del
        Hit Enter and you are done.

      4. Tom Hawack said on November 4, 2018 at 10:07 pm
        Reply

        @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.

      5. manouche said on November 5, 2018 at 7:21 am
        Reply

        Even a Sardine Head will clean Firefox History “… far more complete” for Those Who Truly Believe.

      6. Klaas Vaak said on November 5, 2018 at 11:04 am
        Reply

        @manouche: thanks for confirming that Shift + Ctrl + Del is not worth it and that Clear Cookies and Storage Button is superior :-)

      7. manouche said on November 6, 2018 at 12:10 pm
        Reply

        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.

      8. Klaas Vaak said on November 6, 2018 at 12:33 pm
        Reply

        @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.

      9. manouche said on November 6, 2018 at 8:02 pm
        Reply

        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

  5. Tom Hawack said on November 4, 2018 at 3:28 pm
    Reply

    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.

  6. Steve#99 said on November 4, 2018 at 4:06 pm
    Reply

    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.

    1. Anonymous said on November 4, 2018 at 5:28 pm
      Reply

      “I think it solves this issue but am unsure.”

      It doesn’t : see my reply above to Borgy.

    2. Pants said on November 4, 2018 at 8:00 pm
      Reply

      > 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.

      1. Klaas Vaak said on November 5, 2018 at 7:01 am
        Reply

        @Pants: so is there another setting we can adjust to mitigate this threat?

    3. Anonymous said on November 4, 2018 at 10:39 pm
      Reply
    4. Steve#99 said on November 6, 2018 at 3:21 pm
      Reply

      @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.

      1. Anonymous said on November 6, 2018 at 8:30 pm
        Reply

        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.

  7. Emanon said on November 4, 2018 at 5:22 pm
    Reply

    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.

  8. Anonymous said on November 5, 2018 at 1:25 am
    Reply

    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.

  9. Rufus said on November 5, 2018 at 1:34 am
    Reply

    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.

  10. Jeff said on November 5, 2018 at 3:57 pm
    Reply

    The question is which of these addons are blocked by privacy-focused addons?

  11. John Fenderson said on November 5, 2018 at 8:45 pm
    Reply

    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.

  12. Richard Allen said on November 5, 2018 at 9:15 pm
    Reply

    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.

  13. John said on November 7, 2018 at 5:59 am
    Reply

    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.

    1. manouche said on November 7, 2018 at 10:19 am
      Reply

      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

  14. Anonymous said on November 9, 2018 at 4:41 am
    Reply

    there’s a mistake in this article.
    it’s 3,000 URLs per second, not 6,000

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

Please note that your comment may not appear immediately after you post it.