Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why do we have to engage in hypotheticals about whether or not anyone will act in a morally upstanding way when we could instead design systems which don't require trust at all? Or better yet, use estalbished systems which don't require trust?


Because the general population doesn't give two shits about truly trustless systems, they want "good enough". And, while you and a few others might care about it, that's not enough to actually pay the bills, especially when designing trustless systems costs more money than an alternative. Your hopes and dreams don't pay for infrastructure, unfortunately.

So, once again, what about Protonmail makes them a scam, other than not doing things exactly the way you want them to? I've seen absolutely no indication they're a scam from any of your comments or their replies, and your grievances seem to boil down to one feature (the bridge) being paid-for. That's hardly scam-worthy.


I'm not talking to the general population, I'm talking to Hacker News. And among the general population, people who really need encryption are not necessarily going to know how to use it, but need to understand what kinds of guarantees are being made to be safe.

A service which makes you pay to extract your own data with standard tools is a scam in my book. If you don't support IMAP and outgoing SMTP you can't even call yourself an email provider in my book.


You might not be talking to the general population, but ProtonMail is at the end of the day a service provider intended for the general population. They can't sustain their business on security-conscious people alone, so their decisions are going to be targeted towards the general population to some degree. Whether you like it or not, you have to think from the perspective of the general population because nobody is going to cater to the incredibly specific niche you live in. Even within HN, your arguments represent a minority. I highly doubt even a double-digit percentage of the HN readerbase cares about this issue as deeply as you do.

Then your book is flawed and doesn't align with the actual definitions of "scam" and "email provider". Especially for the former, there's a much higher bar, and your arguments are far from meeting it.


>Then your book is flawed and doesn't align with the actual definitions of "scam" and "email provider". Especially for the former, there's a much higher bar, and your arguments are far from meeting it.

Let's define the requirements for the former, then. If someone claims to offer a service they don't, is that a scam? I think so. Now if we can justify the, by your own admission, weaker requirements for calling Protonmail "not an email provider", we've established they're a scam.

An "email provider" that doesn't provide IMAP and SMTP isn't an email provider any more than Facebook's proprietary "free internet but only on Facebook" is "internet service".


> An "email provider" that doesn't provide IMAP and SMTP isn't an email provider any more than Facebook's proprietary "free internet but only on Facebook" is "internet service".

By your incredibly rigid definition, sure. Good thing the world doesn't live by your definition.

An email service provider is, based on the words alone, someone that provides email services. Do they allow for sending and receiving email from one or more email accounts they manage? Yes? Well then they're an email service provider. Many providers supported POP3 only for years, yet they were still called ESPs just fine, even without the IMAP support. Funny how that works.

This is going to be my final message on this, because your incredibly rigid and stubborn definitions and beliefs clearly leave no room for debate and nobody is going to change your mind because you are totally and completely right™, but what I will say is that if you care about this so much, there's absolutely nothing stopping you from making your own alternative that works the way you think it should. Just stop calling things scams because you disagree with their design decisions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: