8 ms·

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 a

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, italics, and double-underline on the also. Is it simply a question of finite developer time? I have multiple specific segments of the population in mind who would benefit greatly from the secure private messaging Signal provides but for whom exchanging phone numbers is a total non-starter. "Ordinary", non-technical, non-"elite secure" people. I hate the framing of this problem as some sort of niche techie elitism. That's a dodge that reflects a social blind spot of its own.

tptacek 8y ago
I don't understand the complexity or see the blind spot. Your use case is not a priority for them right now.
- mintplant 8y ago
  I'll re-rephrase. Is it a problem of: (1) allocating developer time and organizational priorities; or, (2) a technical incompatibility with Signal's existing, phone number-based model? Based on your response I'm inferring (1), but I'm frustrated that this is never directly answered when the topic comes up.
  - tptacek 8y ago
    It's more (1) than (2), is what I think, although I think non-phone authentication is probably trickier than we think it is and so the two categories bleed a bit. I seriously don't understand what people expect in these discussions, though. The situation is straightforward. A small but vocal minority of Signal's user base wants non-phone-number identification. Signal hasn't prioritized that feature. Put up, or use a different messenger. How is this complicated? Don't pick horrible messengers, like ones where encryption isn't enabled by default, or doesn't even exist for group messages, or isn't built on a protocol anyone understands or has reviewed. But even with that constraint, you have options.
    - jake_the_third 8y ago
      > 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.
      - tptacek 8y ago
        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?
        cyphar 8y ago
        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.)
        jake_the_third 8y ago
        Yes. More precisely, I stopped when I discovered that I couldn't decouple the signal user from my phone number. More importantly, I'm still very interested in seeing the data behind your vocal-minority assertion.
        pvg 8y ago
        The survey data you are looking for is WhatsApp.
- eadmund 8y ago
  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.
- Terretta 8y ago
  There are a ton of decidedly non-vocal casuals turning to ‘secure’ messengers to have chats they imagine are ‘military grade’ encrypted (they heard that was good) and not associated with their IRL identity (they consider that a must). They end up using terrible things and their entire chat histories exposed. But they ‘know’ the phone number is a non starter because that’s how other social networks outed them. So they will also often end up using a string of bad tools as an awkward way to keep several worlds separate. Most won’t admit it, but this second reason is why they, as iPhone users, aren’t in encrypted Messages for those chats. Neither end wants the chats in their phone number world. While you can argue this use case is for hiding that one even participates in chats others might frown on, that to me sounds like a use case that matters, since today, most of the world doesn’t agree what should be frowned upon. // This is not a technical assessment, it’s from the non-technical users’ point of view, how they think it’s working or not working. Same folks assume phone number is more identifying than finding an app that doesn’t need phone number because it can accept their FB log in. It’s a pretty rough world for non-techies.
balladeer 8y ago
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 same phone number). This will serve two use cases: 1. People who need simple private IM like WhatsApp can continue using it without asking for A or without giving it any heed. 2. Or you go for A and you are communicating w/o any real world identity attached to your messages.
- hardwarescope 8y ago
  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.
  - enimodas 8y ago
    It can be stored on the server, and encrypted by the users' private key. Like a message to himself.
    - 8y ago
Certhas 8y ago
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...").
- Terretta 8y ago
  I don’t buy the UI for discovery thing. Email is fine without discovery. So are.. phone numbers. I don’t want to be discovered. I want to give you my pseudonymous pointer and you can ping me to connect. Using phone numbers to ‘discover’ doesn’t solve the problem you say prevented encrypted email adoption, that’s a next step in the dance.
  - Certhas 8y ago
    What exactly do you not buy? I think you might be missing the point on what is meant by discovery here. This is not about random strangers talking to you, but about the issue that you have signal, your friend has signal, but even though you're already in each others phone books you can't talk to each other because you haven't exchanged pseudonymous pointers. There are exactly two pseudonymous identifiers that have "made it". Both associated to technological revolutions. One is phone numbers, the other is email. You put them on business cards and save them in your contacts. This is strong evidence that this is a hard problem. No other identifiers have been successful long term. And yes, this absolutely prevents encrypted email adoption. Imagine if switching to encrypted was like installing signal (back in the SMS fall back days). It's: "Hey use this email client, it automatically detects when the person you're mailing also has an encryption capable client and then all your communication with that person is encrypted." vs. "Hey use this EMail client, and if you find out that someone you know is also using it, you can go to this menu item here and search this database in order to find out how to email them securely, and if that doesn't work just email them normally to get a public key from them, before you send them the document you wanted to send." No guarantee that the former would work, but it would have a fighting chance. Of course such a solution isn't possible partly due to usage patterns that email has that would break. But that's why I'm relatively forgiving of Signals strict stance on shooting down these type of feature requests. Because they actually have massively improved secure communication for more than a billion people.
