My links index is pretty new, but I've already got someone trying to pull a fast one on the ratings system.
I noticed that the ratings prvents immediate re-votes, but what's the cutoff? It would seem to be only a day or so per logged IP. Is there a way to increase that time, to like... a week or so? You can ask my why I know it's a problem of fraud, but I won't bother to expound on that right now.
Basically I want to know if anyone has had to deal with ratings fraud, and if so, what did you do to prevent it, or at least make it a lot more inconvenient for the perpetrator.

Thanks!


------------------
Greg Gaub
flux@snapbag.com
The TRANSFORMERS Links Index
http://flux.snapbag.com/...nks/pages/index.html

I think I might have found the right place...
in rate.cgi

(($time - $old_time) > 21600) and (@IP = ());

is the 21600 is minutes or seconds? I'm guessing seconds, because then it comes to 6 hours. I'd like to know for sure if that's the number I need to jack up, and if I'm right about it being in seconds before I go jacking the number up.

If anyone can help me with this, i'd be super grateful!

Thanks!

------------------
Greg Gaub
flux@snapbag.com
The TRANSFORMERS Links Index
http://flux.snapbag.com/...nks/pages/index.html

you got it right but it really does not work
because:

a person can log off the net then login again and most isp will give him a different ip# and he will be able vote again.
***some isp like aol offer dynamic ip which changes everytime you access a page.

also if you rebuild the pages it will delete all ip# in the log.

i think there are afew outside rating mode that will require each person to sign up before they can vote. ( id id not try any)
similar to cgiresources.com

well... that sucks.
so... pretty much the only thing it prevents is people from submitting their rating immediately after another. great. Now I'm going to have to play "bad cop" and strike down links which are obviously getting fraudulent ratings.

you tell me... a site which gets more votes than hits, and does NOT have a rating form on the actual site, where all the votes are 10... is that not an obvious fraud?

-Greg

------------------
Greg Gaub
flux@snapbag.com
The TRANSFORMERS Links Index
http://flux.snapbag.com/...nks/pages/index.html

i gave up on this rating, it does not work.
hey, if people want to cheat let them cheat.
they are basically wasting their time.
if you have ads on your page then you are making money not them

You have two choices: use cookies or require a valid email address. Review.cgi has the benefit of having the email part built in: the cookie is also not hard to implement.

again the e-mail thing is not valid. if they want to cheat they still can do it.
how many free web based services available on the net?
there is a way around cookies as well.

the bottom line:
if people want to cheat, they will
but the way i see it, they are cheating themselves because they gaining basically nothing other than listed on the top rated page

So,

was it the number to change?

It will be great if people is allowed only once a week or even once a month per IP!

IP blocking is NOT the ultimate answer in my opinion, since most dial-up services (excluding ISDN) give out dynamic IP addresses to customers when they dial-in to the modem pool.

But this is what I've done (which I have posted before in this forum)....

1) Add the following codes:



AFTER the following codes:



in the rate.cgi file (Note: There are two occurences of this code.)

2) Then add the following codes:



AFTER the following codes:



in the sub main routine in the rate.cgi file.

3) Then add the following array in your links.cfg file:



4) Then add the following variable in the links.cfg file:



5) Then create an empty file called rate.log, put it in your data directory and change the permission to 666 (rw-rw-rw-).

Now you will have to find a way to improve these codes to do the rating periods you want. One suggestion is change the @block_ips array to open the $db_rate_log and check for the IP address.

Good luck!

Regards,


Eliot Lee

Although I've more or less understood your mod creates a log, my question is: what do i do with it?

Quick suggestion.

Perhaps not entirely practical but certainly a possible solution... Why not create an extra field or even a seperate DB, that puts the ID of a site alongside an IP or cookie ID for a user.

When a rating is submitted then there's a quick check against Cookie ID, and/or IP and it declines or accepts on the basis of whether that user has already voted for that particular Link ID.

Hey, I know it wouldn't be perfect and may'be to make it work you'll want to ditch non-cookie users ratings but it'd help make their job a little harder..

To be honest in the case of one project I'm working on, it's the other people being misled by the ratings that would annoy the heck out of my others users and hence blow the whole system.

My two pence worth anyways

My Mod already stores the IP Address, ID of the site, and more!

Cookies are stored in client software, BTW.

Okay...so, your point is?

Regards,

Eliot Lee

I have 3 occurrances, do I insert after all 3?

