Because of abandoning support for 32-bit PCs, this bug in is unlikely to be fixed, and I may have to give up on trying to use the Wire desktop client on my 32-bit laptop:
github.com/wireapp/wire-deskto

So having convinced a bunch of my family and friends to set up accounts on Wire and install it, I may have lost the main thing that made it attractive (a desktop client for 32-bit GNU/ Linux where voice calls work properly). At what point do I just give up on trying to be a purist, and buy a 2nd-hand MacBook for comms (and video editing, and ... and ... and ...) :(

Follow

@alexl see the 2-3 length discussions I've had here over the year about chat apps. TL;DR Wire is on both client and server side, and has plans to support between Wire servers. is a downside, but they are ok with community-created clients without Electron to connect to their server (unlike , don't know about )

ยท Pinafore ยท 1 ยท 1 ยท 2

@strypey Telegram made a challenge and the best clients became the official ones: a Qt desktop client for Windows, Mac & Linux, two clients for Android, one for iOS, a web client and one specific for Mac, all Open Source, plus community clients including a CLI one. 200 mln of users, 15 bln of messages/day. E2E encrypted chats (optional) and calls.

@alexl @strypey ...but for some obscure reason, the server code is still closed source, even though they said they would open source it years ago. telegram.org/faq#q-why-not-ope

@stragu @strypey

Obscure reasons? telegram.org/faq#q-why-not-ope

Keeping Telegram fast and secure while switching to a federated architecture is a tech challenge. See Matrix, it's the state of the art of decentralized instant messaging and can't deal with Telegram's performance.

@stragu @strypey

"Our architecture does not support federation yet. Telegram is a unified cloud service, so creating forks where two users might end up on two different Telegram clouds is unacceptable. To enable you to run your own Telegram server while retaining both speed and security is a task in itself. At the moment, we are undecided on whether or not Telegram should go in this direction."

@paulfree14 bullshit and fake news, I'm tired of answering people who share that page on GitLab.

@alexl if parts of what is linked are false, the other arguments still stand.

So it remains: telegram is not to be trusted.

@paulfree14 there is not a single argument against Telegram, they took the best decision in every case.

@alexl @strypey but making it open source doesn't mean switching to a federated architecture, the official apps can still prefer the official servers. The idea was to open source it for people to review it and reuse the code creatively.

@alexl @stragu no, it isn't. is much more advanced than when it comes to server performance. But what's key is whether the company recognises that having servers they control at the centre of the entire service is a bad idea () or not. Wire does. Telegram hasn't even released their server code.

@strypey XMPP and Matrix are two totally different things, check Matrix's FAQ section on XMPP

@strypey there is no point in releasing server-side code for an instant messaging platform if there isn't support for server federation. It's just a marketing thing, no benefit from security point of view

@alexl

Yeah, I've begun to think of that sort of architecture as being a vehicle for its developer's own "performative software freedom".

@strypey

@deejoe @alexl the benefit is it allows the whole system to be studied independently, including for security audits. You can stand up your own version of the server, check it for backdoors, and see whether messages are actually secure when you connect clients to it. It also gives the user community the freedom to run their own service for private use, and to fork if the original developer is exposed as a bad actor. So it's quite important.

@deejoe @alexl imagine how much work could have been saved in building the if FB or the birdsite released their whole server stack under AGPL.

@strypey zero, there is no value in Facebook/Twitter codebase... Reddit was Open Source, but its federated version, Prismo, is being built from scratch

About Wire, I specified "instant messaging" because using your own server mean you and your contacts need to trust the same server managed by you or one of your contacts that maybe don't know each other... so at that point is better to trust a third-party company like Wire that has low interest in your conversations...

@strypey ...and even if independent developers can audit the code and make it more secure you still need to trust Wire because you have no idea of what they are running on their servers. They could run a branch of the Open Source repo with optimized performance, with additional security holes... so the important part in e2eE systems is just clients being Open Source and secure

@alexl @strypey open-sourcing doesn't necessarily mean switching to a federated architecture, it should be trivial for the Telegram developers to restrict the official clients to the official servers, even if others open new servers based on the original code. What it _would_ allow though, is some public review of the quality of the code, to check for code quality and confirm the privacy claims. And it would allow others to creatively re-puprose, and learn from their valuable work.

@alexl @strypey Telegram server is still closed source and they went for an ICO. I'd rather not deal with any of that.

Not to mention their CEO is a libertarian who thinks throwing money in the street is a fun way to pass time:โ€‰https://www.huffpost.com/entry/pavel-durov-russian-millionaire-throws-money-paper-planes_n_1557404

@alexl @strypey @jalcine yet, telegram's crypto is rubbish, and the ux dangerous, as most people have no idea that messages go unencrypted by default ยฏ\_(ใƒ„)_/ยฏ

@tethre @strypey @jalcine OK use e2e encryption to message with yourself, I have to message real people in real world and they are all on Telegram, where I can start e2e encrypted chats with them

@jalcine willdo, sorry. Only just saw this after I sent that last post.

