I see all the work on comment spam, how about referrer spam? The wonderful Referrer Karma tool for WordPress practically eliminates the problem, but we on Textpattern have nothing like this. There are only so many variations one can manually add to an htaccess file (mine is 230 lines so far) before its a losing battle of bandwidth. Can the spam plugin process work for these as well? It looked very tied to comment spam.
There is a user-centered and a technical answer to that question:
The user-cenered answer is: log statistics are not a vital and central feature of Textpattern CMS, whereas comments often are; Comments are usually publicly viewable and thus comment spam requires often immediate effort on the part of the publisher to remove those comments. Spam referrers on the other hand are only shown on the private log page viewable by the Site Publisher, so the only action one must take is to ignore those referers.
Also be aware that while it was always possible and very easy to write a plugin against referrer spam, it was more difficult to write anti-spam plugins and their scope would have been limited. That’s why we worked hard for 4.0.3 and improved the infrastructure for writing anti-spam plugins that tie in well with the site and require little effort to develop and use.
The techincal answer(s): Leaving a comment is an interactive process which is controled-by and specific-to the application that is used, i.e. Textpattern. So when comment spamming became a reality, it was obvious to expect the application to be able to do something about it.
However referrers are part of the standardized HTTP-Protocol, we can’t just go in there and change that to force a reload, ask a question, enter a captcha or do other user- or application-centric things. With referrers it’s a simple take-it-or-leave-it situation, it’s residue of normal web-traffic. They are provided as is, and you can only choose to ignore/block/filter them. That limits the possibilities a lot.
The plugin you mention is in fact just that, a black- and white-list. So the effort shifts from maintaining webserver-configuration files to maintaining applications specifis files. I guess the harder part of it, is deciding on the interface (what to allow the user to configure and what not). Anyway, it would be easy to develop such a plugin for Textpattern (and it always was), but apparently there is just not as much interest in it.
Also, because referrers are part of the HTTP-Protocol referrer spam can — and on some hosts already is — being taken care of at other levels, for example using mod_security
at the webserver-level, or at the analysis-level in log-statistic-software. And if you follow the discussions around those blacklisting/rule-approaches, you’ll see that while it’s possible to catch a lot of the referrer spam, it’s almost inevitable to also generate a considerable rate of false positives, which is when real harm might be done (in comparison to ‘unwanted’ referrers in private logs, you could be affecting users).
So, if there is sufficient interest in something like this, I am sure a plugin will eventually be written. Textpattern CMS certainly makes it easy to do so.
]]>Besides Rights&Permissions, is there any tools or features you thought or wandered about, but did not start coding because you had no time to think them through, imagine how the admin or layout would be, etc.? To see if we can expand the Rights&Permissions experiment unto other areas.
The Rights and Permissions Workgroup, for those who are not following the forum closely, is a self-organizing group of Textpattern enthusiasts that has got together to work out the challenge of giving Textpattern CMS a better permission system. It was formed in response to the Assignment: section permission design. We have posted several such assignments for users/enthusiasts and welcome input on those issues. You can find more by searching for assignment in the ‘Feature request’ forum.
How people organize their contributions is entirely up to them. Work-groups can incur quite a bit of overhead with respect to managing communications and then aggregating all discussions into some form of ‘result’ that we can work with. In some cases it may well be worth the effort, in other cases it might be much easier to spend the available time on the problem. Usually smaller increments are better for the people working on them, and for us to be able to incoorporate those ideas. The more complex the topics and results, the costlier it is for everyone involved, and the more people may be disappointed when we can’t dedicate the necessary time for it, because of other priorities.
I’ve skimmed some posts in the thread, and I have to appreciate the amount of time people are willing to spend in drafting things out and debating ideas. It’s great to see this interest combined with a huge dose of diligence.
Independent of what may finally come off from this effort, I have to say: “Thank you very much to the people involved!”. If I am reading the first post right it’s Matthew, Alexandra, Jeremie, Saccade and Neutrino. I hope I didn’t forget anyone!
The tidbits I looked at looked fairly complex — maybe even too much for Textpattern — but as I understand it, the whole terrain is first being explored, to be able to make better informed decisions and to finally settle on something which fits with the overall aims and goals of textpattern. I am looking forward to the results!
]]>As you can see, I’m not saying “it will be included into core” when ready, but “released to the public”. Why?, mostly because we’re trying to put all our efforts into the next big Textpattern release – crockery branch into the repo – and don’t want to add anything more than bugfixes to the existing stable branch.
Of course, it will be included by default with crockery, like many other new goodies we’re going to talk about here really soon.
IXR_Library
which has been included in Textpattern for a long time, so no completely new RPC-libraries are required for Textpattern.There is going to be documentation for developers – I have already written more than 20 pages – and as many specific client configuration samples, including screenshots, as we can collect during the next weeks.
]]>Keep it sane and polite, please! ?
]]>