Twilio incident: What Signal users need to know • Hacker News Board

Re: Twilio incident: What Signal users need to know

#501

Post by SnowVivid » Wed, Aug 17, 2022, 8:19 AM UTC

mpol wrote: post #391

jorvi wrote: post #346

Earlier quoted context omitted.

> This info gives us an interesting opportunity to estimate the rate at which Signal is adding new users. They've been very tight-lipped (understandably) about their usage stats but anecdotally they seem to be an increasingly common presence on my friends' phones, even the non-techies. I am assuming US or Germany. I can't remember which thing it was exactly but there was a huge privacy scare in the US at some point w…

You might be in a different bubble than I am in :) Netherlands here. 80 contacts on my phone. 20 on Signal, of which 10 are quite normal people. Almost all 80 are on Whatsapp. No idea about Telegram.

Belgium here. I don't have WhatsApp, Messenger, or any social network account.

I only use Signal. Most of my contacts are on Signal (meaning people from work or close friends/family). I would say ballpark 85%+. My shrink and MD are on Signal. I'm lucky enough to work for an organisation that promote and emphasis privacy and security. I'm also quite a good evangelist to my family and few friends ;-)

Once I step out of that circle/bubble of people, I realize how peculiar my situation is, mind you. I have 2 teenagers and sometimes I have to communicate with "regular" people. EDIT : in that case, I use regular email, SMS or phone calls. WhatsApp is widely used in Belgium, as is Messenger. My wife tried to remove WhatsApp at some point, but that made her social life too difficult.

Re: Twilio incident: What Signal users need to know

#502

Post by irfwashere » Wed, Aug 17, 2022, 10:58 AM UTC

rvz wrote: post #256

dcow wrote: post #200

Earlier quoted context omitted.

I am aware. For one it still works just as well is it ever has, the Zoom acquisition didn't change anything there. So if you care about features, there shouldn't be any problem. For sure it seems to be in maintenance mode, but nothing they were doing of late with Lumens was that exciting anyway (trying to become a crypto wallet like everyone and their mothers). I would pay $/mo for a Keybase reboot with the goal of b…

Yeah I'd rather use Keybase which has username / password than the disaster that Signal is right now. Especially when you have both Twitter and Twilio breaches, SS7 attacks, SIM swapping attacks, etc. Keybase still works and for a simple messaging app does the job better than Signal or any other messaging app that requires a phone number. This is a total disaster. > but nothing they were doing of late with Lumens was…

Why doesn't anyone ever consider XMPP using one of the many clients like gajim, conversations, etc.? It's got all of the encryption features anyone would want but has zero mentions as a secure messaging option.

Re: Twilio incident: What Signal users need to know

#503

Post by rt4mn » Wed, Aug 17, 2022, 5:02 PM UTC

thaumasiotes wrote: post #95

eitland wrote: post #74

Earlier quoted context omitted.

You can trivially create as many emails as you want, anonymously and for free. In many countries, registering phone numbers anonymously is illegal and/or impossible.

> You can trivially create as many emails as you want, anonymously and for free. Where? Gmail and hotmail both don't allow this.

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.

Re: Twilio incident: What Signal users need to know

#504

Post by spullara » Wed, Aug 17, 2022, 6:29 PM UTC

xorcist wrote: post #116

spullara wrote: post #54

Earlier quoted context omitted.

People don't have email addresses in their contact lists because all their email contacts are stored on Google servers.

Having the ability to identify by other strings than "phone number" wouldn't take away any functionality, just add it. It would be possible to communicate with devices that have email but not phone numbers (children without SIM cards, for example). But this is all moot because phone numbers aren't just opaque binary strings. They are more useful than other forms of identification.

That isn't why Signal uses phone numbers. It uses phone numbers because users have a local list of phone numbers they communicate with and Signal can use that to determine if people you communicate with are on Signal. If there was a reliable local list of email addresses they could use that but most people use cloud email now and don't have their email addresses they communicate with on their device.

Re: Twilio incident: What Signal users need to know

#505

Post by kortilla » Wed, Aug 17, 2022, 7:20 PM UTC

dcow wrote: post #488

dcow wrote: post #390

Earlier quoted context omitted.

