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

Technology preview: Sealed sender for Signal

signal.org

Post reply on HN
Print view View original

71–80 of 162 posts

Re: Technology preview: Sealed sender for Signal

#71

Post by Sir_Cmpwn »

ardy42 wrote: post #69
Sir_Cmpwn wrote: post #27

Earlier quoted context omitted.

No, it's not. By requiring a phone number, Signal does not defend privacy. This is a binary question, there's not a grey area here. It doesn't matter that they're building a social network, or anything else. What matters is that it's not private so long as they require a phone number.

> No, it's not. By requiring a phone number, Signal does not defend privacy. This is a binary question, there's not a grey area here. It doesn't matter that they're building a social network, or anything else. What matters is that it's not private so long as they require a phone number. I'm not so sure. A lot of the objections to Signal using phone numbers seem similar to objecting to SSL/TLS because it's not Tor.

Nice comparison, that gives me some pause. I think that Signal is better positioned to fix the shortcomings in their system than the rest of the world is to fix the shortcomings of SSL/TLS, though.

Re: Technology preview: Sealed sender for Signal

#72

Post by tptacek »

eadmund wrote: post #65
tptacek wrote: post #29

Earlier quoted context omitted.

I'm not sure what was unclear about my summary of what Signal is doing. Here, let me put it differently for you: Signal's goal is to make all the messaging in the world that currently uses phone numbers as identifiers --- which, by a long ways, is most messaging in the world --- cryptographically secure. Hope that helps. You are welcome to have and to advocate for different goals. Please don't pretend your goals are…

> Signal's goal is to make all the messaging in the world that currently uses phone numbers as identifiers --- which, by a long ways, is most messaging in the world --- cryptographically secure. That goal is fundamentally broken, though, because phone numbers aren’t cryptographically secure . One can use any exploit which allows one to take over a phone number to take over someone’s Signal identity. Yes, all of the t…

If key change alerts don't generally work, we have bigger problems than phone numbers.

Re: Technology preview: Sealed sender for Signal

#73

Post by jlund »

eadmund wrote: post #65
tptacek wrote: post #29

Earlier quoted context omitted.

I'm not sure what was unclear about my summary of what Signal is doing. Here, let me put it differently for you: Signal's goal is to make all the messaging in the world that currently uses phone numbers as identifiers --- which, by a long ways, is most messaging in the world --- cryptographically secure. Hope that helps. You are welcome to have and to advocate for different goals. Please don't pretend your goals are…

> Signal's goal is to make all the messaging in the world that currently uses phone numbers as identifiers --- which, by a long ways, is most messaging in the world --- cryptographically secure. That goal is fundamentally broken, though, because phone numbers aren’t cryptographically secure . One can use any exploit which allows one to take over a phone number to take over someone’s Signal identity. Yes, all of the t…

You can read more about the Registration Lock feature here:

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

Re: Technology preview: Sealed sender for Signal

#74

Post by Spivak »

geofft wrote: post #52
tptacek wrote: post #26

Earlier quoted context omitted.

It prevents their servers from easily tracking (and, importantly, logging) who sent which messages to whom.

Oh, I see - it effectively hides the fact that a conversation occurred between two participants from their servers. They know that I'm at my IP, they know that you're at your IP, and they know that we're both sending messages, but this feature prevents them from knowing whether we're sending messages to each other.

It seems like this is backwards: you have an address and username, they have an address and username. They see the source address and destination username.

So suppose an attacker sees two packets:

Encrypted("Indian for dinner?"): Their username, your address.

Encrypted("Sure, sounds good."): Your username, their address.

From this they could be reasonably sure you two are talking but it's less data than they had before and now that attacker needs to either know you're using the source address or see both messages to get the full picture.

Re: Technology preview: Sealed sender for Signal

#75

Post by TheDong »

foolfoolz wrote: post #58
tptacek wrote: post #50

Earlier quoted context omitted.

The PGP ecosystem is a pretty great example of what happens when you target unbounded interoperability.

and it’s adoption rate is a great example of what that does to user experience

Are you trying to paint PGP in a positive light with this comment?

Putting "user experience" anywhere near PGP/GPG makes most gpg users immediately gag.

gpg offered a solution to encrypting email. No one uses it because it's unusable.