@alexl @strypey @jalcine i'm not saying "don't use telegram", but *recommending* it, for whichever reasons, is actually dangerous, so please don't do it ๐Ÿคท

@tethre @alexl @strypey @jalcine if I had a buck every time someone claims that Telegram "messages go unencrypted by default"...

@alexl sure, but all the code use on the server-side is proprietary. If you can't audit the server, you can't guarantee the the client claims to offer. If I was willing to compromise on to reach more people, I'd use . Unlike with social media (when used for activist purposes), I don't care about reach. All I want to do is voice chat with people I already know, and we can use email and other tools to agree on which chat app to use.

@strypey
> If you can't audit the server, you can't guarantee the #E2E the client claims to offer.

?! The entire point of e2e encryption is that you can't trust the server... Open Source clients are enough

@alexl @strypey #Telegram client gets Diffie-Hellman configuration from the server via core.telegram.org/method/messa but performs only a probabilistic check of received parameters, see github.com/DrKLO/Telegram/blob and github.com/DrKLO/Telegram/blob
Probabilistic check is only enough if *you* have generated the prime. If you receive it from a potentially malicious server, the server can simply generate a lot of insecure parameters and select the one that will pass the check. Telegram is bad, use #Signal protocol

@alexl Why not? Just in case, Signal protocol means you can use XMPP+OMEMO or whatever, just something with sane crypto. Telegram simply does not have secure E2E. Bad verification, no warnings on key change, keys regenerated for each call, huge vulnerabilities indistinguishable from backdoors found in the past (in Russian, with comments by Nikolay Durov, @W_K: habr.com/en/post/206900/ ), and now this Diffie-Hellman vulnerability exploitable by the server.

@alexl Its Olm protocol is based on the Signal and it was audited matrix.org/blog/2016/11/21/mat So it is good enough from the security and FOSS point of view, just need to check if current usability is satisfying for you. My only concern is the lack of self-destructing messages and lack of secure defaults (too easy to create insecure chat etc.) so you should rely on your peers not to accidentally backup the conversation to google disk etc.

@wire what about Wire? It's annoying that their desktop clients are just the web client in an wrapper, but the is excellent. Any idea how robust their crypto is?
@alexl

@strypey @alexl Their crypto is basically a copy of the Signal protocol. OWS even forced them to publish it under GPL license even though they wanted to publish it under permissive license.

Their key management is way worse. You have to manually confirm each device of your contact. It's way harder than scanning one QR-code per contact. So in practice you will see that your contacts have one or two unconfirmed devices. They can verify them for themselves but there is no way propagate this trust.

@wire
> OWS even forced them to publish it under GPL license even though they wanted to publish it under permissive license.

Citation please? Given how much pressure had to be put on Signal to release their own source, and the discussions I've had about licensing with folks from Wire on GH issues, I'm sceptical.
@alexl

@strypey @alexl medium.com/@wireapp/axolotl-an

OWS wants every open implementation of the Signal protocol to be under the copyleft license (GPL), so they can continue selling their own implementation to WhatsApp under proprietary-friendly license.

@wire if that's true (citation please?), it could mean gets a big chunk of its funding from FB, just as Mozilla got (gets?) a big chunk for goOgle. Worth keeping in mind when analyzing their tech decisions and public statements.
@alexl

@strypey @alexl It is not secret, it is on their blog: signal.org/blog/whatsapp-compl

As for RedPhone story, I was not aware of it. Looks like its server was indeed closed source, I did not follow them back then.

@wire I see various comments there about a "partnership" between and . I see no mention of money changing hands, in either direction, or how much. Unless I'm not reading carefully enough, and missing that bit?

@strypey @alexl
> Given how much pressure had to be put on Signal to release their own source

I don't think there were ever problems with the Signal source code. The problem was making them publish protocol specifications, now available at signal.org/docs/
Yet it is quite obvious, if you follow Signal development, that they don't publish their internal design documents. Major features, such as sealed sender, are announced when their development is already finished.

@wire perhaps I'm getting confused between , , and . From what I remember, Moxie liberated the Signal client source before setting up , but resisted releasing the server source for some time, claiming there was no point. Just as he still claims there's no point replacing Google Play Services in mainstream Signal, or distributing the Android client in , or supporting between servers. Some people discussing this in 2016:
whispersystems.riseup.narkive.
@alexl

@strypey @alexl Their desktop client is not only a wrapper. It constantly tries to auto-update the internal JavaScript code, so even if you build desktop client from the source, the crypto code is simply downloaded from their website, so it is no better than using a web version. Can't find a reference in the source code quickly, but see the reply by lipis (wire app developer) here: github.com/wireapp/wire-deskto

@alexl @strypey e2e encrypted chats are available only on android and iOS though. Telegram Desktop, while being pretty nice, seems to not support instant view and encrypted chats at all

@alexcleac @alexl all Wire clients have E2E turned on by default, including the desktop clients.

Sign in to participate in the conversation
Mastodon - NZOSS

This Mastodon instance is provided gratis by the NZ Open Source Society for the benefit of everyone interested in their own freedom and sharing with others. Hosting is generously provided by Catalyst Cloud right here in Aotearoa New Zealand.