1. I'm not angry at all. 2. Let me make this clear: an imperative component of signal's product is that the identifier used is verifiable , and that the only thing they store for a period of time is that users in-fact did verify their number. Everyone arguing for typed in identifiers is missing this point. That wouldn't be Signal. That's the core of what I'm saying. That would be something else where people claim sho…

Following up on: > Nobody arguing for non-phone-number short identifiers has proposed a solution for how you verify them and manage them that doesn't change Signal's fundamental threat model and information architecture, which, at the end of the day, is what many users are bought into. So it turns out Signal is building support for usernames and their solution is indeed rather involved. In order to achieve usernames…

“Using phone numbers is what makes signal signal and everyone else is stupid who doesn’t see that!”

“Oh, signal is relaxing that constraint. I was still right and signal employees are wrong for doing this.”

Re: Twilio incident: What Signal users need to know

#506

Post by dcow » Thu, Aug 18, 2022, 2:51 AM UTC

stormbrew wrote: post #496

dcow wrote: post #453

Earlier quoted context omitted.

I've been reading up on the state of things. So Signal actually is working to remove the phone number requirement: https://twitter.com/moxie/status/1281353114063257600?s=20&t=... They've been working on it for years . Their solution is that they have to take client-side ownership of your contacts list, keep it associated with your "account" and sync it across your devices so that when you correspond with someone by u…

> in their effort to solve a problem that only exists on HN I don't understand why your takeaway from the fact that they're implementing it is that the people saying they want or need it are irrational and only exist on hn instead of "hmm, maybe I'm wrong and this is a legitimate feature request". Anyways, let me assure you that the people who get "reamed" are in fact anyone who even causally mentions they want this…

I'd consider the way you're asking for the feature. There was definitely an air of "this is such a simple feature why can't I just have it it should be no trouble for everyone involved it's just a username". I think if people asking for this feature were to spitball through it and acknowledge the tradeoffs rather than incessantly repeat how uncompromising they are in their need for usernames and their need for Signal to have them yesterday, the conversation wouldn't seem so volatile. I actually wasn't trying to dive in and sling mud. I see this conversation all the time on HN and, coming across it again, wanted to suggest that maybe another product with usernames would work better for these people since literally every time Signal comes up on HN the peanut gallery shoots off with tired smears and entitled quips about how Signal users phone numbers.

The strong response you encounter is people trying to communicate that it isn't that simple for them. That it means enough of a shift in Signal's model that they're really worried about the change to the product if Signal implemented it, not least because it changes the very thing that drew them to the product in the first place. And unfortunately, it seems the worries are not unfounded. I genuinely don't think many of the people asking for usernames would want them if the proposition was clear: "you can have them but you have to trust us with your contacts book and personal information". It's the catch22: in order to have the privacy of a username, you must give up the privacy you'd win. For some people, they trust Signal with that responsibility more than their carrier (like a VPN) and it's a good tradeoff.

Me? What was compelling about Signal is that it was my contacts book and encrypted communication. No accounts/profiles, no passwords, no proprietary software, no invasive product analytics, just a global DB associating phone numbers with pubkeys. That was my pipe dream but I also acknowledge I'm not the center of the world either: in the same way you begrudgingly use Signal with a phone number, it's also not the end of the world for me if we have yet another company out there where I need to maintain a profile and stick a password in my password manager and login periodically. But sadly, if Signal gets to that point, it ultimately means the "Signal experiment" portion of the product's life will have come to an end. didn't do what everyone else on the internet did and send off all your data to their servers the minute you opened their app.

Re: Twilio incident: What Signal users need to know

#507

Post by dcow » Thu, Aug 18, 2022, 3:03 AM UTC

kortilla wrote: post #505

dcow wrote: post #488

Earlier quoted context omitted.

Following up on: > Nobody arguing for non-phone-number short identifiers has proposed a solution for how you verify them and manage them that doesn't change Signal's fundamental threat model and information architecture, which, at the end of the day, is what many users are bought into. So it turns out Signal is building support for usernames and their solution is indeed rather involved. In order to achieve usernames…

“Using phone numbers is what makes signal signal and everyone else is stupid who doesn’t see that!” “Oh, signal is relaxing that constraint. I was still right and signal employees are wrong for doing this.”