gpg offered a solution to releasing signatures beside releases with the idea that users could verify them through the web of trust. The exactly zero people who notice when the person signing changes or a technical error results in an invalid signature shows no one actually verifies signatures.

XMPP, when it needed e2e encryption, could not use pgp/gpg because their effectively unusable in what it's doing.

gpg's adoption rate is not great, and any adoption it has is entirely in-spite of its bad UX, not because of it.

Re: Technology preview: Sealed sender for Signal

#76

Post by StudentStuff »

tptacek wrote: post #60
StudentStuff wrote: post #54

Earlier quoted context omitted.

I'm not looking to argue with you, just pointing out the current state of affairs wrt why so many privacy minded, tech aware folks either won't use Signal or choose to move conversations off it as quickly as possible. The reasons for avoiding Signal (metadata leakage, mandatory phone number usage, questionable 3rd party dependencies, etc) are valid, despite how I often argue to the contrary in favor of getting as man…

Of those issues, I believe only mandatory phone numbers are valid, for what it's worth. And I'm fine with mandatory phone numbers; there are other options for people who have a problem with that.

You obviously have a different opinion on what a standard threat model is then...

Re: Technology preview: Sealed sender for Signal

#77

Post by mbesto »

ikfmpwdsoz wrote: post #28
tptacek wrote: post #24

Earlier quoted context omitted.

This is the "Go y u no generics" of secure messaging. The answer is always the same: Phone numbers bootstrap a workable social network for ordinary users. Signal's goal is to transform all ordinary messaging into secure messaging. Not elite secure messaging. All messaging . The most popular messaging application in the world uses phone numbers for identifiers (as, obviously, does SMS). That's the goal they've set for…

But... Wire has both! With generics, you introduce complexity into the language that everyone has to understand, but that's obviously not true when it comes to having accounts that aren't tied to phone numbers!

Digression: anyone who's used Wire. How is there video/audio and more importantly conferencing software. Any good?

Re: Technology preview: Sealed sender for Signal

#78

Post by tgsovlerkhgsel »

upofadown wrote: post #64
tptacek wrote: post #23

Two observations: 1. You should look into what other messengers do with sender/receiver pairs information. One very popular competing messenger logs pairs permanently, serverside, in order to make UI features work. 2. One of the least popular attributes of Signal (on Hacker News, at least) is its lack of federation and ability to interoperate with third-party clients. This feature is a pretty crystalline example of t…

Yes you can do stuff more easily if you control all parts of the network. That doesn't mean we have to give up on standards based messaging just because it is harder. In the long run silo based systems are more work because you have to reinvent everything every time you create the next entirely incompatible system. If that system doesn't catch on then you have to reinvent everything again and again until you get luck…

On the other hand, Signal works. Messages get delivered and phone calls get established.

All the open/interoperable solutions that I found were sufficiently broken that I no longer use them, since it felt like I was spending more time debugging them than actually communicating.

Re: Technology preview: Sealed sender for Signal

#79

Post by somebodythere »

tptacek wrote: post #24
amaccuish wrote: post #3

Here's an idea, Signal, how about removing the requirement that everything be tied to phone numbers? BBM back in the day worked great with their unique "PINs", that could be shared by QR code, and I could reject an "add" request.

This is the "Go y u no generics" of secure messaging. The answer is always the same: Phone numbers bootstrap a workable social network for ordinary users. Signal's goal is to transform all ordinary messaging into secure messaging. Not elite secure messaging. All messaging . The most popular messaging application in the world uses phone numbers for identifiers (as, obviously, does SMS). That's the goal they've set for…

Opt-in typing indicators and read receipts would go a long way towards that goal, I think.

Re: Technology preview: Sealed sender for Signal

#80

Post by tony101 »

somebodythere wrote: post #79
tptacek wrote: post #24

Earlier quoted context omitted.

This is the "Go y u no generics" of secure messaging. The answer is always the same: Phone numbers bootstrap a workable social network for ordinary users. Signal's goal is to transform all ordinary messaging into secure messaging. Not elite secure messaging. All messaging . The most popular messaging application in the world uses phone numbers for identifiers (as, obviously, does SMS). That's the goal they've set for…

Opt-in typing indicators and read receipts would go a long way towards that goal, I think.

Signal has optional read receipts.

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

Post reply on HN