In most European countries you need to submit your ID to get any sort of working SIM card.

If that’s the case doesn’t it matter even less that signal requires it since it’s already known anyway?

Signal’s use of phone numbers as IDs means they don’t have to have any of your contacts sent to their servers.

As shown in the article they have no metadata and nothing to reveal beyond your phone number and when you signed up.

These other apps send your social graph to their servers, track and store metadata, don’t have encryption on by default, roll their own cryptography, or some combination of all of these things.

The phone number obsession on HN seems dumb to me - a meaningless thing for people to repeat and complain about that doesn’t actually matter so they can sound like they know what they’re talking about.

I don’t get it.

The only real criticism I have for signal is that they’re not federated so they’re vulnerable to shutdown. I think that’s okay though because we have Matrix working on that problem and having both is probably a good thing.

It’s also a thoughtful and intentional choice: https://signal.org/blog/the-ecosystem-is-moving/

The response from Matrix: https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom

Assuming you’re using Signal for organizing something the government doesn’t want you organizing, if one member of the group gets rubber-hosed into unlocking their phone, the govt instantly gets a list of verifiably correct names of people involved. In contrast, with a service that lets you use usernames that maneuver would reveal nothing but those usernames (which are as pseudonymous as it gets).

One of the other problems with using phone numbers, is that it provides an opening for adversaries. Now they know your phone number, which can be used for social-engineering attacks to attempt to bypass 2FA for any other online services tied to your phone number. Either for 2FA or for account-recovery/i-forgot-my-password functionality. 2FA by SMS is wrong and broken and nobody should use it, but they do.

Adversaries will attempt to social engineer customer service for your phone carrier into issuing them a new SIM or porting out the number, so they can receive verification SMS and phone calls.

Signal uses a registration pin to prevent that exact attack.

Maybe I misread, but the GP doesn't seem to be talking about impersonating a user on Signal, but rather impersonating that user on other websites that depend on SMS 2FA sent to their phone number that is now visible through Signal.

Thanks - the concern makes sense to me given that context.

I feel comfortable with giving my Telegram username out to random people on the internet and posting it on my website because it doesn’t mean anything outside of Telegram. I wouldn’t post my phone number publicly.

That’s fair, thanks - I think for secure communication with people you don’t know personally or trust, it’d be better to use something that doesn’t share your phone number.

> roll their own cryptography

Signal did the same thing. They invented their own cryptographic algorithms. https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm

And the social graph IS sent to servers by Signal. It's protected only by hashing (trivial to circumvent) and by the Intel SGX technology (a bit harder to circumvent, but I doubt that the US govt can't do it).

Signal's crypto is an incremental improvement of existing algorithms with good reputation, OTR and SCIMP.

Telegram's crypto is reportedly designed from scratch, with questionable choices such as SHA1 and MAC-then-encrypt.

https://www.cryptofails.com/post/70546720222/telegrams-crypt...

https://eprint.iacr.org/2015/1177.pdf

I didn't want to claim that Telegram's crypto was better or as good as Signal's. But saying that Telegram rolled their own crypto while Signal did not is misleading as both designed their own protocols.

Also, Telegram uses SHA256 now in the places relevant for security, so that point was resolved.

My (limited) understanding is numbers are queried to see if accounts exist, but those queries are not connected to the users sending them (and they are obscured in transit).

Am I wrong?

Signal’s cryptography has also gotten a ton of attention, I don’t think the same is true for competitors.

Transit encryption is employed by other services as well. Whether there is de-correlation on the cloud backend I don't know. Maybe there is, but you can't really verify that and it's easy to correlate them again, especially if clients use ipv6 or non-CGNAT ipv4.

>If that’s the case doesn’t it matter even less that signal requires it since it’s already known anyway?

Well, if you're operating on that premise, which is to say, a premise of complete and total resignation and surrender, then from that starting point of course you haven't lost anything. I don't think anybody is joining you though in agreeing that that's a legitimate starting place to analyze privacy concerns associated with the phone number requirement.

This is such an uncharitable interpretation of what I was saying that it's basically a straw man.

If you're required to use ID to get a SIM (as K2L8M11N2 stated in the parent comment I replied to), then what I was saying follows - that the person is already tied to the phone number anyway.

In this context Signal revealing the only data they have (that a phone number signed up on X day) really doesn't matter or reveal anything new.