I think you're missing the part where they are in the trying to figure out how to relax that constraint phase (they have not yet) and having trouble in paradise.

They've run into all the issues and nuances elucidated in this thread. They have been receiving pretty intense feedback from people who have stopped using their product because of the concessions made. They've clammed up in response and are losing even more people because they are not clearly articulating the changes to their users (many of whom would be fine with it if communicated transparently and respectfully). They have people who desperately want usernames but also not if it means what Signal is proposing and admit "okay, you heard my request and tried, but hmm let's not do that I don't like this PIN UX and it's not what I wanted when I said I want usernames". And they even saw their product forked the minute it became clear what they were doing: https://getsession.org (blogs start Dec, 2019 which is around the time Signal started messing around with secure value recovery stuff, at least publicly).

Re: Twilio incident: What Signal users need to know

#508

Post by dcow » Thu, Aug 18, 2022, 3:14 AM UTC

panick21_ wrote: post #500

dcow wrote: post #495

Earlier quoted context omitted.

Claiming that the solution is simple is the problem. Signal actually has been trying to add usernames for years. It involves an account, contacts book, trusting Signal, trusting Intel, SGX remote attestation, Raft, and passpins. They are getting reamed for it because it's not really possible to treat a 4 digit pin as a strong password but they're trying to do it anyway. It inverts the whole value prop of Signal on it…

Again, I'm not talking about usernames, I'm talking about public keys.

Well you should try: https://getsession.org. It's a fork of Signal with pubkeys instead of phone numbers.

Re: Twilio incident: What Signal users need to know

#509

Post by [deleted] » Thu, Aug 18, 2022, 7:39 AM UTC

dcow wrote: post #506

stormbrew wrote: post #496

Earlier quoted context omitted.

> in their effort to solve a problem that only exists on HN I don't understand why your takeaway from the fact that they're implementing it is that the people saying they want or need it are irrational and only exist on hn instead of "hmm, maybe I'm wrong and this is a legitimate feature request". Anyways, let me assure you that the people who get "reamed" are in fact anyone who even causally mentions they want this…

I'd consider the way you're asking for the feature. There was definitely an air of "this is such a simple feature why can't I just have it it should be no trouble for everyone involved it's just a username". I think if people asking for this feature were to spitball through it and acknowledge the tradeoffs rather than incessantly repeat how uncompromising they are in their need for usernames and their need for Signal…

[deleted]

Re: Twilio incident: What Signal users need to know

#510

Post by nobody9999 » Thu, Aug 18, 2022, 8:33 AM UTC

bscphil wrote: post #497

nobody9999 wrote: post #421

Earlier quoted context omitted.

>I mean that's really bad, right? Supposedly Signal is the go-to alternative to doing things the hard way (e.g. GPG over email), but apparently it's just not good enough for those with the highest security needs. Is it? If that's what you got from my comment, then I certainly didn't communicate my thoughts clearly. Signal is great for what it is. And that's as a centralized encrypted messaging platform that's easy to…

> The whole "telephone number as identifier" bit, and the network discovery it provides, is the primary reason Signal has had the level of adoption it has. I agree. Signal absolutely should not abandon this. Rather, it should add other user identifiers that can be used alongside phone numbers. > Storing anything on systems accessible to the Internet is risky. Plain text is much worse than encrypted blobs, but there's…

>I strongly disagree. A lot of critical work has been done with email + PGP, and that's about as leaky (in terms of metadata) as it gets. Obviously there are use cases where you do worry about this, but "storing data on the Internet" is not as such always a problem for those who need the highest security guarantees. Signal adopting alternative user identifiers would open it to use in some of these extreme cases, but would not (of course) make it usable in every situation - and that's okay.

I'm old school. If it's connected to the Internet, eventually it will be compromised.

Yes, strong encryption can (and does) make data compromise immensely more difficult in terms of time and resources (much longer than our star will exist -- about five billion years -- which isn't really that big a deal, since the Earth will be uninhabitable in a billion years or so), but once that centralized server(s) is compromised, all bets are off.

I don't disagree that strong encryption is a valuable tool for maintaining data privacy and integrity, but it absolutely does not reduce the risk to zero.