Live data from Hacker News

We can do better than Signal

icyphox.sh

141–150 of 290 posts

Re: We can do better than Signal

#141
post #137

Earlier quoted context omitted.

Nobody thinks about it but the most professionally used communication medium is the email, and part if not all of its success if not all its success is that is decentralized. A company cannot afford to use a service that can be closed and loose all the communications. Centralized services are single point of failure, and in that regard Signal is no better than WhatsApp, because yes, in theory you can run your own ser…

On the other hand, email is the single largest causes of cyber attacks. The communication is not E2E encrypted (apart from a few GPG/SMIME users), no forward secrecy and barely any signature checks. Even if outlook, thunderbird maybe supports it, goodluck getting all the mobile versions to support it too. The clients used to view emails suffer from the same problem with browsers so are subject to all the HTML/JS/CSS…

> I wish all companies would move to something centralized solution where communication is guaranteed to only come from those within the same service. This way Sharon from HR won't open every link, download every crypto/ransomeware.

It's totally possible to set up 'email' for intranet purposes only, using your own DNS setup, standards compliant smtpd and imap daemons over TLS. The persons using it just need to know it can't send or receive emails from outside of the organization.

Re: We can do better than Signal

#142
post #32
post #8

I'm confused about this piece. If there's true E2E encryption (verified by open source client code and review of released binaries) then why does it matter if the server code is backdoored or not? The whole point of E2E is that you don't need to care about the server being able to ever see the text of your messages because it never can.

Copy pasting my comment: Consider this paragraph from the Signal protocol > ...For example, they may compare public key fingerprints manually, or by scanning a QR code. Methods for doing this are outside the scope of this document. > If authentication is not performed, the parties receive no cryptographic guarantee as to who they are communicating with . Nobody I know in practice does this authentication. If an activ…

I can't see how this is a problem on its own.

If they were eschewing some better option than "don't trust the server", that would be a problem, but is there a better option?

Re: We can do better than Signal

#143

Earlier quoted context omitted.

We need to think of ways to run the various Matrix, Mastodon, peertube etc in tiny boxes in our homes! There is no real reason for not promoting self hosting. The same way i buy a small Nas or an amazon firetv stick, with apps, I would buy a small box with pihole, mastodon and matrix.

Have you tried running Mastodon and Matrix on a Pi? I'm not so confident it'd work, these aren't lean servers. I would love a tiny server I can run on my home server (for my tiny message volume), but Mastodon and Synapse are optimized for large servers.

I have tried it on a RPi3 and it is painfully slow. I would not recommend this to anyone.

Re: We can do better than Signal

#144
post #67
post #42

Earlier quoted context omitted.

How do you prevent bots giving each other reputation?

Some strategies: Make reputation scores the result of some sort of eigendecomposition-based algorithm (similar to PageRank) where the initial state vector is based on the people you trust. That way, you’ll only give credence to a bot to whatever degree you (indirectly) trust the bot. Implement Sybil resistance with a combination of verifiable cost and blacklisting. Make it cost real verifiable resources to create an…

> Make reputation scores the result of some sort of eigendecomposition-based algorithm (similar to PageRank) where the initial state vector is based on the people you trust. That way, you’ll only give credence to a bot to whatever degree you (indirectly) trust the bot.

This is just 'web of trust', right? https://en.wikipedia.org/wiki/Web_of_trust

Re: We can do better than Signal

#145
post #10

I'm a bit annoyed at "we can do better than X" when, you know what? Maybe we can't. Yes, it's nice that you and I can install Element and deal with the finicky crypto handshake that for some reason always shows red for me because a friend opened the web UI and closed it before he completed the handshake and now we can never actually make that check go green, and it's nice that Mastodon is distributed but mastodon.hos…

We need to think of ways to run the various Matrix, Mastodon, peertube etc in tiny boxes in our homes! There is no real reason for not promoting self hosting. The same way i buy a small Nas or an amazon firetv stick, with apps, I would buy a small box with pihole, mastodon and matrix.

There's been work on integrating the server and client together in a p2p fashion.

Then you are essentially self-hosting on your phone/laptop when you run the client.

Re: We can do better than Signal

#146
post #57

Earlier quoted context omitted.

