Tools that go beyond typical email security also tend to hamper this use-case. I frankly really wouldn’t want to use Delta/Arcane Chat to sign up for a newsletter or a Netflix account or whatever. They just aren’t built for that.
It’s actually perfect for that: since you never need to reply to any of those email, you can create a one-shot address for them (although that’s part of chatmail, not DC/AC per se) and then hide those accounts forever.
Basically, I don’t think Delta/Arcane Chat should get a special status on our website because they’re based on email, I think it is more accurate to compare them to instant messengers despite them being based on email, and write our guides accordingly.
The point is, the perceived deficiencies of email are not due to its intrinsinc properties but to its social usage. If those deficiencies can be solved, why not say it and put it forward ?
So, I thought they did, but if you are a user you might know better. Great to see. The point still stands. Email IS insecure. Maybe delta chat is not. If delta chat makes enough changes, then it is no longer email. It is delta chat. It is not a good or bad thing, it is just different. Just like enough changes to the OTR encryption protocol makes it something different (signal protocol), not better OTR.
I think the bottom of the misunderstanding is a different definition of what “email” is. Is it the protocol ? Is it the usages ? Everyone agrees that current usage of email is insecure, but that’s not interesting because that’s not its original goal. What matters is how current usage can change towards something that is far more interesting without changing its actual use.
There is a more current ‘plan’ to implement forward secrecy once the crypto refresh (RFC 9580 - OpenPGP) is standardised.
Upcoming improvements
After the crypto refresh of the OpenPGP standard is released, we plan to continue to work with the OpenPGP Working Group to bring even more advanced cryptography and additional features to PGP, such as:
Security improvements
Post-quantum cryptography (a topic that we’ve already been working on. We’ll publish a separate blog post about it shortly.)
Forward secrecy (protecting messages sent today even if a key is compromised tomorrow)
I agree, make something better. But that is different than barging in here and saying the email overview is wrong.
I also find it curious that 2 accounts recently created after I asked arcane chat about something, both are trying to defend a relatively unknown service.
Proton is doing reasonable work. Last I read GnuPGP was blocking their work.
write a PoC, I already provided you access to a full raw email with headers and all, exploit it, show me what you got
I think it would help if the guide started with a short explanation of what is defined as “email” by it, DeltaChat, Thunderbird with encryption etc. certainly are email and are compatible with each other. Same with ArcaneChat it is not an “closed-off system” it can interact with other email servers. Maybe the guide should start with “we refer with email to using gmail, outlook, etc. with a half-assed email client from the 80s without proper encryption support”
(@mountainofmeat replaying to you in older post because I reached the number of post per day it seems “new” members are limited)
E-Mail is not “secure”. Services want interoperability with each other so they have to make compromises. It doesn’t matter if your isolated service uses the SMTP protocol in a special way, it doesn’t make e-mail more secure, only your closed-off system. Quite literally the exception to the rule, but if you start listing exceptions to everything we’ll never find the end of it.
Changing the definition because a technical-minded individual disagrees is not productive. E-Mail should continue to refer to the commonly used services. If you have to jump through multiple hoops to make it secure, you might as well use a protocol that was designed for it from the start instead of hacking features onto an old one designed to be “electronic mail”, a way to send messages easier than paper mail.
You keep not understanding the point. You seem to have not understanding of IETF works, how standards are implemented, and how terms are important. Your users have similar technical illiteracy guessing from the two sockpuppets here. It makes me very worried about whatever software you are making. I won’t engage further due to the ad hominems. I will also be advising folks the same, adding you to the list of projects that do not understand what shoulders of giants they stand on, led by coders who never graduated to become actual programmers. Keep twisting words you cannot comprehend.
I would also like to just register my confusion that the moderators have not stepped to curb these personal attacks in, yet simple off topic posts are flagged within seconds. I am not sure if this is because the person breaking community guideline is some minor dev, or if they simply missed it. For now as remedy I have blocked the dev and their sockpuppets. (The offending post is now removed, happy to see prompt response from the moderators.)
You keep saying this, but disappearing messages are a feature pretty much every secure messenger supports, so it isn’t really a slam dunk to be one of the only security-focused messengers besides iMessage that doesn’t have this basic functionality.
you will not see this message, but I am sorry if my joke was offensive, maybe it was a bit over the top to send a meme.
But you keep talking about other people as “sockpuppets” and undermining Delta Chat users etc. which is also not nice of you.
FYI I am a graduated of Computer Science, but anyways I find your comment very offensive, there are people out there that never graduated in university and know a lot more than me and absolutely much more than you.
it exists but do every single user have this feature enabled? does Signal forces disappearing messages for PFS to be secure and make sense? if most users don’t use disappearing messages because they don’t want to lose their messages history, what is the point? and if you need to use disappearing messages for PFS to make sense, how is it then better than just using OpenPGP and creating a temporary account/key and drop it after a while? besides when you have a central server collecting messages then PFS sounds more interesting because the attacker needs to control de server to collect the messages and decrypt them later when the key is compromised, but with decentralized servers there is no easy way for the attacker to control the particular server you might decide to use (or even self-host)
Honestly there is quite a bit on bad faith being thrown around. I feel like this is two conversations: one about DeltaChat/ArcaneChat, the other about email by itself.
An analogy I see here is that WireGuard uses UDP. I would not consider UDP by itself a secure protocol. I consider WireGuard built atop UDP as secure. There are ways to secure UDP outside of WireGuard through other encryption schemes.
Email by itself has privacy leaks. DeltaChat built atop email is more private than traditional email. There are also ways to maintain some privacy in email outside of DeltaChat like through PGP.
Rather than compare apples to oranges, I’m curious how DeltaChat compares to email with PGP.
EDIT: and then truly compare the differences between DeltaChat using email (I’m assuming the base is SMTP/POP/IMAP related protocols) as transport layer, vs Matrix, vs Signal.
I’ve only given a quick read and it has been mentioned already, but I feel like the primary point of contention is interoperability.
Email can be called secure, only if you’re able to maintain that security while sending an email to any random address I give you (without them having to use another service to open the mail).
I’ve never looked at DeltaChat and ArcaneChat and don’t know what they are exactly, but can an ArcaneChat user send a secure email that I can read from my Tuta client? Or maybe to a mail(.)com or yahoo(.)com user? If not, I personally wouldn’t consider email secure, because this is how email is meant to be used.
Afaik, Perfect Forward Secrecy thwarts a class of offline attacks where malicious actors eavesdrop on encrypted comms with the intention of decrypting it at a later date, probably after they compromise the keys (or break encryption).
These malicious actors are usually corporates and nation states.
it seems “new” members are limited)