Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twilio incident: What Signal users need to know

support.signal.org

Post reply on HN
Print view View original

141–150 of 512 posts

Re: Twilio incident: What Signal users need to know

#141

Post by melgafin »

daneel_w wrote: post #118
niel wrote: post #107

Earlier quoted context omitted.

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.

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.

Re: Twilio incident: What Signal users need to know

#142

Post by bubblethink »

mikece wrote: post #28
giancarlostoro wrote: post #19

Earlier quoted context omitted.

Do they offer numbers you can use that way or do you just use their APIs with a minimal app?

I spin up a number and verify it can receive SMS (which it forwards to me via email). Since I need receive-only, this is fine. No need to futz with APIs or apps.

A lot of banks refuse to send SMSes to voip numbers. Google voice runs into this, and presumably twilio too.

Re: Twilio incident: What Signal users need to know

#143

Post by sneak »

autoexec wrote: post #137
godelski wrote: post #82

Earlier quoted context omitted.

I think they are. I just also think the problem is a lot harder than people give it credit for. If they just go with a standard username (as in some form of a database lookup) then I'll be upset. But I'll be upset because this effectively doesn't solve any issue, and introduces others that have big privacy impacts and requires Signal to be a trusted source (which is antithetical to Signal's proposed mission). I do wi…

> I do wish Signal would be more transparent though. You mean like updating their privacy policy to explain that they are keeping sensitive user data in the cloud? They refuse. There are people in this very discussion who are (or were at least) unaware that Signal is collecting and permanently storing user data on their servers. Signal's communication on what they're collecting and how has been a total joke. I cannot…

Please stop spreading objectively inaccurate FUD in the thread.

Re: Twilio incident: What Signal users need to know

#144

Post by godelski »

notpushkin wrote: post #119
godelski wrote: post #82

Earlier quoted context omitted.

I think they are. I just also think the problem is a lot harder than people give it credit for. If they just go with a standard username (as in some form of a database lookup) then I'll be upset. But I'll be upset because this effectively doesn't solve any issue, and introduces others that have big privacy impacts and requires Signal to be a trusted source (which is antithetical to Signal's proposed mission). I do wi…

Signal is a trusted source already – you trust them telling you which number is which user.

Sorry, let me clarify. We should trust Signal as little as possible. That's how the design should work. Zero trust is very hard to create but let's minimize it.

Opening up usernames (in the conventional sense) you will end up needing to verify and act as an arbiter. This is due to the fact that certain usernames have real world meaning behind them and you don't want to create an ecosystem where it is really easy to honeypot whistleblowing platforms (how do you ensure that CNN gets {CNN, CNN-News, CNNNews, etc}?). They've suggested that this might be the case given that the "Notes to self" and "Signal" users are verified with a blue checkmark. The issue is that verifying users not only makes Signal a more trusted platform but the act of verification requires obtaining more information about the user. It also creates special users. All things I'm very against. I'd rather hand out my phone number than have Signal collecting this type of information. So yeah, it isn't completely trustless, but I certainly don't want to move in the direction of requiring more trust.

Re: Twilio incident: What Signal users need to know

#145

Post by fezfight »

mbrubeck wrote: post #106
A4ET8a8uTh0 wrote: post #70

Earlier quoted context omitted.

I will admit that this requirement always confused me. What is there to benefit from by requiring it?

It means that Signal doesn't need you to create or upload a list of your contacts; it uses the existing contact list from your phone. This also lets you use Signal to replace the default text messaging app on Android, automatically upgrading conversations to be encrypted when possible. This in turn means that just using Signal to communicate with someone becomes a normal, everyday activity, and less of a sign of susp…

I think the problem is that it's a requirement, not a feature you can choose to use. I'd be more inclined to use Signal if I choose to use only a user/pass. Just need a block function.

Re: Twilio incident: What Signal users need to know

#146

Post by 0x457 »

registeredcorn wrote: post #59
CogitoCogito wrote: post #49

Earlier quoted context omitted.

So if you have a phone number that someone else used to create an account, you can't use Signal?

Close, but not quite. You see, if the other person didn't use registration lock, now you've got access to complete strangers account. Problem solved!

Not exactly. Registering again will make an entirely new identity with different key pair. The new phone holder won't get access to your contacts or your message history. I believe your contacts will also know about signature change as well.

Re: Twilio incident: What Signal users need to know

#147

Post by lxgr »

ycombinator_acc wrote: post #80
ryukafalz wrote: post #45

Earlier quoted context omitted.

Your account is tied to your phone number so pretty sure that’s the case, yep!

That sounds horrible. Would I be SoL even if I had ticked "Registration Lock" prior to that?

Apparently as long as you use Signal at least once every 7 days from a linked device, you should be good: https://support.signal.org/hc/en-us/articles/360007059792-Si...

Still, given that your number is used as a primary identifier, I'd avoid using it in that way for an extended amount of time. Among other things, I'm not sure if it's possible to re-register using just your phone number and PIN (but not access to SMS-OTPs on the associated phone number) in case you lose your own device, for example.

Re: Twilio incident: What Signal users need to know

#148

Post by dcow »

uncomputation wrote: post #47

Yes, Signal’s phone number requirement is bad. But, given that, the fact that they don’t store any messages on their side and everything is client side is still a huge benefit over a lot of other apps and still a huge step forward for privacy! Criticism is definitely important but I just wanted to put that out there that all things considered, Signal is still very much a good thing.

I wouldn't even call it bad. In may ways it's good, actually. It's good because it allows signal to build a product that is relevant and usable. Phone numbers only connect people and are a bridge to allow all the perfect crypto to do the legwork. The knee jerk "phone bad" reaction is understandable, sure. But I don't think it's warranted for Signal. Signal would look like Keybase without phone numbers. Keybase (or their key exchange UX, at least) is great. But it's not the same product.

Re: Twilio incident: What Signal users need to know

#149

Post by fezfight »

dcow wrote: post #138
panick21_ wrote: post #124

Earlier quoted context omitted.

While that is nice, I see no reason to require that. Some people just don't care about that feature.

What is this future UX you're imagining? How does the future solve the contacts book/short identifiers problem?

Just like this website. Usernames. Easy peasy.
Post reply on HN