Signal doesn't ask for phone numbers simply to combat spam; the phone number isn't an elaborate captcha. Rather, as this article repeatedly points out, Signal doesn't keep your contact lists and other data available to its servers. It uses phone numbers because phones already have contact lists, stored clientside, keyed by those numbers.
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.
> It uses phone numbers because phones already have contact lists, stored clientside, keyed by those numbers.
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.
> 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
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.
Users having to add their contacts each time they set Signal up on a new phone, should the app keep its own client-side contact book, doesn't sound like hassle.
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.
The Signal protocol has had "sealed sender" since 2018 - Signal server does not know who sent a message, because the sender's identity is E2E encrypted along with the message.
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.
Every inbound message is authenticated, and credentials are stored somewhere. Correct me if I am wrong, but I'm betting that it's with the same credential/channel as for logging-in a user (aka "sender").
Also, wasn't "sealed sender" broken (again) earlier this year by a group of researchers?
No, sealed sender messages are not authenticated. The sender's client uploads two things: 1) an encrypted message (with sender id encrypted), and 2) a zero-knowledge proof that the sender's client knows the recipient's delivery token.
There is no authentication by the sender, and the sender does not upload any credentials.
I guess I have to rephrase myself: the API calls are authenticated, because the API endpoints will not consume anonymous requests. I'd be glad if you could point me to documentation proving that the messaging API uses completely different credentials than those for user login, and that the two are also disassociated.
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.
Good luck finding documentation about the protocols and APIs used by signal. While every random cryptocurrency has a cryptography whitepaper, it seems that Signal does not.
Signal published detailed specifications of the protocol with reference implementations since at least Feb 2017 (group messaging protocol was added later on): https://signal.org/docs/
Signal has always prioritized message security and integrity over anonymity. If you want anonymity, Signal is not, has not, and probably never will be the tool for you.
Huge difference between having a low profile and actively advertising out new registrations. Does not sit well with any conceivable notion of privacy. Which supposedly is one of their strongpoints.
A) Most contacts have phone numbers
B) Most contacts don't have email addresses?
I think you're assuming this (and as it happens, I agree, although the number of email-only contacts is still nonzero for a lot of people).
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?
Give people the option to pay. I would gladly pay $100 one time fee if it meant I could avoid having a phone number associated. https://jmp.chat is a great work around but I would rather just have an email address or ideally nothing but a receipt directly associated with my signal account.
Depends, if you're able to poison the DNS of the mailprovider / hack the recipient mailserver or do a phising attack.
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.
I agree with you on this one. the person you are replying too is correct in that it does not matter how much you learn or teach yourself, getting a new number is far from trivial, whereas with getting a new anonymous email account, if you take the time to learn, it is trivial, depending on what you care about.
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.
One option could be to not be able to send unsolicited messages in the first place. Make it required for everyone to "accept interaction" before messages can actually be sent between two parties. Add in rate limiting so you can only have N open "invitations" and spamming should be very limited.
I don't see the difference between some Isabelle showing up as someone to accept or deny, or some Isabelle with a "I'm a hot single in your area, click this link" message so I'm sure it's spam.
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.
> Add in rate limiting so you can only have N open "invitations" and spamming should be very limited.
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.
Who is dealing with the spam SMS messages I get all year round? Phone numbers do not stop spam, they are used to distribute it. I know I received no spam when I had Google Talk... It is a solvable problem that I guess benefits nobody in power to solve.
I don't use SMS because I can't download an open source client to use on desktop, send pictures or other files, edit messages, encrypt conversations, share a live location, hold a poll, have group chats with some semblance of scale, it just doesn't work for more than receiving an occasional message as last resort.
Spam via sms doesn't seem to really exist here, maybe two per year now, up from zero until three years ago.
