Live data from Hacker News

Technology preview: Private contact discovery for Signal

signal.org

161–169 of 169 posts

Re: Technology preview: Private contact discovery for Signal

#161
post #154

Earlier quoted context omitted.

> I don't see why a messaging service like Signal cares about mutual friends. Signal doesn't care; users care about mutual friends. Here's an example: - Alice installs Signal². She has many contacts, and doesn't know which contacts also use Signal². Notably, she doesn't want to give the Signal² servers all of her contacts. - Alice asks Bob to install Signal². He does, and they trade key information (e.g. via SMS, ema…

Users also won't see contacts who use Signal and do have mutual friends in common, but who simply haven't used Signal to talk to those mutual friends. Your solution is certainly better than nothing, but it relies on people having actually used Signal to talk to each other in the past. It also appears to involve a lot of P2P coordination. And while it may not share contacts with the Signal servers, it does leak your a…

> Your solution is certainly better than nothing, but it relies on people having actually used Signal to talk to each other in the past.

Well, it is trying to incentivise Signal² usage:-)

> It also appears to involve a lot of P2P coordination.

Not necessarily a huge amount, I think — folks could SMS/email stuff as well as trade contacts face to face, depending on their risk preferences.

> it does leak your address book to all of your friends

Only where there are overlaps: since it's private set intersection, Alice & Bob only see their mutual acquaintances, not other folks. But yes, the mutual-thereapist issue exists. Presumably an expert mode might enable folks to whitelist/blacklist particular contacts when they're added.

Certainly, there are ways in which this approach is worse & more complex than the current Signal approach, but it is better in another way: it preserves privacy from Signal (and its hosting provider, and Intel, and any government which can coërce Signal, its hosting provider and/or Intel into subverting security).

Re: Technology preview: Private contact discovery for Signal

#162
post #149

Earlier quoted context omitted.

Clearly you're not the target market for Signal but there are many encrypted messangers out there for you.

I'm not so sure about that. Matrix is the closest thing, and that has a code quality that makes me want to puke. EDIT: Before I get complaints from the Matrix devs again that I’m bad-mouthing their app: ObjectOutputStream is NOT a suitable implementation for a "database": https://github.com/matrix-org/matrix-android-sdk/blob/736643...

What about XMPP with OMEMO? I know it's not the latest hype but has decentralized usernames.

Re: Technology preview: Private contact discovery for Signal

#163
post #149

Earlier quoted context omitted.

Clearly you're not the target market for Signal but there are many encrypted messangers out there for you.

I'm not so sure about that. Matrix is the closest thing, and that has a code quality that makes me want to puke. EDIT: Before I get complaints from the Matrix devs again that I’m bad-mouthing their app: ObjectOutputStream is NOT a suitable implementation for a "database": https://github.com/matrix-org/matrix-android-sdk/blob/736643...

Any project made up of hundreds of repos has bad areas which you can cherrypick if you want to bad-mouth, especially whilst still it's very actively in dev. For instance, conversely on iOS we have four different local store API implementations[1] ranging from in-memory, flatfile (via NSKeyedArchiver), CoreData and Realm. The equivalent work just hasn't yet happened on Android; PRs welcome.

Once again, why not invest your time in doing something more productive than spreading FUD about Matrix?

[1] https://github.com/matrix-org/matrix-ios-sdk/tree/master/Mat... and https://github.com/matrix-org/matrix-ios-sdk/tree/master/Mat...

Re: Technology preview: Private contact discovery for Signal

#164

Earlier quoted context omitted.

I'm not so sure about that. Matrix is the closest thing, and that has a code quality that makes me want to puke. EDIT: Before I get complaints from the Matrix devs again that I’m bad-mouthing their app: ObjectOutputStream is NOT a suitable implementation for a "database": https://github.com/matrix-org/matrix-android-sdk/blob/736643...

Any project made up of hundreds of repos has bad areas which you can cherrypick if you want to bad-mouth, especially whilst still it's very actively in dev. For instance, conversely on iOS we have four different local store API implementations[1] ranging from in-memory, flatfile (via NSKeyedArchiver), CoreData and Realm. The equivalent work just hasn't yet happened on Android; PRs welcome. Once again, why not invest…

> Once again, why not invest your time in doing something more productive than spreading FUD about Matrix?

Because I’m already investing my time in improving IRC, and there’s little time left after that.

> spreading FUD about Matrix?

Every criticism of mine you’ve admitted to be true, yet call it FUD still. Even this one you admit that there is significant amounts of bad code in Matrix, just argue that other projects have as much. That’s no excuse.

> The equivalent work just hasn't yet happened on Android; PRs welcome.

So why did this happen in the first place? This isn’t even just bad code – someone spent significant amounts of work and time (far more than would’ve been spent for using existing solutions such as Realm) on this. And there’s many pieces of the Matrix code just like that.

Re: Technology preview: Private contact discovery for Signal

#165

Earlier quoted context omitted.

Any project made up of hundreds of repos has bad areas which you can cherrypick if you want to bad-mouth, especially whilst still it's very actively in dev. For instance, conversely on iOS we have four different local store API implementations[1] ranging from in-memory, flatfile (via NSKeyedArchiver), CoreData and Realm. The equivalent work just hasn't yet happened on Android; PRs welcome. Once again, why not invest…

> Once again, why not invest your time in doing something more productive than spreading FUD about Matrix? Because I’m already investing my time in improving IRC, and there’s little time left after that. > spreading FUD about Matrix? Every criticism of mine you’ve admitted to be true, yet call it FUD still. Even this one you admit that there is significant amounts of bad code in Matrix, just argue that other projects…

The FUD is saying "Matrix's code quality makes me want to puke" and then cherrypicking a non-representative example. Android may still use flatfiles as the work needed to switch simply hasn't happened yet (it's a one person team handling the whole platform), but both iOS & JS SDKs show the opposite picture (iOS with 4 stores; JS SDK supporting 3 different stores; in-memory, localStorage and indexeddb).

So, please back off. We wish IRCv3 and your projects the best; please stop spewing negativity about us.

Re: Technology preview: Private contact discovery for Signal

#166

Earlier quoted context omitted.

> Once again, why not invest your time in doing something more productive than spreading FUD about Matrix? Because I’m already investing my time in improving IRC, and there’s little time left after that. > spreading FUD about Matrix? Every criticism of mine you’ve admitted to be true, yet call it FUD still. Even this one you admit that there is significant amounts of bad code in Matrix, just argue that other projects…

The FUD is saying "Matrix's code quality makes me want to puke" and then cherrypicking a non-representative example. Android may still use flatfiles as the work needed to switch simply hasn't happened yet (it's a one person team handling the whole platform), but both iOS & JS SDKs show the opposite picture (iOS with 4 stores; JS SDK supporting 3 different stores; in-memory, localStorage and indexeddb). So, please bac…

That was a representative sample of the code quality on the Android side.

The problem isn't in flat files, it's in "serializing" to the flat files by dumping the objects directly from memory. Specifically, Java's native serializer is used, which serializes types and constructors in a non+portable way. There are fucktons of people that get this wrong, every second RCE in JavaEE was due to this. It's long deprecated. You use it as only storage backend.

Files written that way can't be reliably read on different android versions, or different devices.

Reading such files back in basically allows anyone with write access to the files to execute whatever they want in your process, because it also serializes constructors.

The problem isn't flat files, but that whoever wrote that code has never had any experience with security critical code.

I can easily provide hundreds more examples of this. Race conditions that lead to private messages being sent unencrypted. Bugs that cause full crashes due to code errors. Horrible messaging performance with tons of low hanging fruit.

All this would be fine were this a random flashlight app.

But if an app with a focus on secure messaging fucks up the secure part and the messaging part, then it's definitely not something I'd want to use. I've got apps of my own that I've worked on daily for 3 years that have similar code quality — but guess what, I haven't released them, because of this code quality.

With secure messaging, you can't release first and iterate later, you actually need to build a secure solution from the first version on.

The fact that you apply Silicon Valley mentality to secure messaging makes it already problematic. If your company needs to iterate or pivot, you can. But once your data's been sent unencrypted, it's gone.

And the fact that you also don't even notice the problem with this code even when I'm pointing you directly at it makes it even worse, because it makes your project even less trustworthy.

Re: Technology preview: Private contact discovery for Signal

#167

Earlier quoted context omitted.

The FUD is saying "Matrix's code quality makes me want to puke" and then cherrypicking a non-representative example. Android may still use flatfiles as the work needed to switch simply hasn't happened yet (it's a one person team handling the whole platform), but both iOS & JS SDKs show the opposite picture (iOS with 4 stores; JS SDK supporting 3 different stores; in-memory, localStorage and indexeddb). So, please bac…

That was a representative sample of the code quality on the Android side. The problem isn't in flat files, it's in "serializing" to the flat files by dumping the objects directly from memory. Specifically, Java's native serializer is used, which serializes types and constructors in a non+portable way. There are fucktons of people that get this wrong, every second RCE in JavaEE was due to this. It's long deprecated. Y…

We know the issues around ObjectStreams and rehydrating constructors; mad gadget style vulns etc. But this is a local cache of trusted data which can only ever be touched by the app, and if an attacker is starting to mess around with your app's file storage you are already in a pretty bad situation. And, as I said, this is a placeholder for a proper DB.

In terms of whether "release and iterate" is unacceptable for secure messaging: we make it abundantly clear that the privacy protecting features are still in development and are beta quality and shouldn't be used for anything where privacy is critical. Meanwhile the idea that secure messaging products shouldn't be publicly beta'd prior to a formal GA (especially for stuff as complex as decentralised e2e crypto) feels weird at best.

If you've found fatal crashes or races in the E2E UX, please do the responsible thing and chuck an email to security@matrix.org rather than bragging about non-specifics here. Finally: Matrix's projects span a little bit more than just the Android SDK, which is admittedly mid-development still. So yes, there's loads of low-hanging optimisation work to be done and some areas of crappy code, but that's not remotely the whole picture.

Re: Technology preview: Private contact discovery for Signal

#168

Earlier quoted context omitted.

That was a representative sample of the code quality on the Android side. The problem isn't in flat files, it's in "serializing" to the flat files by dumping the objects directly from memory. Specifically, Java's native serializer is used, which serializes types and constructors in a non+portable way. There are fucktons of people that get this wrong, every second RCE in JavaEE was due to this. It's long deprecated. Y…

We know the issues around ObjectStreams and rehydrating constructors; mad gadget style vulns etc. But this is a local cache of trusted data which can only ever be touched by the app, and if an attacker is starting to mess around with your app's file storage you are already in a pretty bad situation. And, as I said, this is a placeholder for a proper DB. In terms of whether "release and iterate" is unacceptable for se…

[deleted]

Re: Technology preview: Private contact discovery for Signal

#169
post #100

Earlier quoted context omitted.

> In my opinion the signal ios client is significantly less polished than the telegram client. I could convince my girlfriend to switch to telegram, after she found signal to be intolerable on her android device as well. My reaction is the opposite. I love the signal iOS app because it doesn't try to do SMS. It lets you enter the code which is great if I want to use a Google Voice number instead of a carrier number (…

You think the Signal app is more polished than the Telegram app?!

I have very limited experience with Telegram. I was comparing Signal for iOS vs Signal for Android. Sorry for the confusion.
Post reply on HN