3 ms·
> It sometimes feels like the security community is a bucket of crabs where any time something starts getting traction due to ease of use a lot of others try to
by zeveb 10y ago
> It sometimes feels like the security community is a bucket of crabs where any time something starts getting traction due to ease of use a lot of others try to pick at it due to it not being perfect even if many of those things are trade offs
That's because when it comes to security often theoretical vulnerabilities end up being protocol-destroying vulnerabilities in practice. Security folks are notorious for saying, 'that won't work,' being ignored — and then everyone being surprised when indeed it doesn't work.
> phone numbers allow for signal to be a drop in replacement for other messaging apps with minimal to no registration required
The issue is not allowing phone numbers as identifiers: the issue is in not allowing other identifiers. There's already a URN scheme for telephone numbers, and there are URN schemes for many other identifiers, to include email addresses, and there are even ways to add additional schemes. If Signal used URNs rather than telephone numbers, then users could continue to use telephone numbers but advanced users could use other identifiers, as they wish.
> lack of federation means ows can control spam better unlike in a federated environment where lazy/malicious operators can cause lots of problems
A spammer cannot spam someone whose public key he does not know. If there is no central directory of identifiers to public keys, there's no way for a spammer to send spam. It is possible for someone who knows one's public key to spam one, but since the sender's public key is tied to a public identifier, one knows who sent the spam.
Does Signal perform any anti-spam activity anyway?
- cwmma 10y ago> That's because when it comes to security often theoretical vulnerabilities end up being protocol-destroying vulnerabilities in practice. Security folks are notorious for saying, 'that won't work,' being ignored — and then everyone being surprised when indeed it doesn't work. we're not talking about protocol destroying bugs, were talking about things firmly in the realm of trade offs between marginal security gains and usability with security folks tending to be far too focused on marginal security gains while loosing sight of the big picture of less then perfect security that people use is better then perfect security that nobody uses. I.E. ChaCha is better then AES because it is more resistant to side channel attacks among other things, but if you are creating a TLS server and can only choose one algo, you probably want to choose AES because more browsers support it compared to ChaCha and the marginal gains from ChaCha probably don't justify excluding those users that don't support it. > If there is no central directory of identifiers to public keys, there's no way for a spammer to send spam If there is no central directory of identifiers to public keys, there's no way my mom will use it to send me anything
- zeveb 10y ago> If there is no central directory of identifiers to public keys, there's no way my mom will use it to send me anything She'd never use an app where you two bump phones with NFC?
- cwmma 10y agoI don't think her phone has NFC, it might but she wouldn't know if it did. But I don't always see her in person that often, which means we'd have to wait until we were face to face before we could even try to see if she had NFC etc.
- zeveb 10y agoCould also scan a QR code. I think an IM which relied on in-person seeding and then bootstrapped with mutual contacts could be quite powerful, and easy to use for newbies too.