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

121–130 of 162 posts

Re: Technology preview: Sealed sender for Signal

#121

Post by simias »

icebraining wrote: post #120
simias wrote: post #107

Earlier quoted context omitted.

>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 the kind of protocol change you can make when you control all the mainstream clients, and that would be an absolute nightmare for a protocol where you didn't. Personally I would be fine if they were in control of th…

Isn't that what the libsignal-protocol-* repositories are about? https://github.com/signalapp?utf8=%E2%9C%93&q=libsignal-prot...

Ah, interesting. I assumed that this didn't exist because I had never heard of it and as far as I know there are no third party signal clients out there. Is it just that nobody bothered to do it or is there a catch?

Frankly if it's just that nobody did it I might seriously consider adding Rust bindings and making a basic IRC gateway or something like that.

Re: Technology preview: Sealed sender for Signal

#122

Post by hardwarescope »

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!

If I remember correctly, as a consequence, they store all of your unencrypted contacts on their server, or at least all of your unencrypted Wire contacts on their server. Unlike Signal, which stores nothing about you other than the date your account was created. That may be the "complexity" you're not understanding, in this case.

Re: Technology preview: Sealed sender for Signal

#123

Post by hardwarescope »

walterbell wrote: post #17
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.

Wire supports email-only registration at https://app.wire.com (from a desktop web browser). The account can then be used to login from mobile or web. This approach enables "easy" mode for casual users who prefer phone number registration, while supporting additional privacy for others.

As a consequence of this choice, they store all of your unencrypted contacts (or unencrypted Wire contacts) on their servers. I don't think that's "additional privacy," compared to what Signal stores (nothing, it appears). Or it is at least not as simple a question as you make it seem.

Re: Technology preview: Sealed sender for Signal

#124

Post by eadmund »

tptacek wrote: post #88
mintplant wrote: post #82

Earlier quoted context omitted.

I see you explaining and re-explaining the same point throughout this thread: "ordinary users" are used to using phone numbers as identifiers in the messaging apps Signal is trying to replace. That's an answer to the question: why does Signal default to a phone number-based social graph? What it doesn't answer is: why can't Signal also provide an option to add a contact using something other than a phone number? Bold…

I don't understand the complexity or see the blind spot. Your use case is not a priority for them right now.

There's really not much extra complexity: instead of usernames which are of the form tel:+31123456789, one could also support usernames of the form mailto:foo@example.com, urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6, along which canonicalisers & verifiers for each (the last might be some sort of internal Signal-scoped hash — I dunno).

Yes, it is some, but it's not a ton.

Re: Technology preview: Sealed sender for Signal

#125

Post by eadmund »

balladeer wrote: post #115
glenneroo wrote: post #108

Earlier quoted context omitted.

Why don't you use it for SMS? At most 20% of my contacts use Signal, but for the rest of my non-Signal contacts I still use it to communicate using normal SMS/MMS without any hiccups, the only thing being the lack of encryption. I also personally prefer it to the IMO horrible default SMS apps provided by multiple vendors (including stock Android, at least up to V7).

People might be used to other SMS apps (better feature, familiarity etc) and Signal can't be used as an SMS app on iOS.

> Signal can't be used as an SMS app on iOS.

Sounds like a broken smartphone platform to me.

I'm not being glib: I really do believe that I should be easily able to replace any app on my phone. Android, while imperfect, is closer to that goal than is iOS, and so I use it, and recommend it to others.

Re: Technology preview: Sealed sender for Signal

#126

Post by eadmund »

tptacek wrote: post #26
geofft wrote: post #13

I'm not sure I understand the feature. It protects the sender's identity from their servers , or from the recipient ? What's the use case / threat model? I think it prevents their servers from correlating my identity and my IP address etc., but since I want replies and I'm asking the server about replies, doesn't that operation tell the server what my identity is anyway? (There are some comments here talking about an…

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

I don't think that's actually true. Reading their blog entry at https://signal.org/blog/sealed-sender/, I believe that they can still correlate IP addresses to phone numbers, and since they see which IP address sent a message and to which IP address it was delivered, they know who's talking to whom (or can know, and can be compelled to know, record & share).

