5

What is the best way to implement a "memory" or persistence for an anonymous vote? The other day I was browsing some site (unfortunately I forgot the URL), and I could quickly "thumbs up" or "thumbs down" an item. So I voted on several items. I then closed all my browser instances, deleted all the browser history and files. I went back to the site to vote on some of the same items but it "knew" that I had already voted. So I am wondering what's the best way to accomplish this

I have read about evercookies, but somehow they don't seem like a nice way to treat your users. I don’t want to go that way. Or are evercookies the only way to accomplish this?

If evercookies were not the mechanism behind this then the only way I can think of is to remember the client's IP + User Agent + something else. But what is "something else"?

Any thoughts?

Regards, Archil

ticallian
  • 1,631
  • 7
  • 24
  • 34
Archil Kublashvili
  • 696
  • 1
  • 8
  • 20
  • I am asking a question because obviously I have exhausted the research and someone has voted this down. In that case, please show me good pointers that talk about this. In fact, I dare you. I find bits and pieces here and there but not a single article explaining this completely. – Archil Kublashvili Jul 29 '11 at 05:33

2 Answers2

2

I have got your question and there are many methods to identify the user clicks or visit.

Cookies

There are various cookies you can store in users machine like

  • SuperCookies
  • Flash Cookies
  • Silverlight Cookies
  • Zombie Cookies
  • First party cookies
  • Third party cookies

Zombie cookies are similar to Flash Cookies. If you don't want to use all these, you can simply use SuperCookies. It's usage is simpler and you can find it in github. But the problem is most of the users will disable the cookies. So you can even use the below methods which gives the hash key which we will be generated depending on broswer, fonts etc.

  • webGL fingerprinting
  • canvas fingerprinting
  • audio fingerprinting

Panopticlick says that 1 of 84 will have similar canvas hash and 1 of 983 will have similar webGL.

You can have a look at the site user tracker. This type of websites also adopts some of the methods to identify the users like

  • getting client's IP
  • location
  • browser fingerprinting

we can get the client's IP by using the webRTC.

We also have websites which gives free api to get location like ipgeolocation. You can match with webGL, canvas hash keys with your location.

And finally browser fingerprinting which helps most of the companies and websites to identify the users.

2

Sites may use a combination of the following to try and identify flooding or abuse of a form such as an online poll. No method is completely infallible; in fact, most are trivial to fool.

Identifying the same person:

  • Setting a cookie (such as a session cookie)
  • Comparing the IP address
  • A hueristic approach having a cookie, and comparing part of the IP address (a /24 subnet) and/or user-agent as a backup when there's no cookie.

Preventing other types of abuse:

  • Flood control: don't allow more than a certain number of votes per minute from a certain IP subset, or from everyone.
  • Spam detection: try to detect bots by signature (eg malformed user-agent or accepts header, etc)

Making the user jump through hoops:

  • CAPTCHA/robot detection
  • Making the user confirm their vote by email
  • Making the user register, provide a unique email address, confirm the email address

For every measure there's an equal and opposite counter-measure. For example, an abuser might ignore cookies, vary his user-agent or use an anonymiser service that varies his IP address for every request. He might sign up using multiple accounts with throw-away email addresses, and there are even ways to try and defeat CAPTCHA (eg. replay the CAPTCHA for users on another site).

Note that to someone who is determined to disrupt, an evercookie doesn't do much more for you than a cookie. They wouldn't affect a bot, for example.

I personally do not like to use the barriers that make users jump through hoops. Hopefully I've demonstrated that even if you require registration you are not guarding against abusers all that much more than you would with a good flood control algorithm, since it's trivial to get multiple throwaway email addresses.

thomasrutter
  • 114,488
  • 30
  • 148
  • 167
  • 1
    Thank you for your response. This is exactly what I was looking for. I apologize if I was not specific enough in my question. I wanted to know if there was a mathemitacilally certain solution. You just confirmed that there is none. This coincides with how I was looking at things. No matter how hard one tried to protect the system, there will still be ways to break it. In my case, I don't want to go super crazy with captchas and emails, and what not as that will turn off the users from my site for sure. – Archil Kublashvili Jul 29 '11 at 09:57
  • On the other hand, I don't want to be too lose either. Basically, I don't want some one write a bot that votes, then hits F5 and votes again. That would be another extreme. So what I plan for now is to use some combination of cookies, IP + UserAgent and limit to some number of votes in a given time interval from a given combination of IP + user agent. – Archil Kublashvili Jul 29 '11 at 09:59