Live data from Hacker News

We can do better than Signal

icyphox.sh

231–240 of 290 posts

Re: We can do better than Signal

#231

Earlier quoted context omitted.

There's nothing inherent about this to Matrix, I don't believe.

I mean, maybe? There could certainly exist a phone-verified Matrix server, obviously, but unless the default server that is used for Matrix does that, it's still going to be a bit of friction entering in the server information.

Or even more critically, a discovery server that supports phone number registration so your existing contacts can find you again after they switch.

The only major discovery server on Matrix is currently the vector.im one, and it only supports email identity registration. As many people have pointed out, most users care far more about usability than they do security/privacy, so a service that allows an optional registration of identity using the currently-standard identity tracking system of phone numbers is pretty much a requirement.

Re: We can do better than Signal

#232

Earlier quoted context omitted.

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…

For me, this was a month or two ago. I don't remember exactly now, but my friend and I tried to verify each other, but one of us quit the device verification (with the five emojis) half-way through and uninstalled the app, so now there is a half-verified device that we can never remove. My icon with him always shows up red because of this device, and there's nothing we can do. UPDATE: I just checked now, there's a "m…

In case you don't know, like Gitter, Freenode has a public Matrix bridge!

Re: We can do better than Signal

#233
post #193

Hey icy, the issue you raise about Signal not being decentralized, I think, is a valid one. You should check out a decentralized messaging and social media app I have been working on - Omnii. Omnii allows each user to manage their encryption keys, and all data exists in a decentralized manner - only on endpoints (users' phones), and not on a backend. https://omnii.co is our website if you are interested.

Omnii looks exciting. Signed up for the beta in Play store. But can’t find the app afterwards. Does it require specific hardware?

Hey, glad you are intrigued!

If you click the "Download Omnii Beta" button on the website, it should take you to the Google Play Store listing and allow you to download the Beta version of the app.

One restriction at the moment is that the app is closed to the U.S., Canada, Mexico, and India. If you do not reside in one of the listed countries, shoot me an email with the country you live in and I can see if we can open up the Beta to your country.

My email is: tyler@omnii.co

Re: We can do better than Signal

#234
post #148

Earlier quoted context omitted.

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.

E2E encryption is certainty a reason that non-techies use WhatsApp, particularly in preference to Facebook Messenger since 'Facebook reads all those messages' as a friend said. Which I don't think is technically possible any more, but remains a common suspicion.

Re: We can do better than Signal

#235

I feel like Signal is held to a ridiculously high bar when it comes to anything. Is it perfect? No. But come on now; I see other threads on HN where people are debating/bashing their use of Intel SGX, really? Assuming you trust the client builds (or use a verified build) and verify the public key, all of these arguments go out the window with the exception of exposing your phone number. This situation seems like a pr…

If they're transparent, why don't they expose their commits to server code to the public?

This is a great example of what I'm talking about. Are you also commenting how you can't see the source of your phone's baseband, Google's services, your ISP's router firmware, WhatsApp's servers, Facebook's service's, etc?

Because Signal's client is open source it's considered a unique-to-Signal downside that we don't have access to the server's source. I feel like some people would bring up the server source issue if someone was asking if it would be a good idea to migrate off of Facebook Messenger.

Re: We can do better than Signal

#236
post #153

I feel like Signal is held to a ridiculously high bar when it comes to anything. Is it perfect? No. But come on now; I see other threads on HN where people are debating/bashing their use of Intel SGX, really? Assuming you trust the client builds (or use a verified build) and verify the public key, all of these arguments go out the window with the exception of exposing your phone number. This situation seems like a pr…

Why is not wanting vendor lock-in a high bar? After dealing with Messenger, WhatsApp, Face time, etc all my life I'm tired of it. It doesn't matter if the code is open source, I'm still going to be locked in when all my friends move to Signal.

I understand what you're saying but I don't know if calling it vendor lock in is quite correct. You can export your list of messages out of Signal and presumably import them to whenever you motivated to do so. Your friends could then join you on the new service and life would continue on.

I am personally unaware of any communication service with a universally portable user identifier and that allows you to freely switch upstream providers other than phone service. I think this what you're talking about?

Re: We can do better than Signal

#237
post #186

For the longest time, Signal wouldn’t work without Google Play Services, but Moxie (the founder of Open Whisper Systems and maintainer of Signal) finally fixed this in 2017. There was also a long time when Signal was only available on the Google Play Store. Why do I make a big deal out of Google Play and Google Play Services? Well, some people might trust Google, the company. But up against nation states, it’s no con…

> Moxie, why haven’t you put Signal on F-Droid yet? There's no security benefit in having Signal on F-Droid instead of using https://signal.org/android/apk/ . I don't think Signal would say much if F-Droid distributed this APK directly (instead of a recompiled version with a different signature). It's just complicated to set up, which is why (I think) nobody has done it. > But we have to trust that Moxie is running t…

The benefit of running Signal on F-Droid is its secure update mechanism.

Do you really think a homebrewed self-update mechanism is superior to the battle tested F-Droid?

Moxie has a complete stranglehold on the Signal system. You are completely at his mercy for all decisions affecting the platform

See:

https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

The solution is federation, like email has always been.

There are a couple of ways to solve this problem, which can be used in tandem. We can stop Signal from knowing when we’re talking to each other by using peer-to-peer chats. This has some significant drawbacks, namely that both users have to be online at the same time for their messages to be delivered to each other. You can still fall back to peer-to-server-to-peer when one peer is offline, however. But this isn’t the most important of the two solutions.

The most important change is federation. Federated services are like email, in that Alice can send an email from gmail.com to Bob’s yahoo.com address. I should be able to stand up a Signal server, on my own hardware where I am in control of the logs, and communicate freely with other Signal servers, including Open Whisper’s servers. This distributes the security risks across hundreds of operators in many countries with various data extradition laws. This turns what would today be easy for the United States government to break and makes it much, much more difficult. Federation would also open the possibility for bridging the gap with several other open source secure chat platforms to all talk on the same federated network - which would spurn competition and be a great move for users of all chat platforms.

Moxie forbids you from distributing branded builds of the Signal app, and if you rebrand he forbids you from using the official Open Whisper servers. Because his servers don’t federate, that means that users of Signal forks cannot talk to Signal users. This is a truly genius move. No fork of Signal4 to date has ever gained any traction, and never will, because you can’t talk to any Signal users with them. In fact, there are no third-party applications which can interact with Signal users in any way. Moxie can write as many blog posts which appeal to wispy ideals and “moving ecosystems” as he wants5, but those are all really convenient excuses for an argument which allows him to design systems which serve his own interests

Re: We can do better than Signal

#238
post #68

Earlier quoted context omitted.

Matrix is merely federated, right? Why is it unlikely that a situation like email or the Internet will emerge, where the network still ends up massively centralized because that's just more convenient ?

We're proactively working on P2P matrix, as per https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix/ , to prevent this risk.

This is literally the saving grace for Matrix in my opinion. As can be seen with Mastodon, federation tends toward centralization of the servers if there's even an incremental benefit to doing so and nothing encouraging otherwise.

Matrix at least seems to have fewer barriers to usability/functionality when self-hosting, which decreases the detriments of self-hosting and slightly lowers the drive to centralize, but until P2P is default standard for clients the convergence is likely to remain with a mostly centralized federation infrastructure target than a heavily decentralized one.

Re: We can do better than Signal

#239

I feel like Signal is held to a ridiculously high bar when it comes to anything. Is it perfect? No. But come on now; I see other threads on HN where people are debating/bashing their use of Intel SGX, really? Assuming you trust the client builds (or use a verified build) and verify the public key, all of these arguments go out the window with the exception of exposing your phone number. This situation seems like a pr…

> I feel like Signal is held to a ridiculously high bar when it comes to anything. Maybe I can help: I feel Signal is doing a lot right and if I need to send a message right now and be 99.999% sure nobody except the recipient can read it, Signal is my choice. My criticism is mainly directed not at Signal, but at the people trying to promote Signal by trying to trash every other messaging technology. The reason is tha…

> - and allow armed forces and other groups that need it to run their own servers

if you can afford to run your own servers, then you can afford to run a build server too and push your own releases with the server patched.

Re: We can do better than Signal

#240

Earlier quoted context omitted.

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…

> 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

I think they already do quite a bit of this, which is probably what makes it puzzling when tech oriented users on hn keep reporting how terrible it is, thus the desire for more details to see whether it's just an older anecdote, something missed in testing, etc.

Two matrix blog posts[1][2] from the past 2 months both mention new user testing/research, and there's definitely more if you go back in their blog history.

[1] https://matrix.org/blog/2020/12/17/matrix-to-reloaded#whats-...

[2] https://matrix.org/blog/2020/11/27/this-week-in-matrix-2020-...

Post reply on HN