Hacker News Reader

Comment by moxie | Hacker News Reader

Wait, have you actually used Signal multi-device? Your thesis is that it's not usable because you have to scan a QR code once, as opposed to Telegram where you have to receive an SMS on your device and manually type it in on your desktop?

The flow you're describing in your "possible solution" is basically identical to how Signal works now: you install Signal on a new device, approve it with your existing device, and are done. Anything involving the word "blockchain" here is fundamentally not going to work. It sounds like you want CONIKS, but there are some really substantial barriers to deploying that for marginal gains (and some clear losses).

View on HN

Given that the OP didn't know about Signal-Desktop 4 hours ago when I told them (see https://news.ycombinator.com/item?id=10750637 ) and was bashing Signal then for not supporting it, I'd say tajzin has at most had a cursory look at it. I'm not sure how or why they feel qualified to blog about it.

I've been using Signal-Desktop since the first days of the Beta and so far it's been a really pleasant experience. Big thank you to all involved!

Signal having all three qualities author is blogging about: security, multi-device cync, and usability basically makes this post and SMU theory nil. This looks like a case of "I have my theory, now lets bend facts to fit the theory".

I'd argue that usability in Signal isn't that great for other reasons, particularly around the contact list.

I responded in another thread about this. [1]

[1] https://news.ycombinator.com/item?id=10753881

Since when do you need qualifications to blog about something?

To be fair, Signal desktop is really new, the author may not have known about it. But yes, the flow of adding devices in Signal is very seamless and simple.

The issue of not supporting SMS though makes usability go down the toilet, because it's not immediately obvious who you can message or receive messages from, but I understand the reason for not supporting it.

The author definitely knows about it, since the thesis of the article is that Signal would be near-perfect if the multi-device flow were usable but "..the process for setting it up is annoying."

It's fine if the author hasn't tried it, but don't write an article criticizing the usability of something you haven't even tried.

The author concludes by asking for feedback on the idea. It would be difficult to get that from anyone, let alone people with actual expertise in cryptography, without writing a blog post and sharing it in venues like Hacker News. Rolling their own cryptography and selling it on the app store would probably be worse, as a first public engagement.

> Rolling their own cryptography and selling it on the app store would probably be worse, as a first public engagement

Also not something I would do because I don't feel qualified to implement this beyond a simple POC :-)

> The author concludes by asking for feedback on the idea. It would be difficult to get that from anyone, let alone people with actual expertise in cryptography, without writing a blog post...

Wat? It's trivial: https://lists.riseup.net/www/info/whispersystems

Thanks for taking the time to give some feedback, appreciated!

I didn't say Signal isn't usable, but it doesn't fit into the requirements because there should not be a distinction between primary/secondary devices after onboarding.

It might be possible to change Signal's model to accomodate that, but why even have a model that involves copying private keys between devices if you can avoid it? What if you wanted to revoke privileges from a device, but it has a shared identity key with your others?

> Anything involving the word "blockchain" here is fundamentally not going to work

Why? What if you're building something as a federated system and you need to share this key info in the network? Do you have an alternative suggestion?

What are the substantial barriers to deploying something like CONIKS? It doesn't seem to help the multi-device problem, but in general it does seem useful.

I would be curious about this as well. The only attack that I can think of that he might be referring to is the server publishing bad keys for a particular client while that client is offline. This equivocation would be caught fairly promptly though, and I think that eventual proof-of-equivocation is better than forcing users to manually verify keys.

Reply on news.ycombinator.com