That's an overreaching interpretation of parent's post. Besides, the "rights" issue is a red herring. Making an analogy - and yes, I know it's not accurate, it's an analogy -, people don't have a the "right" to a free car, but if I am going to offer free cars, surely we can agree they should have breaks.
The idea that because it's free it's above all criticism is simply unreasonable.
Personally, I don't think requiring payment for SSL is wrong, though.
> The idea that because it's free it's above all criticism is simply unreasonable.
Solution: shut down the free version. Addressing complaints from free users who demand things captures absolutely zero value when you're a struggling startup with too much else to do and limited resources still trying to make a viable business. Freemium doesn't work unless you're swimming in VC money and only care about user growth, not MRR growth.
Shut down the free service and no one will get hooked to your product, and choose a another free service to start with, and maybe even pay for it later.
Providing both free and payed tier is the way to go, especially in the commodity market segment like RSS readers, unless you are in a niche without too much competition.
I disagree. RSS readers have a significant long tail expense per user. I worked at Bloglines. Pretty much every one of those free users have extra little RSS feeds that nobody else subscribes to that you have to crawl, handle invalid rss/xml for, update and keep unread status on. At scale, that is the most expensive part of operating an RSS reader, and it's not worth it.
I agree with your point that keeping RSS user is not free. But, from the users perspective, RSS readers are a commodity. You can't sell them subscription unless you provide them a free ride to actually check and hook up to your service. The only reason that OP is successful is having a business model working is that he already has a large userbase which was acquired largely because it was free.
Any site viewed over plain HTTP is susceptible to content injection by ISPs, public wifi providers, employers, etc, basically anyone between you and the server. At best it's annoying, at worst it's a security hazard.
And as someone else mentioned, the session cookie is still transmitted in plaintext, which effectively compromises your Feedly account.
Not to be too glib about it, but for God's sake, who cares? It's my Feedly account. It holds my read/unread status for my daily newsfeeds. What's the big hacker target here? Spoofing that I've already read Hacker News today? Subscribing me to feeds I don't want? I encourage Feedly not to waste time securing that on my behalf.
For the functionality Feedly provides, plain HTTP is a reasonable amount of security. I also, up until fairly recently, received news via a bundle of paper left on my doorstep. Shocking, I know.