Fwd: URGENT: Changing spam reduction strategy in tiki.org (new topic for today's TRM)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

Fwd: URGENT: Changing spam reduction strategy in tiki.org (new topic for today's TRM)

Xavier de Pedro (Tiki)

Oups, sorry, forgot to send also to the tikiwiki-users list.

Help back sharing your wisdom regarding the registration process at tiki.org that you experienced!


-------- Forwarded Message --------
Subject: URGENT: Changing spam reduction strategy in tiki.org (new topic for today's TRM)
Date: Thu, 20 Oct 2016 11:25:06 +0200
From: Xavier de Pedro [hidden email]
To: developers, Tikiwiki [hidden email], Tiki Admin Group [hidden email]

Hi all:

I was on irc while I found that there were a few requests for issues in
the way we have setup our sites (mainly tiki.org site, due to intertiki):

(1) registration in t.o with "Registration page key" but custom links
without it
We seemed to have setup the randomstring keyword needed ("Registration
page key") in the url for the registration screen to show up in
https://tiki.org, but this was blocking users from registering since
there was a hand made link to "Register" in the tiki homepage that
didn't have that keyword string manually setup in that hand-made link.

Conclusion: users that clicked at the link from the Homepage couldn't
register. And the link to "register" frmo the login module didn't work
either for me the first time I tried but only after I disabled the
feature "Registration page key" and re-enabled it again (caching issue?
was that recently setup in tiki.org??? )

Anybody aware of other places were we did setup custom links to
"Register" or tiki-register.php?

(2) new user admin validation in tiki.org (intertiki) by a single person

Regardless of the many thanks we need to give to the person that has
been taking care of validating new user requests in tiki.org, we cannot
rely in this custom hand-made single-man procedure, since it means a
bottleneck and too much pressure and responsability on a single person
for such an important entry point of new users, reviewers and developers
to the Tiki community.

I did a quick review, and there were plenty of legitimate registration
requests to tiki.org (like the ones reminded on irc and through personal
emails days ago to some admins), and dozens of others in the last weeks.
Even found some legitimate requests from several months ago (4 months
ago, 8 months ago, ...) among dozens of spammer registration attemps. So
the man-made work was woprking pretty well, but indeed not well enough.
And it's not a single-man responmsibility. Therefore, I propose to
change this situation to a more automated process of allowing users to
register first, and only when proven that they spam, then we can remove
+ ban ip, etc.

For instance, validation of new user requests can NOT be done in bulk in
the user admin UI (not even easily reviewing theuir user tracker records
with a single click from there), but removing and banning ip's can be
done indeed in bulk from several places (user admin UI, action log UI, etc).

I will add this to the roundtable discussion of this month (today), at
13h UTC (according to the votes).


By the way, not many people indicated whether they could attend or not
(afaik, only jyhem and me, who can, and jonny, who can't make it).
I wish we coudl have enough wisdom/brains today in the TRM so that we
can decide something after discussing pros/cons regarding how to
urgently improve this strategy to keep spammers away but leave
legitimate user requests to (please) go in and ask, help, contribute, etc.



Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
TikiWiki-users mailing list
[hidden email]