zbentley 8y ago
> Is it simply a question of finite developer time? Maybe. Or it could be because they don't want to. People equipped to solve one problem may not want to solve another, related problem. It might not be a priority, interest, or motivation for them. That's not apathy; that's decision-making.

tptacek 8y ago

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

mintplant 8y ago
I'll re-rephrase. Is it a problem of: (1) allocating developer time and organizational priorities; or, (2) a technical incompatibility with Signal's existing, phone number-based model? Based on your response I'm inferring (1), but I'm frustrated that this is never directly answered when the topic comes up.
- tptacek 8y ago
  It's more (1) than (2), is what I think, although I think non-phone authentication is probably trickier than we think it is and so the two categories bleed a bit. I seriously don't understand what people expect in these discussions, though. The situation is straightforward. A small but vocal minority of Signal's user base wants non-phone-number identification. Signal hasn't prioritized that feature. Put up, or use a different messenger. How is this complicated? Don't pick horrible messengers, like ones where encryption isn't enabled by default, or doesn't even exist for group messages, or isn't built on a protocol anyone understands or has reviewed. But even with that constraint, you have options.
  - jake_the_third 8y ago
    > 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.
    - tptacek 8y ago
      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?
      - cyphar 8y ago
        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.)
      - jake_the_third 8y ago
        Yes. More precisely, I stopped when I discovered that I couldn't decouple the signal user from my phone number. More importantly, I'm still very interested in seeing the data behind your vocal-minority assertion.
        pvg 8y ago
        The survey data you are looking for is WhatsApp.
eadmund 8y ago
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.
Terretta 8y ago
There are a ton of decidedly non-vocal casuals turning to ‘secure’ messengers to have chats they imagine are ‘military grade’ encrypted (they heard that was good) and not associated with their IRL identity (they consider that a must). They end up using terrible things and their entire chat histories exposed. But they ‘know’ the phone number is a non starter because that’s how other social networks outed them. So they will also often end up using a string of bad tools as an awkward way to keep several worlds separate. Most won’t admit it, but this second reason is why they, as iPhone users, aren’t in encrypted Messages for those chats. Neither end wants the chats in their phone number world. While you can argue this use case is for hiding that one even participates in chats others might frown on, that to me sounds like a use case that matters, since today, most of the world doesn’t agree what should be frowned upon. // This is not a technical assessment, it’s from the non-technical users’ point of view, how they think it’s working or not working. Same folks assume phone number is more identifying than finding an app that doesn’t need phone number because it can accept their FB log in. It’s a pretty rough world for non-techies.

balladeer 8y ago

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 same phone number). This will serve two use cases: 1. People who need simple private IM like WhatsApp can continue using it without asking for A or without giving it any heed. 2. Or you go for A and you are communicating w/o any real world identity attached to your messages.

hardwarescope 8y ago
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.
- enimodas 8y ago
  It can be stored on the server, and encrypted by the users' private key. Like a message to himself.
  - 8y ago

Certhas 8y ago

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...").

Terretta 8y ago
I don’t buy the UI for discovery thing. Email is fine without discovery. So are.. phone numbers. I don’t want to be discovered. I want to give you my pseudonymous pointer and you can ping me to connect. Using phone numbers to ‘discover’ doesn’t solve the problem you say prevented encrypted email adoption, that’s a next step in the dance.
- Certhas 8y ago
  What exactly do you not buy? I think you might be missing the point on what is meant by discovery here. This is not about random strangers talking to you, but about the issue that you have signal, your friend has signal, but even though you're already in each others phone books you can't talk to each other because you haven't exchanged pseudonymous pointers. There are exactly two pseudonymous identifiers that have "made it". Both associated to technological revolutions. One is phone numbers, the other is email. You put them on business cards and save them in your contacts. This is strong evidence that this is a hard problem. No other identifiers have been successful long term. And yes, this absolutely prevents encrypted email adoption. Imagine if switching to encrypted was like installing signal (back in the SMS fall back days). It's: "Hey use this email client, it automatically detects when the person you're mailing also has an encryption capable client and then all your communication with that person is encrypted." vs. "Hey use this EMail client, and if you find out that someone you know is also using it, you can go to this menu item here and search this database in order to find out how to email them securely, and if that doesn't work just email them normally to get a public key from them, before you send them the document you wanted to send." No guarantee that the former would work, but it would have a fighting chance. Of course such a solution isn't possible partly due to usage patterns that email has that would break. But that's why I'm relatively forgiving of Signals strict stance on shooting down these type of feature requests. Because they actually have massively improved secure communication for more than a billion people.

zbentley 8y ago

> Is it simply a question of finite developer time? Maybe. Or it could be because they don't want to. People equipped to solve one problem may not want to solve another, related problem. It might not be a priority, interest, or motivation for them. That's not apathy; that's decision-making.