I had a similar experience with Matrix/Element. I was using the desktop app to chat with a friend, and while we were able to get some end-to-end encryption working, it was a huge pain the butt, and if two software engineers struggled this much to get the damn thing working, there's no way in hell that I'm convincing my parents to use it. To me, we have to accept the incremental wins where we can get them; getting my…

Speaking as project lead for Matrix (and Element), I'm trying to understand the mixed feedback we've had this week, and somehow channel all the negativity into improving things. While some folks are clearly using it successfully and seem to like it, another bunch of people say "it was a huge pain in the butt to get E2EE working, and if it two software engineers struggled this much..." etc. When did this E2EE failure…

I don't actually think anything is awful, but my main complaint about Element as a GUI app, is that aside from opening the chromium developer console and watching what it does, it has very few options to diagnose client-server connectivity or TLS crypto key handshake issues.

I wish it wasn't an Electron app built on Chromium which makes it a huge resource hog. There's lots of underlying dependency and reliance on whatever design decisions the Chromium developers might make now or in the future, which would not be best suited to the security and single-purpose-focus of a chat application.

Re: We can do better than Signal

#148

As I wrote in https://news.ycombinator.com/item?id=25795575 - WhatsApp: Oh wait, SMS etc. is completely insecure - Signal: Oh wait, WhatsApp is structurally unable to be a force for privacy - Matrix: Oh wait, even benevolent centralization is an unnecessary risk It's not that worse is better, but the general public's imagination can only grow so fast. We need to coax people along. As such, I do think all 3 serve a pu…

In fairness, I think WhatsApp's value proposition is and was as little more than 'just' oh wait, sms etc. is completely insecure. I don't think the majority really cared about that (especially since end-to-end encryption was a later addition). I think most people primarily started using WhatsApp because a) it was (is) free b) cross-platform c) worked very reliably

I really doubt it was about security. My bet is on convenience and the fact that it's free for Non-North Americans while SMS is not.

Re: We can do better than Signal

#149
post #57

Earlier quoted context omitted.

I had a similar experience with Matrix/Element. I was using the desktop app to chat with a friend, and while we were able to get some end-to-end encryption working, it was a huge pain the butt, and if two software engineers struggled this much to get the damn thing working, there's no way in hell that I'm convincing my parents to use it. To me, we have to accept the incremental wins where we can get them; getting my…

Speaking as project lead for Matrix (and Element), I'm trying to understand the mixed feedback we've had this week, and somehow channel all the negativity into improving things. While some folks are clearly using it successfully and seem to like it, another bunch of people say "it was a huge pain in the butt to get E2EE working, and if it two software engineers struggled this much..." etc. When did this E2EE failure…

> At the moment the vast majority of negative feedback on HN has been "it sucked" without giving a hint of what actually went wrong.

That's the nature of the HN beast: getting all the "it sucked" comments without STR and/or use-case descriptions is certainly demoralizing (reading HN comments about your own work is not for the unprepared) but asking folks who've had a bad time with your product to spend more time, for free, going through that same experience again so they can do a detailed report-out for you is probably not going to get a lot of takers (even if you might get a few high quality reports).

If you're not already doing so, I would strongly recommend you invest some money in getting access to "people who've never used Matrix before but are familiar with messaging apps" to do user testing (there's a number of sites for doing that for you, where you hand over money and instructions, and they find folks to do unbiased testing for you) where you ask pairs of people to get started with your software, with the explicit goal of getting to the point where they can set up E2EE messaging, and reviewing the recordings to see what roadblocks they run into.

And for bonus points, dev-blog about those experiences on the matrix/element site (where did folks get stuck? was this a surprise to you? why? how did you fix it? what were the user reactions to the fix? how much better is Matrix now, thanks to this work?).

Re: We can do better than Signal

#150

I wanted to disagree with the headline. Then I read the article and do see their point. I’ve been a big proponent of Signal for years and donated for the first time during their outage. But I do think this is a conversation worth having. I’d also like to understand more about this: > In fact, the Signal server code [0] hasn’t even been updated since April 2020. You’re telling me it’s undergone no changes? [0]: https:…

I disagree too, I known the people behind signal and signal protocol by far 10 years, I been see their work for a long time in different fields, when I read "We can do better than Signal" It's a natural thought human to find better in all things, but I don't really see more in the article
Post reply on HN