How do you deal with spam without requiring a phone number to register?
To replace the numbers with usernames, Signal users would have to either give up contact lists altogether (at which point nobody would use the service), or allow Signal to keep a serverside database of contacts ready at all times for users who log in. This is what other messaging services do, and the result is that the servers have a plaintext log of who talks to who on their service, which is the most valuable information a secure messaging service can make available to a state-level adversary.
This makes sense for contact discovery, which is important for normal people who just want a chat app that works.
But there are a very important segment of signal users, people with an elevated threat model, who I would be willing to bet a good portion of them would gladly sacrifice contact lists if it meant not having to share their phone number.
Why couldn't they just keep using the current system, alongside usernames, for phone number contact discovery? Of course for those who opt into it; imo that's what it should be.
Could you please explain how Signal does not have a social network map, when 1) user accounts are equal to mobile phone numbers, and 2) Signal servers route messages between user accounts.
Even if Signal's server saves a message (they claim not to, once downloaded), Signal's server by design has no way of knowing who sent the message.
Also, wasn't "sealed sender" broken (again) earlier this year by a group of researchers?
There is no authentication by the sender, and the sender does not upload any credentials.
The server and clients are open source: https://github.com/signalapp
> Without authenticating, hand the encrypted envelope to the service along with the recipient’s delivery token.
Source: https://signal.org/blog/sealed-sender/#:~:text=Without%20aut...
The sender's client sends a certificate derived from the recipient's profile key.
This certificate is sent to the server as the header "Unidentified-Access-Key" - you can see how this header is derived from the Signal clients' source.
So yes, these API calls are authenticated, but not using the sender's credentials in any way.
Also, everyone not sharing their contacts with the signal app already have that UX. Minus the privacy benefits of course.
A) Most contacts have phone numbers
B) Most contacts don't have email addresses?
Are you also assuming that it just adds a lot of complexity to be willing to search by both phone numbers and emails?
That's the part of your argument I'm not grasping. Signal has to be willing to intersect known-account-identifiers with this-device's-local-contact-handles, what's the problem with preferring phone numbers but allowing emails?
Is there a reason why a user's address book can't be encrypted as well?
I just want to be able to communicate without sharing my phone number (since my phone number is bound to Swedish "Swish") meaning someone can get my ID from my phone number here.
This is why drug dealers use Wickr, Threema and others, because they don't expose identity, not because they're "safer".
I have a contact on Threema who I've met many times, but I have no idea how to contact him outside of Threema, because I don't know his identity and we'd both like to keep it that way.
In many countries, registering phone numbers anonymously is illegal and/or impossible.
Where? Gmail and hotmail both don't allow this.
Do you just care about making burner anonymous emails that just work all the time? There are vendors that you can pay for that service (my go to is protonmail), and there are free options out there as well (my go to is riseup). The problem is finding the vendor that suits your need, since these are niche services for the most part.
If you care more about the privacy / sovereignty side of things, you can set up your own mailserver, and once thats done, its incredibly trivial to spin up new burner emails. But that's an even bigger knowledge gap, to the point where its fairly common even on tech forums like HN for folks to be like "Self host email? nope thats to hard".
So yeah, I agree. This is not really an option for an average user. But in the context of signal, I think it makes perfect sense to allow it as an option, even if its not the default.
Email can absolutely be used for with e2e encryption keeping the content of exchanges from external eyes.
Email can absolutely not be used for hiding metadata of who talks to who.
That also sounds like a good way to limit adoption as well, at least for anyone with more the N contacts, particularly >= 2N as that means likely a minimum waiting period before you can transfer over "more" contacts since some people will never accept/reject the invite because they don't use the app much.
If it were me and I had to wait on others to accept or reject my invite before I can continue transferring contacts, I'm gonna move on.
On Telegram this is rampant, on average probably one person per day. It shifted from e-gold scams to sex since a few months, but both are still present. People that aren't in big groups (where the spammers scrape user IDs) have zero problems, so the trick is revealing your random identifier only to those you want to contact you. Phone number identifiers are the antithesis to spam protection: we keep our ranges just full enough that we can't shorten it by a digit, but empty enough that we have small growth possibilities. You're very likely to hit a subscriber, by design, by trying random numbers.
Spam via sms doesn't seem to really exist here, maybe two per year now, up from zero until three years ago.