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?
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.
> I genuinely believe there is a lot of commentary on this thread from people who have never designed a secure system.
Gosh that's quite the conclusion. I hope my employer never finds out about this discovery of my competency based on some comments on a message board.
I think you've very much lost the thread of what I'm saying here, because at no point have I suggested anything about 100% security or 100% privacy. It would actually be pretty weird for me to be advocating for that while also asserting that you're making maximalist arguments.
I also never said email is inherently more private than phone. I assert that it's a different privacy tradeoff, and one that I'm more comfortable with for various reasons. I could get into those if you want but I don't think they're relevant. (1) is the more interesting question in the end. (3) is just "it's open source you can fix it yourself!" which is .. not very useful on any level. Yes, I can go make my own signal-based platform and talk to precisely no one over it. No I'm not interested in doing that. I've been to the social network rodeo and have the mental scars to prove it.
So ok, assuming we go with email addresses as the alternative mechanism, and the email addresses still require verification same as the phone numbers, and you still have to mutually have each other on our contact lists to communicate through signal: How, specifically, has the threat model been weakened?
That comment wasn't directed at any single individual. There's just been a lot of "I imagine you can just type in a username and that would all work, QED. Duh." type of comments across the board, hence my broad statement.
I agree Signal could add email addresses specifically, if verified and it wouldn't affect the threat model outside of introducing the network to more spam-able identifiers. Like I've said, if they figured out how to do that without degrading the quality of the experience today I doubt I'd be up in arms. I'm working on adding more email addresses to my contacts book, slowly. It probably makes more sense today than it did when Signal was born.
It's not about what Signal can and can't do, though. Signal needed a readily available offline locally owned and operated contacts book with to make their product vision work. So they used the one everyone has on their phone and it worked. They upgraded the security of everyone sending sms and mms. I think there's a way to celebrate that while asking for email address support without getting into the ream of "zomg Signal sux because they use gross phone numbers what idiots would design a system like that what a fucking mess of a royal debacle attn. whistle blowers and abortion seekers: signal is not for you". That type of response is what I'm railing against by simply reminding people that Signal is a successful product that does indeed work as advertised and that it doesn't exist in a vacuum.
They've been working on it for years. Their solution is that they have to take client-side ownership of your contacts list, keep it associated with your "account" and sync it across your devices so that when you correspond with someone by username, it becomes available to you everywhere. They have to be your contact book. I can find nothing on how they plan to verify usernames, perhaps in the traditional style with email.
So yeah, absolutely not some trivial change that they just don't want to do because fuck the few people that don't have a phone number (or don't want to use it). They're working toward supporting usernames and at every turn keep getting reamed by HN because, in their effort to solve a problem that only exists on HN, they have to deploy a solution that means you have to trust them in a teeny tiny way you didn't previously IF you set a weak pin on your account. It's mind boggling. It must be so disheartening to see that type of response.
But, that's my point. Signal can't add short names without changing the fundamental trust model which appealed to everybody initially. No amount of hiding a password as a pin, will change that. I really hope they don't kill their product along the way...
(Also man WTF they're running Raft on SGX enclaves just so they can rate limit attempts to brute force users' weak pins. While super cool, technically, what an incredible waste of resources just to try and make weak passwords okay. Probably the most backwards thing I've seen a security company attempt like ever. Just tell your users if they want a username they need a strong password. Or just generate the entropy for them and only allow the username option to people who also want to take custody of their new 32-bytes of entropy and have a signal-managed synced contact book.)
> Just tell your users if they want a username they need a strong password.
If their goal is to shift responsbility to the user, that solution works. If their goal is to provide secure communications to the general public, that solution doesn't work. As you probably know, strong passwords are widely recognized as a failed security technology for the general public.
Also, what happens when the user forgets their strong password? Dataloss is not an acceptable outcome for general end users whose priority usually is not ultimate security, but usability. Thus (as I understand it) Signal allows weak passwords ('PINs') that stay with the client, and adds 'invisible' entropy which is backed up to server-side SGX (because the user doesn't know the entropy, it must be backed up off-phone in case the phone is lost). It's a great, no-tradeoff solution IMHO: If SGX is compromised, the user is no worse off than if the supplemental entropy didn't exist at all - they have their (weak) password. If you don't want to depend on the 'supplemental entropy', use a strong password and then Signal's entropy and SGX security become irrelevant.
> Or just generate the entropy for them and only allow the username option to people who also want to take custody of their new 32-bytes of entropy and have a signal-managed synced contact book.
AFAICT, Signal is not interested in implementing features that are valuable only to geeks and that everyone else ignores, and those kinds of features don't seem to fit their mission.
I agree almost completely. It's just that my guess is that nobody actually cares about usernames either, just the few people who can't use a phone for <reasons>. So I'm thinking they're already kinda in the realm of building out this feature for nobody which is why I was suggesting something more wallet-like like generating 32bytes of entropy and showing users the mnemonic representation and telling them not to lose it (which is familiar, despite being a terrible UX, at least). Perhaps I'm underestimating how many people actually would use a username instead of their phone number in which case I think your 100% spot on.
> in their effort to solve a problem that only exists on HN
I don't understand why your takeaway from the fact that they're implementing it is that the people saying they want or need it are irrational and only exist on hn instead of "hmm, maybe I'm wrong and this is a legitimate feature request".
Anyways, let me assure you that the people who get "reamed" are in fact anyone who even causally mentions they want this feature who get a bunch of very dedicated people telling them how utterly wrong they are, no one should ever want that and anyways it's impossible actually.
I'd consider the way you're asking for the feature. There was definitely an air of "this is such a simple feature why can't I just have it it should be no trouble for everyone involved it's just a username". I think if people asking for this feature were to spitball through it and acknowledge the tradeoffs rather than incessantly repeat how uncompromising they are in their need for usernames and their need for Signal to have them yesterday, the conversation wouldn't seem so volatile. I actually wasn't trying to dive in and sling mud. I see this conversation all the time on HN and, coming across it again, wanted to suggest that maybe another product with usernames would work better for these people since literally every time Signal comes up on HN the peanut gallery shoots off with tired smears and entitled quips about how Signal users phone numbers.
The strong response you encounter is people trying to communicate that it isn't that simple for them. That it means enough of a shift in Signal's model that they're really worried about the change to the product if Signal implemented it, not least because it changes the very thing that drew them to the product in the first place. And unfortunately, it seems the worries are not unfounded. I genuinely don't think many of the people asking for usernames would want them if the proposition was clear: "you can have them but you have to trust us with your contacts book and personal information". It's the catch22: in order to have the privacy of a username, you must give up the privacy you'd win. For some people, they trust Signal with that responsibility more than their carrier (like a VPN) and it's a good tradeoff.
Me? What was compelling about Signal is that it was my contacts book and encrypted communication. No accounts/profiles, no passwords, no proprietary software, no invasive product analytics, just a global DB associating phone numbers with pubkeys. That was my pipe dream but I also acknowledge I'm not the center of the world either: in the same way you begrudgingly use Signal with a phone number, it's also not the end of the world for me if we have yet another company out there where I need to maintain a profile and stick a password in my password manager and login periodically. But sadly, if Signal gets to that point, it ultimately means the "Signal experiment" portion of the product's life will have come to an end. <- This, more than anything else, is why the suggestions to go use one of the products that already provide the experience you're looking for is apropos and not dismissive. We don't want the experiment to end. The entire point of championing Signal in the first place was idea that we could collectively participate in a product that didn't do what everyone else on the internet did and send off all your data to their servers the minute you opened their app.
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.
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".
> 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.
I think you're missing the part where they are in the trying to figure out how to relax that constraint phase (they have not yet) and having trouble in paradise.
They've run into all the issues and nuances elucidated in this thread. They have been receiving pretty intense feedback from people who have stopped using their product because of the concessions made. They've clammed up in response and are losing even more people because they are not clearly articulating the changes to their users (many of whom would be fine with it if communicated transparently and respectfully). They have people who desperately want usernames but also not if it means what Signal is proposing and admit "okay, you heard my request and tried, but hmm let's not do that I don't like this PIN UX and it's not what I wanted when I said I want usernames". And they even saw their product forked the minute it became clear what they were doing: https://getsession.org (blogs start Dec, 2019 which is around the time Signal started messing around with secure value recovery stuff, at least publicly).
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?