UPDATE: Thoughtful response from Jesse @ Hiveminder in the comments.
Fans of Getting Things Done [GTD] are on a never-ending quest for the ultimate solution to help them get and stay organized. Remember The Milk [RTM] is one Web 2.0 site growing in popularity amongst the GTD-followers which allows you to perform task management via a slick web interface, from instant messaging services, on Twitter and even has a robust API for custom integration (not to mention some very interesting Google Apps interfaces). Amazingly enough, it even allows you to perform actions over SSL so your credentials and task bits remain secure (if you’re into that whole security thing when it comes to putting your information on Web 2.0 sites).
Contrast that with another contender I just learned about - Hiveminder. It has the similar integration points and facilities (some not as spiffy as RTM), but an entry in their FAQ gave me pause:
You’re not using SSL; how do I know my password is safe?
If you have a Javascript-enabled browser (most of them are these days), then your password will be encrypted when logging in, before being sent to us over the internet. But we also offer SSL encryption as a feature to pro users.
In other words: we don’t care about the security of your data unless you pay us to.
That is a fairly cavalier attitude given that their competition lets you encrypt all web traffic whether you are entering login credentials or just plain browsing.
In many cases, Web 2.0-ish sites put features first and security second (or third), and my concern is that others will either adopt this model of “Features? Sure, you can have ‘em! You want security? Cough up some dough!” or alter their terms of service to switch to this business model at some point after they gather a decent user-base.
This is yet another example of why you need to read the fine print when choosing a product or service and - especially for Web 2.0 sites - ensure that you have complete control over your data.
Technorati Tags: 
Tue, 2008-02-19 19:36
I couldn’t agree more that you should read the fine print of _every_ service you use, but thought it might be useful to give a bit of background about what we do for Hiveminder (and why we do it).
First up, we’ve been doing the javascript hashing trick on passwords since we launched to make sure that users’ passwords don’t go over the net in cleartext no matter who they are.
Second, that note in the FAQ is actually slightly misleading. ALL users can log in with SSL, but you need to have a (<$3/month) pro account in order to be able to interact with your tasks over a secure pipe.
We’re a small company and we’re giving away service to most of our users. We’ve built Hiveminder by stealing time and resources from our consulting business and opensource projects (primarily RT and SVK). When we sat down to decide what we could add to Hiveminder for folks who are willing to pay for a service, one of the most common requests was “I’d pay for SSL.” Unlike many other possibilities, SSL actually comes at a real incremental cost to service providers. The overhead of SSL is, while not huge, measurable.
The myriad other interfaces that tools like Hiveminder and RTM offer also somewhat nullify the advantage you’d get by having an all-ssl service. AIM and Twitter aren’t encrypted. Nor is most users’ email. The choice not to provide blanket SSL for all users may be many bad things, but it was _not_ cavalier. We thought long and hard about it and the incremental security improvement it provides didn’t outweigh the costs over what we’re already doing to help users safeguard their credentials and privacy.
Best,
Jesse, for Hiveminder
»
Tue, 2008-02-19 19:56
Hey Jesse,
The thoughtful response is greatly appreciated and it gives folks some insight into the choices made.
I just need to point out that I made no assertion regarding the security of the IM/Twitter/e-mail transport features of other services. For non-sensitive tasks those - and your free option - transports are fine if the user is willing to take that risk.
Not providing SSL as a base option just doesn’t seem like A Good Practice for Web 2.0 services to spread. RTM is free and foots the cert costs and CPU overhead bill. While you may have some users who would pay extra for SSL, anyone can use RTM without having to.
At the end of the day, however, it’s all about risk tolerance and service benefits/costs vs risks. If your functionality is sufficiently more capable (and I’ve not done enough testing to fully compare either way), then users may either accept the risk or pay (the very reasonable yearly sum) to mitigate them.
»