Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Privacy Security Your Rights Online

Un-killable 'Evercookie' Killed ... Sometimes 186

Trailrunner7 writes "The persistent method that security researcher Samy Kamkar introduced last week for storing tracking data on a user's machine, known as the 'Evercookie,' is even more worrisome when used on mobile devices, according to another researcher's analysis. The Evercookie is a simple method for forcing a user's machine to retain browser cookies by storing the data in a number of different locations. The method also has the ability to recreate deleted cookies if it finds that the user has removed them. Created by Kamkar as a demonstration of a way that sites could use to persistently track users even after they clear their browser cookies, the Evercookie has drawn the attention of a number of other researchers who have spent some time looking for methods to defeat it. A researcher in South Africa took a look at the way the the Evercookie works on both Safari on the desktop and on mobile devices, and found that it can be undone in some circumstances. However, he also found that the mobile version of Safari fares far worse in its handling of the Evercookie than the standard version does."
This discussion has been archived. No new comments can be posted.

Un-killable 'Evercookie' Killed ... Sometimes

Comments Filter:
  • Evercookie is clever (Score:4, Informative)

    by Nichotin ( 794369 ) on Tuesday October 19, 2010 @06:30PM (#33954232)
    For forum administrators, it is a very clever way to keep many ban evaders out. While it is not un-killable, it is pretty much a pain in the ass to get rid of, since it will get back if you miss a single one and visit the site again. Read the list of the places it stores its cookies, and be amazed how many there actually are. So, 1) ban user, 2) place cookie, 3) user signs up again, 4) your site detects the evercookie + new registration, 5) verify and ban again (unless the user suddenly becomes a good user, of course).
  • by al0ha ( 1262684 ) on Tuesday October 19, 2010 @06:35PM (#33954300) Journal
    A combination of FlashBlock and perhaps RequestPolicy, combined with caching set to 0 and a block on the ever cookie creator domain results in no ever cookies being successfully set on FF 3.6.10 on RHEL 5.4 - I'd venture to guess it will be the same for other OS running FF at least.

    If I don't block the domain cookie creation then just a standard cookie is created.
  • Re:Solution: (Score:3, Informative)

    by Anonymous Coward on Tuesday October 19, 2010 @07:45PM (#33955020)

    Don't accept cookies.

    No, not a solution. RTFA. It doesn't matter whether you accept cookies or not. The only two methods of protection are (a) use Safari in private browsing mode, and quit and restart the browser between each and every site; or (b) block absolutely all javascript everywhere without any exception ever. Neither of these is really satisfactory.

    Plus, these evercookies transfer from one browser to another because they get stored as LSOs.

  • by Jah-Wren Ryel ( 80510 ) on Tuesday October 19, 2010 @10:20PM (#33956222)

    Make the folder ~/.macromedia read only. Works with Linux, but not in Windows.

    I just tried it under linux.
    When I made the empty ~/.macromedia directory read-only, the flash plugin consistently crashed.
    So I made sure that Flash_Player sub-folder was created by the plugin first, deleted any cookie files and then did a recursive chmod -R a-w ~/.macromedia and it seems to work fine now.

All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin

Working...