Gnutella Forums - Defending against spam

Gnutella Forums (https://www.gnutellaforums.com/)

- Development Open Discussion (https://www.gnutellaforums.com/development-open-discussion/)

- - Defending against spam (https://www.gnutellaforums.com/development-open-discussion/69719-defending-against-spam.html)

Quote:

Originally Posted by arne_bab (Post 266569)

But it also wouldn't accomplish that much, because spammers partly use files with bogus sha1 keys.

I just confirmed that. Those tricky people! :(

Quote:

Originally Posted by arne_bab (Post 266569)

With dynamic blocking: How can you determine, that the one hit wasn't an actual hit?

How about a global (centralised or not) data-base? A data base with the IP of the spammers?
I was thinking in a digg style algorithm, in which the "the front page" ip's would be blocked. If an ip doesn't get dugged constantly with time it would get buried (not blocked).
This would prevent that some people block some uploaders because that people would be numerical small (i hope so) compared with the real users that would dugg the real spammers!

I know that the digg algorithm has some problems... but this is just a suggestion, a gnutella Manifest0 anti-spammers! :D

Cheers

That might die quite quickly.

There are more than 1 million live clients at any time, so you'd get more diggs than a normal webserver can handle...

At the moment we have one person who collects fakes and spammers and passes them on to the programmers.

But a lasting solution to Spam would be great nontheless...

If you want to get some infos on the current discussions on spam, you can have a look at the gdf mailing list:

the_gdf : The Gnutella Developer Forum (GDF)

Quote:

Originally Posted by arne_bab (Post 266653)

That might die quite quickly.

There are more than 1 million live clients at any time, so you'd get more diggs than a normal webserver can handle...

Digg claims that has 1 million users (ok... some people has 4 or 5 accounts. Not me :) ),
but a story can reach the front page with 300 diggs or even less. This means that the real spammers ip only need to have more diggs than the real uploaders that are dugged. There's no need to everyone dugged someone. The people will digg if they are getting spam.

Well i think that only with a collaborative thing we can beat the spam.

Quote:

Originally Posted by arne_bab (Post 266653)

At the moment we have one person who collects fakes and spammers and passes them on to the programmers.

How does this works? The ip's are getting blocked with no expiration time?
How do i report? If someone has a computer virus will we block his ip despite e has good files?

Quote:

Originally Posted by arne_bab (Post 266653)

If you want to get some infos on the current discussions on spam, you can have a look at the gdf mailing list:

the_gdf : The Gnutella Developer Forum (GDF)

I'll check it. Thanks.

Maybe this lasts posts may be moved to somewhere, because they aren't a "real" suggestion.

Cheers

Something which has been in discussion from time to time but which lacked a developer with time to implement it, is avaible via Credence (which sadly was a university project and died when the students thesis was done):

Credence: Thwarting P2P Pollution

Credence does decentral spam marking and detection, and if it would be implemented in Phex, it could give Phex a real boost.

But I assume that it will be quite much work...

I was looking at credence, and it has four big problems, imho:
1- It's dead (or at least appears to be)
2- The users have to finish the download in order to vote. This doesn't make much sense since it's possible to preview the files.
3- It relies on sha1 to vote. The sha1sum of a downloaded file isn't the same sha1sum of the same file ready to download, because of the bogus SHA1sum.
4- A bad named file would give the users that voted thumbs down a worst "karma", and therefore getting more spam.

In the case of bad-named files, the user can just vote the name down /in the last version).

In the case of a spoofed sha1-sum and a wrongly delivered file, verification of the file should show that it is a bogus-file (hashing after the download finished), but that's not yet integrated into Phex (but I assume it will be with TTH).

If it was changed to rely on tigertree hash (TTH, which Gregor is implementing right now into Phex) instead of only sha1, the chunks could directly be verified, and the first few chunks would show the file to be wrong.

Finishing the file before voting is necessary, at least for positive votes, because else the users could vote up a file which is only garbled at the end.

And for negative votes it's also necessary because else the program can't verify, if the file really has the sha1-sum.

For TigerTree Hashes that could also vanish.

And Credence is a way of verifying files decentrally, not just the program (which is dead, because LimeWire didn't carry it over). And that way could be carried over, but Phex would need an additional programmer for this (who would take it as main goal to implement Credence in Phex, and maybe improving it).

One more problem was, that it relied on centrally distributed key-files, but that could be removed (it was only a draft of a real system, and they planned to switch to a cryptographic generation inside the clients, but didn't carry on to do so).