> i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction.

I mean this kindly: I wish they would think a little bit more inside the box, and converge onto a proven design.

(It’s worth noting that your “existing infrastructure” argument is exactly why Signal uses phone numbers. Using existing infrastructure is a great idea, so long as it doesn’t compromise the security expectations any reasonable user has. That isn’t currently true for Delta Chat.)

▲

em-bee 6 hours ago | parent [-]

exactly why Signal uses phone numbers

the reason may be the same, but the effect is entirely different. until recently signal did not allow hiding the phone number, failing my privacy expectations. a public phone number is something entirely different than a public email address. signal is also centralized with its own servers. deltachat works completely without dedicated servers. and emails easily allow multiple accounts.

and what are reasonable security expectations? what you and i consider reasonable does not at all match what the general population expects. for most people sending encrypted emails would already be a win. (autocrypt also works with regular email clients, not just deltachat)

the goal here is to raise the general use of encryption in messages. if that is not sufficient then deltachat is not the right tool. but i have friends on telegram and whatsapp. getting them to use deltachat would be an improvement.

▲

woodruffw 5 hours ago | parent [-]

Centralization is not a security property in the context of E2EE. You can want decentralization (I often do), but it’s essentially an ideological demand rather than a security preference when the server provably has no access to your messages or metadata.

> and what are reasonable security expectations?

End-to-end encryption that the user can’t accidentally downgrade from and that doesn’t spray valuable metadata across the Internet. That’s table stakes; I’m not interested in lowering my standards below that.

> for most people sending encrypted emails would already be a win.

I don’t think this is even remotely true. I think the average person doesn’t know what an encrypted email is. We’re now in at least the third decade of encrypted email techniques, and adoption outside of corporate S/MIME (another can of worms) is marginal.

There’s almost too much to even say here; it’s a disservice to even accept the implicit assumption that users would use encrypted email correctly if they could be made to: the single most common breakage point for all of this stuff is still people replying or forwarding previously encrypted messages in the clear!

> the goal here is to raise the general use of encryption in messages.

No. The goal is security. “General use of encryption” goes back to putting ideology before security. The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people. The US famously kills people based on metadata[1], and we’re the “strict” ones in terms of evidentiary standards.

[1]: https://www.nybooks.com/online/2014/05/10/we-kill-people-bas...

▲

em-bee 4 hours ago | parent [-]

Centralization is not a security property

true, i wasn't thinking about security here but reuse of infrastructure. signal doesn't reuse infrastructure because it needs its own servers.

End-to-end encryption that the user can’t accidentally downgrade from

that's a fair point.

that doesn’t spray valuable metadata across the Internet

i find that a gross exaggeration. yes. metadata can be read by every server the mail passes through. but in practice most mails are only touching the sending and the receiving mail server. if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.

also, where i use deltachat, the alternative is to use email.

I think the average person doesn’t know what an encrypted email is

which is why we need more encryption by default.

adoption outside of corporate S/MIME is marginal.

because it is to hard to use. deltachat makes it easy to use. next possible step: delta mail. a more traditional mail client that makes encryption as easy as deltachat does.

The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people

there is a long road to get to that. more encryption is just one step, but a necessary one. i agree with you, but the goal can't be reached if we don't work on multiple fronts. one of those is helping people to learn about encryption and privacy, which only happens by slowly getting them to use better tools and by improving those tools.

rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some. sometimes that makes sense, especially if the solution promises more than it holds. and deltachat would fall into this if it were to promise complete privacy. but i don't think it does that.

i have friends who outright refuse to sign up to a new service. but deltachat is ok because they can use their existing email for it. technically that sounds the same as saying that with signal you can reuse your existing phonenumber, but people already have much higher privacy expectations to sharing their phone number, and also deltachat doesn't share your email address except with recipients so it really isn't the same thing.

▲

woodruffw 4 hours ago | parent [-]

> if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.

Why are we entertaining this hypothetical? It isn’t true in practice; the average user doesn’t control their mail server. The average user is using Gmail or Outlook, where their metadata is a single subpoena away.

And again, it just isn’t true: you need not just control over the server but also strict transport security for this property. This is not widely true of mail servers on the Internet.

> rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some.

I don’t agree. I think the average user has multiple high-quality E2EE messaging technologies available to them, and that Delta Chat effectively muddies the water by providing a worse security posture with the trappings of a familiar-but-unsecurable ecosystem (email).

(I also don’t know why people think Signal shares your phone number with people other than recipients. To my knowledge, that has never been the default and presumably never will be, even with their private contact discovery protocol.)

▲

em-bee an hour ago | parent [-]

the average user doesn’t control their mail server

fair point. there are options however. you are not locked into trusting a specific entity. but the critical point is that even signal is able to figure out who is talking to whom: https://sanesecurityguy.com/articles/signal-knows-who-youre-... sure, for SMTP the contact details are directly in the messages, which is worse, but i don't know of any service that works completely without metadata. but signal is at least trying.

also strict transport security for this property. This is not widely true of mail servers on the Internet

since gmail requires TLS i highly doubt that there are many servers out there that don't support it.

the average user has multiple high-quality E2EE messaging technologies available to them

available and willing to switch are different. as i said, my friends are not willing to sign up to yet another messaging service. it's a social media fatigue.

why people think Signal shares your phone number with people other than recipients

that's not the point, at least for me. i am hesitant share my number with signal or any other service, and worse, i do not want to share my number with the people i talk to. i refused to use signal until the later was fixed. i refused whatsapp too, but to many people that i need to reach demand it, so i had no choice.

these are all trade-offs. not everyone agrees on the same, and while i understand and principally agree with your arguments, for me they don't work because i can't convince my friends. i also have other friends who do run their own mail servers. i have contacts who require whatsapp and others who can only use wechat. most often i don't have a choice. i am using whatever i can get people to agree to, and for that deltachat is a good option. signal could have been a better option but unfortunately their requirement to share phone numbers until recently made them a worse option than deltachat or even telegram for anything but 1:1 communication with trusted friends (those who i trusted to have my number). that has changed now, and i started to use it. but it will take time to build up my contacts there. btw, in some countries it is not even possible to sign up to signal. the number gets rejected.

	▲	woodruffw 24 minutes ago \| parent [-]
		> since gmail requires TLS i highly doubt that there are many servers out there that don't support it. Gmail doesn’t require TLS, unless by that you mean that their webmail interface is TLS only. Like every other mail provider, they do opportunistic TLS on external delivery, and TLS on MUA connections (SMTP and IMAP) is largely at the mercy of user configuration. The fact that people seem to think that TLS is a mainstay of the email ecosystem is clearly part of the problem here. As for the rest of this: I’ve hammered on about Signal because it’s the naive right choice, but it’s ultimately up to you to decide whether your phone number is an acceptable public identifier. But even if it isn’t, there is so much out there that’s indisputably better than this mess: Matrix or even iMessage (with an email identifier instead of a phone) would be better.