Live data from Hacker News

Technology preview: Sealed sender for Signal

signal.org

111–120 of 162 posts

Re: Technology preview: Sealed sender for Signal

#111

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.

I am homeless and don't have a phone number. :(

But I want to use signal forfor cross platform messaging. Can't use Facebook without a testable phone number either now.

Re: Technology preview: Sealed sender for Signal

#112

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…

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 manage to create a social network by slowly discovering a bunch of usernames from their friends, but then they reinstall the app or get a new phone, it would be pretty unusable if that entire social graph was just... gone. It's bad enough to have to create this social graph from scratch, but to do it every time you reinstall, lose your phone, or get a new device?

The consequence is that many people advocating for this feature (or using other messengers because of it) probably don't understand what it is that they're really advocating for or getting themselves into.

Right now Signal is much more "private" than any other messenger, if you measure that by how much Signal knows about you (timestamp of account creation is the only thing iirc). By supporting a custom identifier, they would have to store your entire social graph, like other less private messengers.

Re: Technology preview: Sealed sender for Signal

#113
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…

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.

Privacy is not binary like Security isn't binary.

The type and amount of privacy a user wants and what you can realistically achieve beyond that depend on your market and threat model.

Thinking Privacy is binary is like thinking IT Security is binary; until it's 100% it doesn't exist. That kind of thinking doesn't allow thinking in incremental improvements.

Re: Technology preview: Sealed sender for Signal

#114
post #70

Earlier quoted context omitted.

This all has network effects. I have a smartphone, and I run Signal. But I run it much less, precisely because several people whom I want to interact with regularly are unable to, due to its limitation. This also means that I'm less likely to recommend it to others. And I don't think that tablets are an "edge case". I mean, seriously? We're talking about millions of devices on the market. They may not be as popular a…

It also seems to be the future. Phone numbers are how people receive phone calls, and more and more people are opting out of that in favor of instant messaging and video chat. More and more people have stopped answering their phones. Including our parents, who got sick of the scams and the robocalls. In my region, despite phone number portability, the numbers are fairly ephemeral with people switching to new ones all…

This is another aspect of inter-portability that, I think, is often ignored. Matrix is doing great on this front. But then there's another concern here, which any Matrix/Riot user would have noticed - you interaction is as secure and private as the least secure of the two (or more for groups) clients in conversation - unless of course you enforce encryption which is also something you can do in a Matrix client. But it's nowhere near the WhatsApps and Telegrams when it comes to user of use.

Re: Technology preview: Sealed sender for Signal

#115
post #70

Earlier quoted context omitted.

This all has network effects. I have a smartphone, and I run Signal. But I run it much less, precisely because several people whom I want to interact with regularly are unable to, due to its limitation. This also means that I'm less likely to recommend it to others. And I don't think that tablets are an "edge case". I mean, seriously? We're talking about millions of devices on the market. They may not be as popular a…

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.

Re: Technology preview: Sealed sender for Signal

#116
I'm confused here. It seems the identities are trivially linkable via the IP address.

The Signal servers can't determine cryptographically that the message originates from Device A. But it is certainly from device A, because this isn't a peer to peer protocol.

It seems to me like what you'd need to make this work is some sort of intermediate layer, a bit like onion routing, that would have messages arrive at the Signal servers without basically giving everything away in the source IP field.

With general use of NAT there's a N-to-one mapping of identities to IP addresses, sure, but this seems to be technically true whilst in many cases completely erasing any benefit of this entirely.

Re: Technology preview: Sealed sender for Signal

#117
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…

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…

Part of being a solution that aims to make secure messaging usable for everyone is that the UX needs to be there.

By way of analogy: In every HN thread about Firefox there are dozens of comments by people who say that they just couldn't use Firefox because page loads are so awfully slow.

Consider that for a second: HN readers are willing to give their entire browsing history to Google in return for at the very worst a few dozen microseconds of load time saved.

The equivalent here is, that for non telephone number identifiers you have to create a whole UI for actually adding/discovering people. That's the equivalent of the few microseconds. You can argue that it's not a big deal, but it's exactly the type of friction in the ecosystem that hinders adoption ("I already have your phone number, why do I need another number to contact you? Know what, I'll just send you an SMS.").

And it's exactly the type of UI/UX problem that prevented encrypted email adoption ("Download a new program and some sort of key for you? I'll just send you an email directly, I'll figure this out later...").

Re: Technology preview: Sealed sender for Signal

#118
post #75

Earlier quoted context omitted.

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 si…

Although PGP/GPG as end user applications didn't go anywhere, the functionality is widely used.

Every time I get Fedora updates they're GPG signed, if you compromise a mirror and shove crap there it isn't signed and so the system will just try a different mirror. If you try compromising the metadata, that's signed too.

Instead of my bazillion of web site passwords being "in the Clown" as seems to be the popular style these days, or in some fool's hand-built database, they're in Donenfeld's password store, which uses GPG to encrypt text files with passwords in them.

Re: Technology preview: Sealed sender for Signal

#119
post #74
post #52

Earlier quoted context omitted.

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 befo…

What do you mean here by "address" ? And indeed "username" ?

Suppose Alice is asking about Indian and Bob replies that it sounds good.

A passive attacker sees TCP/IP packets between Alice's IP address and Signal's and between Bob's IP address and Signal's. They get no other information from this beyond that Alice and Bob use Signal (and perhaps not even that if Signal shares IP addresses with other services)

The Sealed Sender feature makes no difference in that layer

If an attacker has control of Signal's servers (or perhaps Signal's server admins are secretly bad guys) ordinarily they would be able to see the sender and recipient of every message.

With Sealed Sender, the servers don't know the Sender any more, only that the Sender seems to be someone permitted to send messages to this recipient.

You could try to correlate IP addresses to Signal users, but you have absolutely no guarantee that they're correlated, much less that there's a nice 1:1 correspondence.

In a mundane example, Alice proposes Indian food then leaves her office, her phone disconnects from WiFi and goes to a 3G network. The reply from Bob is picked up by Alice using a completely different IP address, because she isn't in the office any more.

Re: Technology preview: Sealed sender for Signal

#120
post #107
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…

>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...
Post reply on HN