K2L8M11N2's other response to my comment is a helpful clarification, it's less about what can be compelled from Signal the company and more about what can be turned over if a user's device is compromised. In that context the name to number connection is more serious because they also have the content.

I'm sorry but absolutely nothing about this is a straw man or uncharitable, and I'll explain why.

>If you're required to use ID to get a SIM (as K2L8M11N2 stated in the parent comment I replied to), then what I was saying follows

Yes, and this is what I was responding to. You want that "if" to be taken for granted as an unchallenged starting premise to your entire argument. And that amounts to a massive privacy concession. And the fact that I'm challenging that premise, and bringing up the privacy concerns that are associated with that "if", that is the thing that you're describing as uncharitable. Even though you don't appear to dispute that it is indeed a privacy concession. And it only follows if you don't contemplate alternatives to using a phone number, which is what I took to be their point about the problems associated with a phone number.

>and more about what can be turned over if a user's device is compromised. In that context the name to number connection is more serious because they also have the content.

That's going true in any context where your number can be revealed, which is why it has unique disadvantages that usernames wouldn't have, under any conceivable hypothetical scenario. I'm glad that you benefited from their clarification but that struck me as a truism about the nature of phone numbers versus the nature of usernames.

> "You want that "if" to be taken for granted as an unchallenged starting premise to your entire argument."

I don't want that 'if' to be anything. It was the premise, because the parent comment I was responding to was stating it as a fact for where they live.

My point is that signal revealing your phone number and when you signed up doesn't reveal anything new about you. The issue is the case K2L8M11N2 mentioned when they have compromised a device (and can now tie content to IDs via the phone number).

> "That's going true in any context where your number can be revealed...under any conceivable hypothetical scenario."

This is just false? Without access to the content on a compromised device a phone number alone doesn't reveal much (that's the entire point of the e2ee), if it limits the ability for Signal to hand over the social graph or any other metadata (which does reveal a lot) that seems like a win.

Obviously revealing the phone number still reveals more than a username would, and if you can get all the benefits of not having to upload your social graph to their servers or share metadata without having to use phone numbers that would be better - I think they're working on that.

People using apps that upload their social graph and collect their metadata so they don't have to use their phone number are probably making the wrong choice when considering the trade-offs.

"The social graph" (your phone book) is most likely already uploaded somewhere by third-party app or even Google/Apple themselves. Using separate contact list (even uploaded to some server) seems more secure to me than using your phone's one.

The phone number is much more valuable to any authority than other metadata because they are more likely to have access to cell service than to messenger services.

In the context of the post, signal is much more vunerable than even basic things like email or web chats because police can effortlessly identify anyone in the group chat with a single request to cell company.

Signal can have a great interest in buying up private data linked with phone numbers and add people that they chat with with their phone numbers, sell again with the added data.

Just do like TOR services. Hash some garbage with your private key. done.

This is no excuse other than copying the leading app for no good reason.

That wouldn't be a problem in phones where the radio part is screened from the system (Pinephone?) so that implementing encryption can be effective. The SIM might be tied with my me, but any eavesdropper would see only noise because the outgoing data is encrypted by the system before entering the radio hardware and is decrypted by the system after leaving it. They can know I generated some traffic at a certain moment, which is the same information they could get from the carrier operator, but that's about it.

In the UK you can buy a SIM from a vending machine in the airport.

Don't you have to keep paying for the sim, otherwise someone else might "steal" your account once your phone number gets reused?

Yes, and I'm tired of hearing "burner sim" thrown around as a solution whenever some company stupidly demands a phone number. Getting a burner sim is WAY more effort than I'm prepared to expend to sign up to some service.

Stop asking for phone numbers!

My mother has my phone number. A few of my closest friends and family have it. That's it. I have like 10 actual people on my phonebook. My phone provides immediate 24/7 access to me, and there are very few people who are close enough to me that I want to be able to reach me at any time.

Some Silicon Valley company with an inflated sense of importance is never on that list...

Furthermore, "burner sim" implies an accompanying burner phone and all of the opsec that entails (eg only turn it on away from home), lest that "burner" number be trivially linked to your identity through databases that the telephone companies are happy to sell.