It's also odd that the tokens are 96 bits. Very odd, really.

Re: Technology preview: Sealed sender for Signal

#127

Post by walterbell »

hardwarescope wrote: post #123
walterbell wrote: post #17

Earlier quoted context omitted.

Wire supports email-only registration at https://app.wire.com (from a desktop web browser). The account can then be used to login from mobile or web. This approach enables "easy" mode for casual users who prefer phone number registration, while supporting additional privacy for others.

As a consequence of this choice, they store all of your unencrypted contacts (or unencrypted Wire contacts) on their servers. I don't think that's "additional privacy," compared to what Signal stores (nothing, it appears). Or it is at least not as simple a question as you make it seem.

Would appreciate a reference on this, if you have one. I don't know about the general case, but none of my mobile contacts are shared with Wire's server and most of my Wire contacts have pseudonym handles/names.

If IETF efforts to standardize E2E messaging protocols can lead to interoperability between clients, we can reduce the influence of social network inertia on messenger client selection.

Re: Technology preview: Sealed sender for Signal

#128

Post by enimodas »

hardwarescope wrote: post #112
balladeer wrote: post #93

Earlier quoted context omitted.

Or maybe let a user sign up with a phone number (as it happens today) but create a unique ID - a user selected username (Telegram, Wire) or auto-generated PIN (BBM) (and then remove any link to that phone number right at the sign up iff the user wants it - it can be hidden in advanced setting UI wise - A). Use the phone number just to prevent spam (though it can't prevent one user having multiple accounts using the s…

I think this issue is more complicated than people realize. There are really only three options here: 1. Use the device's address book (phone numbers). 2. Use Facebook Connect (FB id). 3. Store the entire social graph on the server (custom identifiers). I think #3 is what every messenger that offers non-phone identifiers does (Snapchat, Twitter, Telegram, Wire, Viber, etc). The reason is simple: if someone does manag…

It can be stored on the server, and encrypted by the users' private key. Like a message to himself.

Re: Technology preview: Sealed sender for Signal

#129

Post by cyphar »

simias wrote: post #121
icebraining wrote: post #120

Earlier quoted context omitted.

Isn't that what the libsignal-protocol-* repositories are about? https://github.com/signalapp?utf8=%E2%9C%93&q=libsignal-prot...

Ah, interesting. I assumed that this didn't exist because I had never heard of it and as far as I know there are no third party signal clients out there. Is it just that nobody bothered to do it or is there a catch? Frankly if it's just that nobody did it I might seriously consider adding Rust bindings and making a basic IRC gateway or something like that.

Moxie was against people publishing the official Signal app (rebuilt) on F-Droid specifically because he was against the idea that ordinary users would be exposed to a minor fork of Signal (which would then require them to co-ordinate changes between the two forks).

I would be very shocked if he would be any nicer about someone writing an entirely new app from scratch that uses their protocol and inter-operates with their servers. Because then Signal on F-Droid wouldn't have been an issue.

Re: Technology preview: Sealed sender for Signal

#130

Post by cyphar »

tptacek wrote: post #98
jake_the_third wrote: post #96

Earlier quoted context omitted.

> A small but vocal minority of Signal's user base wants non-phone-number identification. Have you done a survey before arriving to this conclusion. If so, I'd love to take a look at it, if possible. Otherwise, I can't see how you can make this assertion; everything can be dismissed as a "small but vocal minority". As a previous signal user, I stopped using signal because I discovered this issue.

As a previous user of a program that uses phone numbers as identification you stopped using Signal because you discovered that it uses phone numbers as identification?

Here's my data point: I used to use Signal but then stopped using a smart-phone for a year, and I very quickly discovered that unlike other chat systems (like Matrix) Signal is so tied to you having a smart-phone that you can't use any desktop communication method. The Chrome App pairs with your phone rather than registering a new device.

(Also, it's kinda funny that Signal has reimplemented the iMessage problem -- you have to unregister your phone number on your website so people can SMS you again rather than continuously sending you Signal messages unintentionally.)

(There are also other problems that have bubbled up in Signal in the past year since I stopped using it -- I've heard there's an auto-backup process that takes more than an hour and makes your phone unusable and you cannot change when it happens.)

Post reply on HN