if (open (HIT, "<$db_rates_path/$id")) {
my $input = <HIT>; chomp $input;
($votes, $old_rating) = split /\s/, $input;
chomp ($old_time = <HIT>);
chomp (@IP = <HIT>);
(($time - $old_time) > 21600) and (@IP = ());
foreach $ip (@IP) {
$ip eq $ENV{'REMOTE_ADDR'} and ($visited++ and last);
}
close HIT;

if (!$visited) {
push (@IP, $ENV{'REMOTE_ADDR'});
$votes = $votes + 1;
$rating = $rating + $old_rating;
open (HIT, ">$db_rates_path/$id") or &cgierr ("Can't open for output counter file. Reason: $!");
if ($db_use_flock) { flock (HIT, 2) or &cgierr ("Can't get file lock. Reason: $!"); }
local $" = "\n";
print HIT "$votes $rating\n$time\n@IP";
close HIT;
&site_html_rate_success;
}
else {
&site_html_rate_failure ("Sorry, you've already rated for this resource once recently.");
}
}
else {
open (HIT, ">$db_rates_path/$id") or &cgierr ("Can't increment counter file '$db_rates_path/$id'. Reason: $!");
print HIT "1 $rating\n$time\n$ENV{'REMOTE_ADDR'}";
close HIT;
&site_html_rate_success;


John Hesch

Yes....my rate.cgi only has two...where is your third?

Regards,

Eliot Lee

I posted all three in my message before and bolded them.

John

Ok, Thanks for the reply. I wasn't aware of what your MOD did EXACTLY, so no disrespect intended there. But my suggestion was to use the cookie capability to make it that little bit harder for people to screw around with ratings.

Granted that cookies are client side (I was aware of this) and granted very determined people can still screw with the system but at least it allows one more layer of defence that someone wishing to push their ratings up, needs to get around.

To clarify my point re: "the ratings system and my users". The site I'm working on currently relies on semi accurate ratings to produce a top 5 for each category that appears on the relevant page via SSI. If the ratings are being skewed by someone, then it misleads my users and reduces the effectiveness of that Top 5.

To say that the only people who lose out are the idiots engaged in this over-rating lark, is frankly wrong. My site loses out, the users lose out and I lose out.

So to recap.. I would love to make it as hard as possible for the idiots engaged in ratings fraud. That harder I make it for them, the better I make it for the genuine users and myself.

Perhaps some of you see that as overkill but personally I don't

As to how to do it...

Simple really.
- Setup a cookie that stores all the link ID's that the user has rated.
- No Cookies Capability/Cookies turned off = no rating allowed (may'be this is an admin option)
- If the user has already rated a link (ie: Link ID already exists in the cookie) then no further ratings accepted.

It's pretty simple to implement and yes I know the user could do any of the following:
- delete their browser cookie
- use a different browser

Yes, it would be possible to get round, but it's more inconvenience to the idiot trying to get around it. If you coupled this up with the IP check then not only would they have to reconnect to get a new IP but they'd also have to go through the rigmarol of clearing their cookie every time. Pretty soon that has to mean they get bored, fed up and move on.

Perhaps you don't agree but that's my two pence worth.

Excuse me...where the heck did I say that??? I do not appreciate people like you putting words in my mouth!

This shows both a lack of knowledge of dial-up services, TCP/IP, and also how cookies could be used in this type of situation.

I don't know where the heck you are getting the message that I am against fair rating systems...because I am not...I was only stating that simple IP blocking will also cut off legitimate voters who may be assigned a "blocked" IP address when they dial-in to access the Internet. I would suggest that you do some research about TCP/IP and dial-up services before rudely arguing points that you seem to have no knowledge about!

Regards,


Eliot Lee

ratings by cookies are just lame..

the only way to make sure one person rates one time.. is to use a username/password system..



Jerry Su
email@jerrysu.com
http://www.jerrysu.com/

Ahem.

1. I am responding to all postings placed re: this thread, NOT JUST YOURS!
2. You appear to be responding to comments made by other people on other threads (ie: you are taking your frustration out on me)
3. You have no right or need to call me ignorant.

My experience of dial up services, Internet, cookies and general web design comes from 20+ years or working with computers, modifying scripts and generally learning from doing.

I did not put words in your mouth and I have not at any point suggested that you were against blocking this kind of ratings fraud. I actually thought we were talking about the same thing, ie: actually suggesting ways to improve things.

I suggest a deep breath (a small apology wouldn't be out of order following your direct remarks) and then try re-reading the "constructive suggestions" I made in the first place.

Thank-you.



The impossible we can handle now
Miracles take a little longer

Subject: Re: Preventing Ratings Fraud??

Jerry,

I agree that currently the only way to ensure something close to an accurate rating is to use the user/password system. Unfortunately that involves a "cost" of lost reviews/ratings.

This is down to many of my site users not requiring or wanting a login or user name. They are also the exact type of people who will listen to and believe the hype about privacy, email lists being sold on, etc... regardless of my sites policy.

Because the opinions of those same people are important to me (and more importantly my site) it would be time well spent trying to find ways that make ratings fraud harder and the process of rating easier for the genuine users.

Now, can we please avoid this thread resorting back to misunderstanding, etc...

I am keen to work on this idea myself and would welcome any constructive ideas, input, collaboration even, on ways to do this.

----------

The impossible we can handle now
Miracles take a little longer

Hey Jerry! But then again if you create a user/pass they still can foil it. More than likely, It's comming from the webmaster or one of his/her friends. WARN the site that if they don't stop spoofing your rate service that you will delete their link and ban them completely from the database of links.

can somebody make a mod out of this!

Yeah, you'd think but then you end up with an even more cunning plan of spamming the system with Ratings for a COMPETING site to get it banned.

Which puts us right back at square one.

Fun ain't it



The impossible we can handle now
Miracles take a little longer

So can you tell me where i can find out how to install your mod? im very interested in it!

--Tyler

Quote:
$db_rate_log = $db_lib_path . "/rate.log"; # PATH to Rates log

Hello,

I know this posting is quite old but I think it has to be

$db_rates_log = $db_lib_path . "/rate.log"; # PATH to Rates log
_______^

Mike