I might as well rant about a few strange web software services. I’m a little bit sceptical about the whole software-as-a-service paradigm in general, but as long as it works, I can’t argue there’s much wrong with it. But when it doesn’t work, it’s obviously a valid target for criticism. And when the service is about security and it doesn’t work, things can get really nasty really fast.
And here, we have a good example of a few security services that don’t work.
Today’s rant target: Toolator.
Today’s first case is “Toolator.com IP Address Blocker”. It’s never a good sign if the first thing I see on the site is a big red text, saying…
Toolator offers the possibility to block/ban ip-addresses from your website with 1 single code.
This site should serve as a schoolbook example of how not to market a technology service. I should probably make a separate rant about this, but I think that mentioning system requirements on web apps is of paramount importance. A lot of software is just too annoying in this respect. If you go to, say, the home page of the blogware I use, you need to know you need to click on “Docs” and “Installation and Upgrade Guides” to get to the requirements page. The big competitor does no better - again, two clicks to find the requirements page, to see that the software supports only MySQL, and as such, is inappropriate for my use. Why can’t software packages try to tell us up front what they require to run? It can’t be that hard: “Download Melody now! (Requires Perl and a MySQL, PostgreSQL or SQLite database.)”
In similar vein, a SaaS site should be particularly upfront about the requirements. This is particularly important because a lot of SaaS services depend on functionality that is built in the platform. For example, reCAPTCHA doesn’t make this too hard to find: “What is reCAPTCHA?” has pointers to both the pre-existing webware plugins and the APIs you can use for your own web applications. Use an existing app? Download a plugin, plunk it in, set it up, done - you now have reCAPTCHA installed. Have your own weird application? Download the code, make API calls from your own application, done.
The “What is reCAPTCHA?” page also illustrates one thing that SaaS marketing pages should have: “This is what our technology does. This is how you install it.” This is because it’s a form of security technology and security technology isn’t trivial to deploy - if it’s secure. But it can be easy to deploy, as in case of reCAPTCHA.
So, this is how the script works:
- Blogger serves the evil guy your blog page.
- The page loads up a script from toolator.com, which checks if this user has been blocked.
- As the evil guy is blocked, they’re redirected.
Note that Blogger is still happy to serve the blog page to the evil guy. Note that all the evil guy has to do is to tell their browser that toolator.com is not to be trusted. I mean, everyone has AdBlock and NoScript installed, don’t they? Note how it took me precisely two clicks - one on NoScript button and another on “Forbid toolator.com” - to tell Toolator to bog off? Of course, this applies to all Toolator-“protected” sites. No use installing it now!
If this had been a properly implemented SaaS setup, Blogger would have made a remote call to Toolator and refused to show the page. Instead, Blogger is happily unaware of what transpired between you and Toolator, and just keeps serving the same stuff to everyone.
On sunnier side, however, is that “maintain a global blocklist” type of a dealie would be a proper goal for a SaaS security system. Make one website where people could maintain security parameters of their websites, make an API for it, make plugins for major software packages, and boom! One website that can handle blocking and stuff for all of the websites you use. Similar setups already exist in read-only form (think of all spam blackhole lists), and letting people muck with their own security settings in a centralised location like that could be interesting. Or, it could be hideously problematic in case the service goes down, which is why most people probably want to implement security measures on their end instead. You can’t always get convenience and security at the same time, after all.
And speaking of that, it’s probably not a good idea to mention such unreliability on the front page:
December 19th, 2011
Today our server crashed. For that reason we had to restore our database.
(Random calendar checking - yes, it’s still only April. What the heck? Oh, right, they’re talking about December 2010.)
But then again, it’d be hideously irresponsible for them to not mention such problems, and it’s better to mention them anyway.
There’s a whole lot more of weirdness that can be seen on this company. The fact that free service lets you ban whopping 3 addresses, and that the cheapest offering won’t even let you do range blocks. The fact that range blocks are given in weird format and not CIDR. The fact that the “interal website” where the banned people get redirected to appears to flog Flash clocks (judging from the screenies in The Older Geek’s blog post), which isn’t at all shady, no. The fact that the official faceless nameless corporate spokesperson guy uses Jack Sparrow as a forum avatArrrrrrr. I could go on, but you get the idea. There’s a place for whimsical and weird approaches after the proper things have been taken care of.