[wikwocket]

Why? If it is a feature that will encourage people to upgrade, and/or a feature that only concerns the kind of people who buy "Enterprise" plans, then why not use it as a cost differentiator among the plans?

I can see how SSL is important, but the 2 lower plans are free and a few bucks a month. I don't see a problem with reserving this to the bigger plans.

[skolor]

Pay-for-security is a bad path to go down. Compare pay-for-ssl to using md5 on the lower tier for password encryption, while the upper tiers get something like bcrypt, or you only get a salted password if you pay extra.

It seems pretty absurd to require a payment for security, especially when you're implementing it for a subset of users. Its true that SSL is going to be more taxing on their servers, but the majority of the cost is going to be spent getting an engineer to implement it, rather than the actual operational costs.

[ozataman]

Agreed. I would argue the SSL tax on servers is fairly negligible in this day and age.

As for other reasons:

1. It leaves a bad taste in your customers' mouth. Security should be an option.

2. Imagine the disaster if someone makes front-page on HN complaining how their PW got snooped and their top-secret project plan is now public.

Pay-for-SSL was a bad idea back in 2005 - now it's a non-starter in my opinion.

[bobwaycott]

SSL concerns the kind of people Subtask is marketing its product to. Including me. It's a non-starter as-is. I was interested to sign up and try it out right until then.

Security is never a feature. The app lost all credibility at that point.

[JangoSteve]

Normally, I'd completely agree that if it's a feature people want, then they can pay for it. But SSL isn't just about protecting the person's data, it's about preventing people from snooping their login credentials over unencrypted traffic (e.g. at a coffee shop). If they use the same login as their email or other accounts, then by excluding SSL from any tier, you're putting those users at risk, not just within your own app, but for their other accounts as well.

In an ideal world, if your app has the ability to login, it should have SSL. And I'm not trying to be a judgmental idealist either, just answering the "why" question after thinking it through. I'm certainly guilty of having a couple old apps out there I've not yet updated to use SSL. I think I may have to go do that now.

[michael_p]

You're completely right and in fact all URLs where your login credentials are transfered (login, signup, change password) are guaranteed to be SSL regardless of which plan you're on.

[rubinelli]

If SSL is too expensive for the Basic plan, consider dropping it altogether, or increasing it to EUR 9.95. You can also slash the free plan in half (1 project, 5 MB, 50 tasks) to encourage people to move on to paid; one project is more than enough to decide if the tool is for you.

[notahacker]

I can't help thinking the github model might work here: publicly viewable mindmaps are free and you pay to restrict access to specific signed in users. Privacy is a better selling point than security, and some publicly shared mindmaps will generate backlinks.

[mAritz]

You should also serve the pages on which the login/signup/changepassword forms are over SSL.