Alvaro Lopez Ortega wrote:
It looks really interesting, but we do need a solution for this
right now. I've had to add two more rewrite rules today because we
are still being spammed by some morons. :-//
So, the only way I can think of is to write some sort of script in
order to access the trac.db file directly.. it'd be an awful work
around though.
the only other solution I can think of at this time (and I do hate this
particular technology) is a CAPCHA barrier. This will not defend
against the Third World cyber café attack but it will defend against
automated or handicapped person attack. But I have a sneaking suspicion
you don't have many blind users and as far as I know, I'm the only upper
limb impaired one.
there are many CAPCHA add-ons in different languages so you should be
able to find one you can use in TRAC.
*if* you wanted to go with the proof of work solution, we would need
someone who really knows browser applets in Java in order to do it at
all well.
in this context, every request would have a "number of bits required"
indicator hidden variables, headers or cookies. The Java applet
generating a token would run in background as the user does what ever it
is they're going to do. On submission, if the token is not complete,
then give the user a message about preparing anti-spam response, please
be patient, don't hit reload etc. etc.
all responses without an appropriately sized tokens should be
tossed/reject etc. otherwise, take them and use them.
A refinement of this is necessary when spammers start generating tokens.
In a beginning, spammers won't generate tokens because they don't know
about them, they have other, higher value targets they can go after for
lower-cost which means you can keep your stamp values low and minimize
the impact on legitimate users. Eventually however spammers will catch
on and at that point it would be necessary to implement a differential
rate system.
A differential rate system (a.k.a. reputation proxy) counts on the
ability of the recipient to differentiate between token generators.
Legitimate token generators get smaller demands for token sizes as they
develop a reputation for being "good people". Unknown token generators
are charged the standard amount until they to develop a reputation.
Known bad token generators are charged increasingly higher amounts.
this ability to differentiate between user classes allows you to charge
much higher rates to attackers/spammers and correspondingly lower rates
to legitimate users. In other words, you reward users that report bugs
frequently and penalize those who report bugs once in awhile. This
should have the net effect of increasing the number of bug reports. ;-)
it's important to practice a bit of subterfuge and make token generators
with a bad reputation think their data has been accepted when in
reality, it's been discarded or subject to human review.
Identification of token generators can be difficult. IP address is the
easiest but address/user associations are not as stable as they had
been. Client-side embedded identification can work as long as the
identifier can't be replicated among attackers and reused (i.e. parallel
double spending). this would take a bit of thinking before coming up
with a solution. But even simple IP address blocks would be of some use.
that's the technique in a nutshell. And I have three more to write up
and make slides for (not including the 20 odd slides with fundamentals
and application of proof of work systems). :-)
---eric
_______________________________________________
Cherokee mailing list
[email protected]
http://www.0x50.org/cgi-bin/mailman/listinfo/cherokee
