3

I have a mobile app from which I'd like to allow voting on Things. I don't want to force all the users to have to sign up using email/Facebook/etc. just so that I can properly limit voting.

Is it really a bad idea to leave voting to be an "open" process where anyone can vote? I know theoretically that this allows improper voting techniques, etc. but on the other hand getting more votes really don't offer any kind of financial motivation.

--Edit--

Perhaps there are some ways to limit vote-faking? I know theoretically nothing is unbreakable, but maybe I can limit the amount of votes something can get in a minute/hour/day?

--Edit 2 --

Think of it as "views" on a video. It is a simple measure of popularity that requires no login. What are ways to limit view tampering, and when is it necessary?

you786
  • 171
  • 5
  • 2
    Which do you value more, More votes or correct votes? – daniel gratzer Sep 02 '13 at 07:55
  • 2
    as soon as you get even a single script kiddie that figures out how to automate voting then you'll get a flood of votes all coming from a single person – ratchet freak Sep 02 '13 at 07:56
  • @ratchetfreak I know. I'm wondering if leaving open that risk is fine, considering the lack of incentive to fake votes. Perhaps there are other ways to limit the effectiveness of such scripts. – you786 Sep 02 '13 at 08:05
  • not all spam is cause by any sort of incentive, I've seen people cheating to advance in a free game without any prices – ratchet freak Sep 02 '13 at 08:07
  • @jozefg I suppose in this scenario, it's more votes. If someone decides to send a million votes for one Thing, it has no effect on anybody else using the app. The votes are just there as a 'confirm this Thing actually exists in the real world' mechanism. – you786 Sep 02 '13 at 08:08
  • Yes - bad idea. Don't forget to add validation to stop negative numbers and decimals from coming through. – CodeART Sep 02 '13 at 08:29
  • Is this a mobile app as in an app on a mobile device that is installed, or is it just a web app? – awe Sep 02 '13 at 12:19
  • @awe I have both a mobile and web app. If necessary I could limit voting to the mobile app (obviously this means just hiding the url from web users, which can easily be found anyways). – you786 Sep 02 '13 at 13:30
  • 2
    just one vote per ip address. – john-jones Sep 03 '13 at 05:59

3 Answers3

3

Of course it's not always a bad idea. It's always a trade-off between effort expended on one thing and effort expended on another, and between effort and gain. You've obviously thought about this, and think that in your case the effort of programming checks isn't justified by the added value. That's fine.

A problem will arise when you go live with this solution under the assumption that ballot-stuffing isn't a problem and don't communicate this assumption to the users. Eventually, your app will be used by people who don't share that assumption and feel betrayed when the system behaves differently from how they assume an online vote should behave. This can be a terrible shock to people, and you will lose users about it. So the more appropriate perspective is: "Is programming anti-cheating checks more effort than adding language to the project which informs users of their absence?" The answer may still be "yes", but you can decide that better than we can.

Kilian Foth
  • 109,273
3

if you dont autheticate the user, you can not guarantee he/she will not vote a hundred times .. just for the fun of manipulation ... or other motives. Some people even write small voting scripts. It might "hammer" your vote-counter just for the fun of it.

You can save the IP-Adress for the votes and just dont let them vote for 10 Minutes BUT there are whole corporations/schools ... behind a single IP Adress. You end up blocking them as a whole.

What you could to is submit some encrypted id with the vote. Encryption in your app must create a unique id for your user you would have to verify in the vote script on your server.

One way to do this is a md5('someuniqueuseridstuff'+$yoursecretpassintheapp) and transmit the md5 with the plain userid ('someuniqueuseridstuff') so you can verify the uniqueid on the server. Its by far not unbreakable(use a looong $yoursecretpassintheapp) but defies some level of tempering.

Edit: do you have client local storage ? you could hand out ids and save them to client local storage ...

snitch182
  • 141
  • 4
3

If this is implemented only for a native mobile app, you could restrict retreive some sort of unique device ID, dependent on what's available in the platform API. If no such thing is available, you could genereate a GUID on first run after installed, and store it on the device.

awe
  • 282