Moxie should know better, but this blog post repeatedly boasts about privacy while not addressing this at all. Getting basic encryption into the hands of the masses is a laudable goal. But when the popular threat model changes (eg pocket computer compromise incident to arrest at a protest - an "evil raid" attack), you either need to adapt or you've become an attractive nuisance.

Specifically I'm envisioning an attack where say ten protestors are arrested and found to have a shared contact, and then the police turn that phone number into a real world identity and go after that person for organizing.

Signal has an option to prevent this by locking the number with your PIN. This capability introduces plausible deniability that a phone number assigned to a SIM is actually associated with the number of a Signal account. Don't know if that matters legally or not.

Also the people doing shady things are generally hopping accounts regularly anyway.

PIN only stops registration for a fixed amount of time, believe 7-days, then the entity controlling the number would be able to reclaim the account. If the “attacker” maintained control, new devices that add the number from their contact list would get no alert; that is, the users would have to figure out the number is controlled by someone else.

That’s 7 days since last use. So if you continue to use the app at least once every 7 days, it will remain registration locked.

Also, anyone who had communicated with you before the switch would see a “safety number changed” notification if the number became affiliated with a new device.

Curious, where’s the “last use” in the documentation or code? Ask because I have seen other issues with the PIN vs docs and haven’t gotten to testing the recovery mode.

EDIT: Found the related docs, appears they had been edited since I lasted looked at them; for example, you can now disable PIN reminders:

https://support.signal.org/hc/en-us/articles/360007059792-Si...

And yes, “anyone who had communicated with you before the switch would see a ‘safety number changed’ notification if the number became affiliated with a new device” is correct, though so is my statement about new numbers adding the number. To be honest, I have caused the alerts to happen before, the other user had no idea what they meant, didn’t say anything, just clicked okay.

Isn't the pin lock just a time lock?

Both of these rhetorical claims are misinformation. Please don't do this.

Telegram messages are encrypted at rest on Telegram's servers with the keys held by Telegram the company. [1]

MTProto is fully open-source. [2]

Here's a FAQ of Telegram's most frequent criticisms. [3]

[1] https://telegram.org/faq#q-do-you-process-data-requests

[2] https://core.telegram.org/mtproto

[3] https://telegra.ph/How-really-secure-and-private-is-Telegram...

The "encrypted at rest" claim is completely meaningless since there's no way of verifying it. If their web client can read your messages by you reverifying your phone number, so can anyone else with access to their servers.

But that's not true. We can verify a Cloud Chat message is wrapped in a key generated on a user's device. You can look at the client code and prove this. We can also prove that client-server messages must be decrypted on their way back to a user's device. [1]

[1] https://core.telegram.org/mtproto#authorization-and-encrypti...

I wish it was different, but it isn't. Mtproto v2 seems OK, but it is not default, so hardly used. Server side encryption protects against very little.

I like Telegram, but not for security. Nobody should.

You wish what was different? My rebuttal specifically corrected false claims, without opinion.

The way you use encryption matters as much as the quality of the crypto used. In Telegrams case, usage is all wrong and not even better than e.g. WhatsApp. Opt-in E2EE is worse than having it be default, and server side encryption with server side keys is bordering on the pointless.

Thank you for reflecting with an opinion. I also believe that opt-in E2EE is worse than having it by default. We have precedent for E2EE chats by default and syncing those E2EE messages across devices using the latest RiotX for Matrix. I'd love to see Telegram adopt that strategy.

I use Telegram because it delights its users. When I have tried to bring friends and family to first Riot, then Signal, the experience I encountered was one of frustration, whether it was messages unexpectedly not syncing or delivering, the pain of cross-signing new devices for E2EE (RiotX), or the paucity of features. I have tried nearly every messenger that exists in an effort to seek out a usable compromise for laypeople and Telegram has been the only one to make that bar.

We use Matrix in my workplace because I can count on the employees being technical and patient enough to forgive having to input a multitude of varying passwords in succession just to get their session going.

On the Matrix side we’re removing the recovery passphrase shortly; it was a misstep.

Thank you for your work! I run my own federated homeserver that I really enjoy digging in with on the weekends. Between selfhosting email and Synapse I really feel a sense of reverent ownership over these methods of communication.

Don't get me wrong, Telegram is a very nice app, and I especially like the wide platform support. It's great at what it does, and that's many things, but unfortunately not secure-by-default communication.