Hacker News new | past | comments | ask | show | jobs | submit login

Worth noting that Google does not do what you're describing. Google has never literally "sold" data from Gmail and stopped using it for their own ads ~6 years ago.




This is about displaying ads in the Gmail UI, not reading email content.


Those ads are still targeted to you, maybe not off of your email content (now vs 2017)


So gmail was making money off of personal emails as recently 2017. Why trust them? There is no good reason they shouldn’t e2ee that data.


Except there is a reason. Encrypting email has very little to no benefit, since it is transmitted in plaintext and usually stored in plaintext on the recipient's side, your emails almost always exist in unencrypted form. On top of that it has major usability drawbacks, for example you cant ask the server to search emails for you anymore - all emails have to be downloaded on all your devices to be able to search - which is what skiff does. It will be okay at the start, and progressively get slower and use more space on your drive the more you use it.


> Except there is a reason. Encrypting email has very little to no benefit, since it is transmitted in plaintext and usually stored in plaintext on the recipient's side, your emails almost always exist in unencrypted form. On top of that it has major usability drawbacks, for example you cant ask the server to search emails for you anymore - all emails have to be downloaded on all your devices to be able to search - which is what skiff does. It will be okay at the start, and progressively get slower and use more space on your drive the more you use it.

This are just old technical problems which are already solved, for example by Tutanota. Mails are not send in plaintext if they are encrypted, and mailbox can be encrypted too. Plaintext version of your data exist only in the memory of your computer while the session for your mail client is open.

What it comes to the search - it does not matter anymore. We have enough computational power these days and storage to hold emails on devices. User experience is about the same. Increasingly, it is just optimisation problem which can be done right. Just don’t use Electron for your email app.


Unfortunately not even close. When the server gets the email it is not encrypted (unless the sender has a skiff address too, which is a very tiny portion...). And when you send an email to anyone outside skiff it is the same problem, the email has to be unencrypted so the server can send it in a form readable by the recepient. Without anything like PGP the server does not know the reciepent's public key, so it is impossible to encrypt it.


We might be talking about different encryption, since that does not sound E2EE at all. The point of the encryption is that server never sees the content.

But that is true that if you use skiff to send message for someone, who is not using skiff, the message is unencrypted because receiver has no means to decrypt it.

That is standrdisation issue. Apparantly PGP is not considered good enough.

But if we had standards, we have techology to provide E2EE emails.


Totally agree... it is just disappointing that services like Skiff advertise total E2EE to unsuspecting users with no mention of this in their marketing, luring users into a false sense of security


European based Tutanota offers possibility for send E2EE for non-Tutanota users. It works by setting password for the content, and you need to deliver the password in other means. But usability suffers on this case, but at least there is a possibility.


Skiff encrypts all received emails with user public keys immediately on receipt. This is quite clear in our security model page and whitepaper. Skiff does not have access to any user emails, including external received ones.


Unfortunately this does not matter, since the trust model is same as it would not be encrypted at all. We still need to trust the third party.

Somehow the infrastructure should be transparent so that outsider can verify indeed at any time, that you don't collect logs from that traffic, or have no other means to inspect traffic if you want to.

There are currently no other means than just to use E2E encryption.

There is also another almost there, but that would mean that you should open-source your whole infrastructure, and use reproducible builds. Somehow there should be way to get access for outsiders, that you indeed use your infrastructure as you describe in your source code. But this is very complicated and also changeable at any time, unlike E2EE.


We use an open-source mailserver (Haraka), but security audits are the most trustworthy way to do this. We've had 4: skiff.com/transparency. Audits cover infrastructure.


You can't audit a non-E2EE design into E2EE security!


i have 2.5 million emails in a 32GB datastore. no mailprovider is going to allow me to store that much mail, and search is actually quite fast. if it isn't for you, then get a better mail client.


Google's cheapest paid plan ($6/month) gives you 30GB. The $12/month plan is 2TB of storage. I currently have over 30GB of email in Gmail and everything works fine.


I have around 17GB of pop3fetchallnokeep in the mail folder and the backup is somewhere in the btreeflatfile heap in that UtahDataCenter free of charge training darkgpt 5.8




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

Search: