Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Encrypted messengers: Riot, not Signal, is the future

titus-stahl.de

Post reply on HN
Print view View original

161–170 of 178 posts

Re: Encrypted messengers: Riot, not Signal, is the future

#161

Post by sliken »

Wow, riot has a ways to go. With signal you install it from the app store, it creates an icon, you click on it. Similar for the desktop client, go to the chrome app store, click on it, and it tells you to use your phone to scan a barcode.

In both cases you can start chatting with any signal user in your address book in a minute or so, no expertise (other than using an app store) needed.

Tracked down the http://riot.im, it has a "try now button", that just scrolls you to the top. Didn't see any way to actually try it.

I tried the ubuntu app, they make you manually create your own /etc/apt/sources.list.d, from only the base URL. Then you have to know how to add the pgp key. Then apt-get update, apt-get install riot-web. Then... nothing. Nothing called riot or riot-web in the path. Thought maybe there would be a daemon running (it's called riot-web afterall). Can't find any processes running, nothing listening on a new socket. I track down /var/lib/dpkg/info/riot-web.list, look through the list and find they dropped a dir in /opt. So I run /opt/Riot/riot-web.

It worked, not exactly the kind of thing I'd ask random friends/family/colleagues to do though.

Re: Encrypted messengers: Riot, not Signal, is the future

#162

Post by Arathorn »

vertex-four wrote: post #155
acqq wrote: post #141

Earlier quoted context omitted.

Thank you. This is exactly what I wanted to read: clear explanation what works and surely not "it's not stable." What are the current encryption-related bugs, that is, what is their worst consequence? I surely don't have a problem with the manual verification.

The current bugs are basically that occasionally, you can't decrypt a message. Supposedly this has actually been fixed (and wasn't a security issue), but I've seen it once or twice since. And as I say, you lose your chat history if you log out or bring in a new device. This is an important bug to fix, but it requires some UX work.

We are still chasing down the final unknown session ID bugs actually, although many have been fixed. The other big issue is to warn when unverified devices are added to a room. We are working on them all currently.

Re: Encrypted messengers: Riot, not Signal, is the future

#163

Post by vertex-four »

x0x0 wrote: post #158
vertex-four wrote: post #133

Earlier quoted context omitted.

There's a reason web browsers just don't allow users to easily get past the annoying pages when there is a chance they're being attacked. I see no reason that Matrix clients would be required to allow users to break security without having a persistent banner saying "this room is insecure".

Which they will ignore.

Cool. If they ignore the great big banner which says "do not enter any personal info, bank info, etc etc into this window" and they're attacked, obviously they didn't care much. In the meantime, people who actually understand security can make a reasonable decision.

Re: Encrypted messengers: Riot, not Signal, is the future

#164

Post by krick »

qznc wrote: post #110
NoGravitas wrote: post #36

Earlier quoted context omitted.

And an open replacement for Slack.

Yes. I don't see Signal and Matrix in direct competition, just like WhatsApp and Slack are not in direct competition. The technology is very similar (main difference seems to be the size of chat rooms), but the use case and marketing is very different. Signal/WhatsApp is for casual mobile texting, while Matrix/Slack is for working.

It might be the case, but I should would prefer being able to stick to just one messenger in the end. And I don't see why it wouldn't be Matrix as opposed to WhatsApp. (If we ignore the networking factor, of course.)

Re: Encrypted messengers: Riot, not Signal, is the future

#165

Post by twr »

MichaelGG wrote: post #130
sliken wrote: post #94

Earlier quoted context omitted.

Google can't push a new Signal APK, it's signed by OWS, not google. 3rd parties can download the signal source and compile it. Not sure if there's enough information available to product a bit identical (and thus verifiable binary). I guess a NSL might compel OWS to push a binary specifically for a targetted user. If that's in your threat model you definitely need to take additional steps.

So Android checks the APK is signed by the same publisher on update? What about for new users? Nothing stops Google from just changing which package is on Play Store, right? Where does signature validation come in, and how would a user tell?

> When the system is installing an update to an app, it compares the certificate(s) in the new version with those in the existing version. The system allows the update if the certificates match. If you sign the new version with a different certificate, you must assign a different package name to the app—in this case, the user installs the new version as a completely new app.

https://developer.android.com/studio/publish/app-signing.htm...

If you want to install an update that was signed with a different private key, the app would need to be uninstalled first, which would also delete any sensitive data in private app storage.

This is enforced at the platform framework level, from what I loosely remember of scanning the AOSP source code.

Yes, Google could hijack packages sent to first-time downloaders. That's usually the downside with trust on first use. If the initial download isn't trustworthy, the whole verification scheme falls apart. It would be better off if Android had the APK equivalent of Certificate Transparency. That, and if Google Play made all developer-uploaded APK builds available to users, for awareness.

Re: Encrypted messengers: Riot, not Signal, is the future

#166

Post by sliken »

upofadown wrote: post #100
sliken wrote: post #95

Earlier quoted context omitted.

It's all well and good to run your own mail server. The biggest problem is 99% of who you send to/receive from will be in one of the big 3 mail servers.

I just had a quick look at a email list I run for a local sporting organization and it looks like the big 3 are less than 50% of addresses. There were a lot of local ISP addresses, businesses and educational organizations.

Are you basing the 50% based on what is after the "@", i.e. gmail.com and yahoo.com? Or are you looking at what server the MX points at. It's very easy to have your own MX for your domain point to a google mail server.

Re: Encrypted messengers: Riot, not Signal, is the future

#167

Post by Perceptes »

qznc wrote: post #110
NoGravitas wrote: post #36

Earlier quoted context omitted.

And an open replacement for Slack.

Yes. I don't see Signal and Matrix in direct competition, just like WhatsApp and Slack are not in direct competition. The technology is very similar (main difference seems to be the size of chat rooms), but the use case and marketing is very different. Signal/WhatsApp is for casual mobile texting, while Matrix/Slack is for working.

I think Riot is a better comparison to Slack than Matrix is. Riot is essentially the Slack experience built on the Matrix protocol, but Matrix can certainly work just as well for clients that present a Signal/WhatsApp/iMessage/SMS-style interface.

Re: Encrypted messengers: Riot, not Signal, is the future

#168

Post by Perceptes »

acqq wrote: post #11

> Riot is based on the so-called Matrix protocol which is a federated protocol > In addition, people are writing alternative clients to access the Matrix/Riot network, implementing their favorite features and workflows. As users can vote with their feet for their own interests and choose providers and apps of their liking Can I run my own network which is not part of other networks (i.e. not "federated")? Can I tell…

The Ruma homeserver implementation is specifically supporting this use case. The federation system will run as a separate application alongside the client-server API, so if you don't want to federate with other homeservers, you just don't run the federation component. https://www.ruma.io/

Re: Encrypted messengers: Riot, not Signal, is the future

#169

Post by upofadown »

upofadown wrote: post #86

After a recent discussion of the issues with XMPP on mobile, some obvious questions: 1. How well does Riot deal with changing network connections? Does it have problems when a mobile device switches between, say, WiFi and 4G? How well does it deal with a complete loss of connectivity? 2. How well does Riot deal with power management on mobile devices? Can it spend time in the background while getting message alerts w…

OK, I did a better search and found something relevant in the fricken Matrix FAQ:

* https://matrix.org/docs/guides/faq.html#i-installed-riot-via...

>I installed Riot via F-Droid, why is it draining my battery?

>The F-Droid release of Riot does not use Google Cloud Messaging. This allows users that do not have or want Google Services installed to use Riot.

>The drawback is that Riot has to pull for new messages, which can drain your battery. To counter this, you can change the delay between polls in the settings. Higher delay means better battery life (but may delay receiving messages). You can also disable the background sync entirely (which means that you won’t get any notifications at all).

>If you don’t mind using Google Services, you might be better off installing the Google Play store version.

Re: Encrypted messengers: Riot, not Signal, is the future

#170

Post by jdp23 »

Arathorn wrote: post #149
jdp23 wrote: post #2

Are there any plans to do a security audit on Riot? The useful report by NCC [1] looks at libolm (which implements the end-to-end encryption) but of course that's only part of the whole product. [1] https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-en...

Yes. Once the E2E implementation is fully finished and out of beta, and once we have a non-beta homeserver (as Synapse is still technically in beta, albeit very late beta), we'll be going to NCC and working out how to do an audit of the whole enchilada (homeserver + olm + matrix-js-sdk + matrix-react-sdk + riot-{web,ios,android}). This may well end up being broken down into separate components, much as the Olm audit…

Great to hear, thanks!
Post reply on HN