This week the guys and girls from Defensio have released the 2.0 version of their API. Not only a SPAM filter, but Defensio can now eliminate malware and other unwanted or risky content from your blog. The best part is Pixelpost supports the latest API version through a new release of the Defensio addon for Pixelpost.
A major difference is the way content is evaluated. The old version depended on an instant results after querying Defensio, sometimes resulting in comments not being processed when the service was hammered with request. Therefore the content is now evaluated asynchronous, sending the content to Defensio which will provide a callback when the processing is done.
Initially all comments for Pixelpost make it into the Defensio Quarantine. These comments can basically have two statuses: FAIL and PENDING. The later means that the results through the callback are not in yet (you can issue a query to fetch them right away). The status FAIL means that for some reason Defensio could not be contacted (either the service is down or the API key is invalid or..). In that case you can send these comments to Defensio for an evaluation.
The major drawback of the 1.0 version of the addon was that each comment that had failed had to be rechecked manually. This issue has been resolved with the addition of a new button that processes every comment with a status of FAIL or PENDING for the last two weeks. Obviously the buttons to send either HAM or SPAM to Defensio remain in full effect.
Today I managed to get to the root of a problem I have been trying to eliminate for some time now. It all has to do with the “use the EXIF coordinates” feature of the GoogleMap addon for Pixelpost. It seemed when using this feature the location magically shifted a few meters or even more.
When using reverse geocoding for latitude and longitude values Google Maps focuses on nearby (and sometimes not so near by) “points of interest” or the closest address it can find. This behavior can be changed by changing the following Javascript function function showLocationLatLng().
Change the code of that function to: function showLocationLatLng() {
var latlng = new GLatLng(document.forms['view-latlng'].lat.value,document.forms['view-latlng'].lng.value);
editMap.addOverlay(new GMarker(latlng));
editMap.setCenter(latlng, 16);
}
This will force the addon to use the exact location of the image provided in the EXIF.
The site hasn’t seen much updates lately, but as usual there is a good reason for that. I’ve been busy working on several projects. Inquisitive readers might ask what those projects are. Well, let me reveal at least some of them.
One of the projects I’m working on is the Adobe Photoshop Lightroom Export Plugin,, initially developed by my buddy Jay. As not only the author but also user of both the Googlemap addon and the FTP security addon I needed to modify the Lightroom Export plugin to facilitate both GPS coordinates and the automatic opening and closing of both the image and the thumbnail folders. Currently we have a working copy which I use extensively in testing right now. Did I mention we also managed to squash some bugs while producing cleaner code?
The other project I’m working on is the aforementioned Googlemap addon. Since I began working writing code in a more OOP manner I could see how this approach could seriously limit the duplicate code currently found in the addon. I found a nice Googlemap API Class for PHP and intend to use that as a base to rewrite the addon yet again. All features of the (unpublished) third version will be retained, but it will be lean and fast thanks to the use of OOP practices.
Last but not least I’m also working on the new version of Pixelpost. Recently we added two more plugins dealing with both tags and categories. While testing and writing new things resumes we’re building the next-generation photoblog with a solid codebase.
Every once in a while people ask us: “what’s up with Pixelpost?” The latest update was released at July 27, 2008 and they wonder about the current status.
Well, the truth is that the current release, 1.71, is pretty much rock solid and very stable (quite an accomplishment if you look at the code ). Security wise this has been one of the best versions thus far. However, we have made some minor modifications to the code since the release, but mostly we cleaned up the abundance of old code. Perhaps we will release this as an intermediate version between 1.7x and 2.x.
The last couple of months we basically didn’t do much with the old 1.x code. We spend most of our time on the new version: Pixelpost 2.0. This is going to be a complete rewrite compared to the old 1.x code and as you probably know, this will take some time.
On the forums I compared it to building a house. Let’s assume your blog is a house. Everyone likes a different style: some will like brick buildings while others are looking for a simple wooden house. But every house needs a solid foundation. The foundation is the most important part of the whole building. A house can be expanded/modified to your own taste as long as the foundation is solid.
This is an analogy for where we at with Pixelpost at this time. The main focus is building a solid foundation on which everyone can build what they like. For instance: if you want people to comment on your photos you add the comment plugin. If you don’t want comments and correspondingly no SPAM, just don’t install the comment plugin. It is going to be that simple.
If you look at the current 1.x codebase there is no way to disable comments since they are an essential part of the system. Even if you don’t want users to comment on your images it is likely you do receive SPAM comments, because the code for the comments is an integral part of the system.
So hopefully the new version will address all those issues (and much more in the form of plugins/modules, like multiple users, openID, better EXIF support and the list goes on and on). To accomplish that we have to provide a nice, clean foundation build for speed.
Over the last few months several threads have been posted on the Pixelpost forum regarding SPAM comments. In some of these threads the author boldly claims that Pixelpost isn’t stopping any SPAM. Well, since December 28th, 2006 I have installed a SPAMlog addon on my blog. Basically, what this addon does is keeping track if and why a comment is blocked.
First I think I have to elaborate on my settings, so here they are. I use the <TOKEN> setting from Pixelpost, along with a 30 seconds SPAMflood protection setting and a maximum of three URLS in a comment. Besides that I use the http://BL addon (more info about this addon) and I have installed Defensio addon for Pixelpost.
So now we know the configuration let’s show some stats from the last 743 days shall we?
It seems my photoblog received a total of 31897 comments (43 comments per day). A total of 2457 comments actually made it through the defensive lines of both Pixelpost and the http://BL addon. Defensio managed to catch 2256 comments as SPAM, so this leaves out 201 comments. It turns out that 70 of these comments were SPAM, but these slipped through before the Defensio addon was installed (The Defensio addon was installed a few months after the initialization of the SPAMlog).
These are the numbers, but what happened to the initial 31897 – 2457 = 29440 comments which were blocked by both Pixelpost and the http://BL addon?
Let me break that number down: Pixelpost internal measures took care of 17194 of these comments while the http://BL addon took care of the other 12246 comments. Basically this says that the measures in Pixelpost are capable of catching at least 50% of all SPAM comments.
So what is the internal Pixelpost method that stops most of the SPAM?
887 comments contained words listed in ban or moderation list
10379 comments used an incorrect token
2 commenters waited too long before posting (30 minutes)
156 comments were posted to rapidly in succession (SPAM flood)
5403 comments contained too many URLs (3)
114 comments contained an URL on the blacklist
210 comments were not allowed (commenting disabled)
41 commenters used an invalid e-mail address
As can be seen the token protection is responsible for 60% of the SPAM stopped by Pixelpost own defensive measures. Feel free to comment on my analysis.
Jammer, Dunckers heeft gewonnen. We staan nog steeds tweede, 2 punten achter Dunckers. Gelukkig moeten we thuis nog tegen ze. #kampioenschap#2 hours ago
@ArvidKastermans Ik vraag me af wat erger is: de video of Eva slapend voor de open haard :P Ik wacht het linkje wel af. #3 hours ago
). Security wise this has been one of the best versions thus far. However, we have made some minor modifications to the code since the release, but mostly we cleaned up the abundance of old code. Perhaps we will release this as an intermediate version between 1.7x and 2.x.
