Re: My Gnutella spam reduction idea revised

"just_courtney_girl" <[email protected]>
Newsgroups gmane.network.gnutella.devel
Message-ID <[email protected]>
I'm writing this with all due respect, and
yet, I feel like venting just a tad.

Should any of us to be forced to filter with
our eyes and be told, "Uh, that's just the
way it is?"  Getting 50-200 spam results and
1-2 (if any) requested items tells me that
something is broken.  Protecting a dying
man's ego will not help his health any.

This is why I'm currently not a Gnutella user.
Please burden users with the need of coming up
with kludges on their own to work around what
seems to be getting less than fair attention.
Some bring up ideas that may help alleviate
this serious problem in at least a small way,
and they get excuses and get told to deal
with it.  If it was working as intended, we
wouldn't need to have to do anything else.  We
all know a way to take care of this sort of
thing, but we don't need people behind bars
for deleting spammers.

One other thing, this requires virtually no
more work than is already done (maybe just a
few more lines of code), and does not burden
the network any moreso.  However, other
implementations that I just skimmed over
require multiple searches and garbage strings.
That is too expensive of a price to pay.  We
don't need a cure that is at least as bad as
the disease.  It is like the sinus product
commercials and their long list of side-
effects, including death.  I think I'd rather
have the allergies.

I will admit that I don't know any modern
programming languages.  I used to write for
real mode using assembly and quickbasic.  So
my only asset to this group is being a
solution provider.  Since I am not caught up
in a particular culture, I believe I can see
things that others cannot see and find
patterns where most folks overlook.  I don't
claim to have all the answers, or even any
good ones.  But I am willing to share what
I do know and what seems to be brainstorms.

Yes, I do know about spammers of all sorts
becoming more sophisticated.  They are like
the smugglers, illegal aliens, and drug
traffickers of the digital world.  As the
law enforcement becomes better, so do the
crooks.  It is generally a matter of cat and
mouse.  However, police officers do not give
up and just sit back and let drug dealers
peddle their wares to children.  I know about
the problem with the Bayesian spam algorythm.
What spammers are doing know is just flooding
the system with random garbage to reprogram
the intelligent filters into letting the junk
make it to the inbox.  If they can blow one
piece of spam past our filters, then they
will pat themselves on the back.

No, I cannot say that this algorythm will
guarantee that what it blocks is spam.  But
what is wrong with just placing it in the
clients with an option toggle?  What is done
is this:

1.  User types a search string as usual.

2.  The client shortens the search string
and searches with the shorter one.

3.  The network responds.

4.  The client compares the returned files
with the original search criteria and loses
the results that don't match.

5.  The user is saved from having to look
through a bunch of unrelated s**t in order
to find the few things that might be of use
to them.  Plus, they may be less likely to
modify the string and search again.

The above does not have to be incorporated
in any broader way such as sharing the info
with other nodes.  If this filter is not
reliable enough for modifying how the network
works, it may be reliable enough for end
users who choose to use this.  I admit that
it is not comprehensive, nor was it intended
as such.  It is really just an adjunct to
other measures.  It is like the bulk folder
in mailers.  They fail every once in a while
(with slightly more false negatives than
false positives), but they certainly help in
sorting and getting to the content you want
to see first.

Other types of filters can be added as well.
Like why not some file type intelligence?  I
am sure that some file types have minimum
possible sizes.  An .EXE/.DLL/.OCX under
so many paragraphs in size is bound to be
corrupt or some other format (like text).
Or a .MP3 over a certain size (300-400 MB)
may also be invalid.  So why not ignore
files where the sizes fall outside of the
limits of whatever format or standard?

Adding to filtering out sizes that contradict
a given format, there is the idea of downloading
just a file header and determining if the
header fits the content (ie., if certain "magic"
numbers/letters appear, if the file size of an
.EXE is at least the size stored inside the
file - longer should not count against it due
to overlays and stored data).

There are some annoyances that can never be
solved such as misnamed files.  There are
workarounds for those such as file info
databases which give CRCs and URN codes.
That is not to say that they cannot be
compromised.

Now, what I would like to know is why isn't
WinMX as impacted as Gnutella-based
programs?  Why don't I see the dynamic spam
bots to the extent that I do in Gnutella?
Is this a platform popularity issue, or
is the OpenNap or whatever protocol more
resistant to this problem?

If I'm missing anything, please share with
me.  I admit I'm a little ignorant in the
inner workings of Gnutella, so if I say
something that sounds a little off the wall,
hey, I don't mean anything by it.

                         Courtney

--- In [email protected], Elias Athanasopoulos <elathan@...> wrote:
>
> Hello!
> 
> just_courtney_girl wrote:
> > I just rejoned under a new address.  In a post
> > sometime back, I came up with a spam reduction
> > idea.  I had an idea for eliminating junk hits.
> > The problem is the On-The_Fly spam generators
> > that take the Gnutella search string and
> > create files with the search strings in the
> > name.
> [snipped]
> > Now lets say I searched for voic trainin:
> > 
> > voic_trainin_install.exe
> > voic trainin porn video.avi
> > voic trainin xxx.mpg
> > voice training - control breath and tone.mp3
> > [crack] voic trainin.zip
> > voic trainin sales affiliate program.doc
> > xxx voic trainin.mpeg
> > 
> > Now, do you tell which is the intended result
> > and which is the spam?
> 
> You are just forcing the spammers to become more sophisticated, and, 
> IMHO, it takes no more than a few lines of code for a spammer to defeat 
> your spam defense algorithm. Simply, the spammer just passively modifies 
> QueryHits, which has even better effect, from the spammer's view point: 
> (a) you can not say in any similar way to your algorithm that the Hits 
> are spam, since they are produced from a legitimate peer (b) the spammer 
> does not need to care if Hits from legitimate peers travel faster than 
> her own Hits to the original querier, since she just altered the 
> original Hits with her own spam IPs.
> 
> I am against in using naive algos in order to defeat trivial spammers, 
> since you are just forcing them to become even more clever. Today the 
> majority of Gnutella users can filter on their own spam results, because 
> spam is easily spotted using the human eye. Tomorrow, if spammers employ 
> techniques like the ones I mentioned above, the spam will become much 
> much more serious issue...
> 
> Regards,
> -- 
> Elias Athanasopoulos
> Distributed Computing Systems (DCS)
> Institute of Computer Science (ICS/FORTH)
> Heraklion, Crete
> 
> A bug can become a feature by documenting it.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.