In a system where I have reviews of products, to avoid fake reviews I have thought about doing the following:

  1. Limit one review for each account -> To bypass this measure, the user could create multiple accounts.
  2. Limit a browser fingerprint for each product. To bypass this measure, creating a new account will not work for the malicious user. But, then he could change the browser to get a new fingerprint.
  3. Limit an IP for each product's review. My question is about this step. If I limit an IP by each product, I know that companies or schools have the same static IP for a large audience, but the problem is not that. My problem is about the dynamic IPs. If a legitimate user receives a previously registered IP of the another user, then he can't create a new review. So, should I use only the first two steps? What are the real probabilities of two persons, members of this app, wanting to write a review about the same product, receiving the same IP? Is this just paranoid, or could it be a real scenario? Well, the malicious user could get a new IP easily, so this step is just really easy to bypass.
  4. I'm not interested in things like evercookie.
  5. Is there another way of tracking?
  • Combine all of them. Plus block it on per public IP bases, and block all the known IP's from VPN and Tor. This would be annoying enough to stop most of the people
    – Freedo
    Aug 21, 2015 at 5:00
  • @Freedom could you provide more information about what you are saying? Aug 21, 2015 at 14:33

3 Answers 3


Limiting by IP is too strict in my opinion:

  • As you said there is a problem with dynamic IP. But this alone could maybe solved if you enforce this limit only within a specific time frame because the IP does not change that often.
  • But corporations and institutions often use private IP addresses inside and have few internet gateways. This means all users there have the same outgoing IP.
  • And then you DS-Lite and similar access methods. Here the users get only a private IPv4 address and share the same public IPv4 address because there are not enough public IPv4 addresses for all. Usually they have a unique IPv6 address though. This kind of access affects probably most mobile networks, large parts of Asia but also some ISP in Europe or America.

I think the best way is too limit the reviews per account and then make account creation hard, i.e. use captchas etc. There is also research to detect bogus account so that you can close accounts later and remove the reviews, see for example Aiding the Detection of Fake Accounts in Large Scale Social Online Services from the recent USENIX conference.

Of course everything you do to limit abuse might make it more complex might deter some benign users from using your system. But if there is too much abuse your system is useless for them too. It is probably very hard to get the balance right and if you look at social networks, free web mailers etc they are constantly change their procedures to make it easy for benign users to use the system but hard for spammers to abuse it. Since spammers evolve their techniques too you must probably tune your system regularly. Or you might try to profit from the validations google etc do to their accounts and instead of doing all the account creation and validation by your own let the user sign in with their google or facebook accounts.

  • About dynamic ip, the malicious user could bypass this measure just by restart his router. This did not solve anything in practice, right? Thanks for the paper, but seems a bit over-complicated to implement that method at an early stage. about the captcha, sure, that will be implemented. Just to know, there is any way to find a list of public ips used by anonymox and similar tools/vpns? This could be blocked by default. Aug 21, 2015 at 14:50
  • 1
    @user2990084: for Tor look here Aug 21, 2015 at 15:04

Why not use two step authentication? Any user performing review should get an authorization code on his/her cell number. After providing that code on browser he/she could perform product review.

There should be limit on cell number - one user with specific cell number can review for once.

  • This is could be really, really expensive. Suppose that you are sending sms's for random numbers of fake accounts. You still are paying for the messages. Aug 21, 2015 at 15:42

Technical analysis of client identification mechanisms from Google details many browser and network level heuristics to fingerprint browsers/users:

1.1 HTTP cookies
1.2 Flash LSOs
1.3 Silverlight Isolated Storage
1.4 HTML5 client-side storage mechanisms
1.5 Cached objects
1.6 Cache metadata: ETag and Last-Modified
1.7 HTML5 AppCache
1.8 Flash resource cache
1.9 SDCH dictionaries
1.10 Other script-accessible storage mechanisms
1.11 Lower-level protocol identifiers

You can find an example implementation on these techniques and a few more at BrowserLeaks.

  • well, that information is purely theoretical, I am looking for resources with a realistic implementation and source code to learn how to make similar thing. Sep 21, 2015 at 9:49
  • I wouldn't say so. The techniques are collected from real implementations and I wouldn't call them 'pure theoretical'. In fact some of them are trivial to implement. Additionally, I don't know whether you have checked the link to BrowserLeaks, I've included. That has good amount of sample codes.
    – Dr. mattle
    Sep 27, 2015 at 22:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .