4 ms·

You've said something like this many many times and I just don't see the logic of the question. You're talking about a feature that you admit is a privacy compr

You've said something like this many many times and I just don't see the logic of the question. You're talking about a feature that you admit is a privacy compromise and then comparing it to an absolutely maximalist alternative, or a world where people only connect in literally one way (through their phone contact lists). Is it really so hard to imagine that other compromises may be possible, or even coexist? The answer is I give them my email or username. They give me theirs. We connect. Using phone contact lists shortcuts this process, but the exchange still had to happen at some point. Is it really so hard to believe some users might choose to do it again? Or, god forbid, with someone they'd rather not give a phone number to?

dcow 4y ago
I'm not comparing to some absolutely maximalist alternative. I'm asking how you get an equivalent product experience without the compromise (which would make everyone happy). I strongly believe the UX afforded by the compromise is how Signal has won all its users. The threat model and all it entails is the value prop. I genuinely believe there is a lot of commentary on this thread from people who have never designed a secure system. You never get 100% security and 100% privacy. Even if you only use public keys, web3 style, you're still a traceable public key--by definition not private. Okay everyone uses a fresh key for every action. Well now you have a problem figuring out who anybody is and whether you should trust them. Either trust isn't self-sovereign or it is. And we've learned time and time again that self-sovereign trust systems are akin to anarchy. Signal leverages the verifiable short identifiers available to a mobile phone, at the expense of 100% perfect anonymity when asking the question "has this phone number used signal". Literally everything beyond that point is 100% secure and as private as two public keys corresponding can be. 1. As a signal user, I don't want to see the threat model weakened so that we can include email anons, personally. 2. Even if we did, I don't understand how doing so in any way solves the privacy issue. How is email any more private than phone? If an email provider got phished people would be yelling the same thing "how could signal be so stupid to use email, don't you know it's insecure". Email providers can still be compelled into shenanigans, too. 3. Signal as a product has to facilitate a key exchange. I'm pretty sure you can checkout their source code and run their protocol and solve the key exchange portion differently if you so desire. You could have "signal without phone numbers or email" tomorrow if you wanted. As long as your users are willing to copy and paste public keys into their messenger, that is. To sum up: the key exchange and distribution is the entire problem. And Signal presents an adequate solution: bind phone numbers to asymmetric crypto, add perfect forward secrecy and give people secure messaging. Surely it's not for everyone, but this incident in my eyes only further validated that this premise is solid.
- kortilla 4y ago
  You’re angrily lashing out at strawmen to justify why the lookup key is constrained to a phone number. That does not need to be bound to a phone number, it could be an identifier someone just types in. What you’re arguing for is the recovery mechanism to get back online when you lose your private key, which is totally unrelated and could be solved independently for people who choose to give a phone number vs those using an email or some other arbitrary identifier.
  - dcow 4y ago
    1. I'm not angry at all. 2. Let me make this clear: an imperative component of signal's product is that the identifier used is verifiable, and that the only thing they store for a period of time is that users in-fact did verify their number. Everyone arguing for typed in identifiers is missing this point. That wouldn't be Signal. That's the core of what I'm saying. That would be something else where people claim short identifiers and then have to share them with each other via some other channel which I'd have to independently verify, etc. 3. Nobody arguing for non-phone-number short identifiers has proposed a solution for how you verify them and manage them that doesn't change Signal's fundamental threat model and information architecture, which, at the end of the day, is what many users are bought into. I use Keybase, feel free to hit me up there if you need a messaging platform with socially verified short identifiers. My proof is in my profile. If you want an unverified short id, email works great, I respond to that too. Point being there are existing options for "type in a short id and send it a message".
    - dcow 4y ago
      Following up on: > Nobody arguing for non-phone-number short identifiers has proposed a solution for how you verify them and manage them that doesn't change Signal's fundamental threat model and information architecture, which, at the end of the day, is what many users are bought into. So it turns out Signal is building support for usernames and their solution is indeed rather involved. In order to achieve usernames they've: 1. added a contacts book and profile 2. added a passpin by introducing Intel as a trusted actor. the pin you enter when using signal is actually your Signal account password 3. presumably adding support for usernames and <TBD> username-based verification They've been working on this for years. They're not just sitting on their hands. So my point seems to stand: it's not just "add a username field and let people type shit in we have input fields amirite". It's a massive overhaul of their fundamental architecture. And sadly it's not happening very publicly because the stuff they're doing to make it happen is also not okay according to the other half of the security community. Carriers? Not okay? Well how about usernames? Oh, you're using 4 digit pins as passwords and SGX to throttle login attempts? Well that's not okay either SGX has been pwned a billion times. Lose/lose for Signal. I pity them, honestly. It sucks. I'm not personally enraged or anything. I think the SGX stuff is actually a pretty cool compromise. But, alas, it's still a compromise in order to make usernames equally feasible as phone numbers. Either way you're compromising. And that's what this thread is about: to make security accessible you can't live in an ivory tower and demand perfection. You have to get down in the field and make compromises in order to build a successful product that people will actually use.

dcow 4y ago

I'm not comparing to some absolutely maximalist alternative. I'm asking how you get an equivalent product experience without the compromise (which would make everyone happy). I strongly believe the UX afforded by the compromise is how Signal has won all its users. The threat model and all it entails is the value prop. I genuinely believe there is a lot of commentary on this thread from people who have never designed a secure system. You never get 100% security and 100% privacy. Even if you only use public keys, web3 style, you're still a traceable public key--by definition not private. Okay everyone uses a fresh key for every action. Well now you have a problem figuring out who anybody is and whether you should trust them. Either trust isn't self-sovereign or it is. And we've learned time and time again that self-sovereign trust systems are akin to anarchy. Signal leverages the verifiable short identifiers available to a mobile phone, at the expense of 100% perfect anonymity when asking the question "has this phone number used signal". Literally everything beyond that point is 100% secure and as private as two public keys corresponding can be. 1. As a signal user, I don't want to see the threat model weakened so that we can include email anons, personally. 2. Even if we did, I don't understand how doing so in any way solves the privacy issue. How is email any more private than phone? If an email provider got phished people would be yelling the same thing "how could signal be so stupid to use email, don't you know it's insecure". Email providers can still be compelled into shenanigans, too. 3. Signal as a product has to facilitate a key exchange. I'm pretty sure you can checkout their source code and run their protocol and solve the key exchange portion differently if you so desire. You could have "signal without phone numbers or email" tomorrow if you wanted. As long as your users are willing to copy and paste public keys into their messenger, that is. To sum up: the key exchange and distribution is the entire problem. And Signal presents an adequate solution: bind phone numbers to asymmetric crypto, add perfect forward secrecy and give people secure messaging. Surely it's not for everyone, but this incident in my eyes only further validated that this premise is solid.

kortilla 4y ago
You’re angrily lashing out at strawmen to justify why the lookup key is constrained to a phone number. That does not need to be bound to a phone number, it could be an identifier someone just types in. What you’re arguing for is the recovery mechanism to get back online when you lose your private key, which is totally unrelated and could be solved independently for people who choose to give a phone number vs those using an email or some other arbitrary identifier.
- dcow 4y ago
  1. I'm not angry at all. 2. Let me make this clear: an imperative component of signal's product is that the identifier used is verifiable, and that the only thing they store for a period of time is that users in-fact did verify their number. Everyone arguing for typed in identifiers is missing this point. That wouldn't be Signal. That's the core of what I'm saying. That would be something else where people claim short identifiers and then have to share them with each other via some other channel which I'd have to independently verify, etc. 3. Nobody arguing for non-phone-number short identifiers has proposed a solution for how you verify them and manage them that doesn't change Signal's fundamental threat model and information architecture, which, at the end of the day, is what many users are bought into. I use Keybase, feel free to hit me up there if you need a messaging platform with socially verified short identifiers. My proof is in my profile. If you want an unverified short id, email works great, I respond to that too. Point being there are existing options for "type in a short id and send it a message".
  - dcow 4y ago
    Following up on: > Nobody arguing for non-phone-number short identifiers has proposed a solution for how you verify them and manage them that doesn't change Signal's fundamental threat model and information architecture, which, at the end of the day, is what many users are bought into. So it turns out Signal is building support for usernames and their solution is indeed rather involved. In order to achieve usernames they've: 1. added a contacts book and profile 2. added a passpin by introducing Intel as a trusted actor. the pin you enter when using signal is actually your Signal account password 3. presumably adding support for usernames and <TBD> username-based verification They've been working on this for years. They're not just sitting on their hands. So my point seems to stand: it's not just "add a username field and let people type shit in we have input fields amirite". It's a massive overhaul of their fundamental architecture. And sadly it's not happening very publicly because the stuff they're doing to make it happen is also not okay according to the other half of the security community. Carriers? Not okay? Well how about usernames? Oh, you're using 4 digit pins as passwords and SGX to throttle login attempts? Well that's not okay either SGX has been pwned a billion times. Lose/lose for Signal. I pity them, honestly. It sucks. I'm not personally enraged or anything. I think the SGX stuff is actually a pretty cool compromise. But, alas, it's still a compromise in order to make usernames equally feasible as phone numbers. Either way you're compromising. And that's what this thread is about: to make security accessible you can't live in an ivory tower and demand perfection. You have to get down in the field and make compromises in order to build a successful product that people will actually use.