Live data from Hacker News

XMPP: The secure communication protocol that respects privacy

notes.nicfab.it

121–130 of 160 posts

Re: XMPP: The secure communication protocol that respects privacy

#121
post #80

Earlier quoted context omitted.

the omemo support in pidgin is just through a plugin, as with many recent XEPs. i think people tend to forget that pidgin's focus is being a multi-protocol messenger. it ships with XMPP support, but that mostly includes the base. i wrote that omemo plugin and tbh I am pretty burned out. so many moving parts, it's hell to debug and i'm not even sure where to go next with it. (plus people keep talking badly about pidgi…

> i think people tend to forget that pidgin's focus is being a multi-protocol messenger. That's what's great about it and part of the reasons i think blocking Pidgin would be very wrong. > i wrote that omemo plugin and tbh I am pretty burned out. Thanks for that work! Maybe you could start by writing about your burnout on the README to encourage other people to contribute/maintain, or at least be less demanding of yo…

>Thanks for that work! Maybe you could start by writing about your burnout on the README to encourage other people to contribute/maintain, or at least be less demanding of you?

you're welcome! :D that sounds like a good idea, at least so people know i am not planning to abandon it even if i'm slow. i don't think people are demanding, i just feel bad that despite my best efforts it just doesn't work for some.

>Do you think this is specific to your plugin? To OMEMO? Or to pidgin plugins in general? Personally, i find it very challenging to write correct code in C, and i can only imagine the pains pidgin developers have to come through to make so many networks/protocols inteoperate.

in fact it's mostly related to your last point. there's just so many moving parts to this decentralized system: the os, installed libaries, exact version of the plugin, exact version of pidgin (or rather the underlying libpurple), the version of the used xmpp server, the version of the module implementing the XEP on the server, the version of the client on the other end, and how exactly that client implemented OMEMO and other XEPs in combination (e.g. the order of elements or their attributes in the received or sent xml).

right now there is a persistent bug that some omemo xml element cannot be parsed, and based on the input taken from the debug log i cannot reproduce it in unit tests, and i don't even know where to begin, and why it doesn't seem to affect other clients. also, persistent discovery issues that from my end don't look like a problem, and yet this plugin is the only one having these problems. i believe other clients must spam those discovery messages just in case, i didn't verify that yet though :)

>If you have some reading about your experiences, what lessons we can learn, and maybe some project (whether internal to pidgin or not) to implement them, i'd be interested to read.

i don't, but maybe i should write it down! venting in this reply already helped a lot, thank you :D

>I don't think anyone feels really let down. Some people are not aware of just how experimental certain things are and so they get disappointed but life goes on. You however should take care of your mental health and not let maintenance burden and heartless cyber-ranters like me affect your mood and taste for computing i got some helpful lessons out of it either way, so i definitely don't regret it. a big part of it is what i already tried to say in my last post: i'm mostly not sure where to go with that project.

Re: XMPP: The secure communication protocol that respects privacy

#122
As a former XMPP fan, I think XMPP is extremely interesting in light of Moxie's recent web3 post [1], and most specifically the part:

> A protocol moves much more slowly than a platform. After 30+ years, email is still unencrypted; meanwhile WhatsApp went from unencrypted to full e2ee in a year.

You could replace email with XMPP in that sentence. (In fact, I'd bet Moxie was specifically thinking of XMPP when he wrote that.)

I remember when Google introduced voice/video, and provided a library (libjingle) to help other clients add the feature. It never really got picked up. Perhaps it was the state of the driver ecosystem at the time that made it hard for clients to reliably support such streams (PulseAudio was still new at the time, and GStreamer wasn't as mature), that was in excess of what open-source maintainers could provide.

Google eventually decided (reasonably, in retrospect and IMHO) it was easier to turn its chat into its own platform than try and drag a protocol with it. They were certainly dealing with problems that no-one else did. For example, they were very late to enable federation, much to the annoyance of the community, because Google had to deal with spam at a scale no-one else did, and wanted to make sure they had the protocols to deal with that, which no-one else in the community wanted to deal with.

(Of course after that I cannot give Google any credit for their chat client merry-go-round, and they've burned any goodwill I had for them on that front! [2] )

Perhaps we'll reach a point where the feature-set for a chat client will settle, and once again a federated protocol can emerge. I no longer believe XMPP is it.

[1] https://moxie.org/2022/01/07/web3-first-impressions.html

[2] https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-...

Edit: that said, I think XMPP had a lot of great ideas, and I'm glad it still pops up now and again.

Re: XMPP: The secure communication protocol that respects privacy

#123
post #106
post #80

Earlier quoted context omitted.

the omemo support in pidgin is just through a plugin, as with many recent XEPs. i think people tend to forget that pidgin's focus is being a multi-protocol messenger. it ships with XMPP support, but that mostly includes the base. i wrote that omemo plugin and tbh I am pretty burned out. so many moving parts, it's hell to debug and i'm not even sure where to go next with it. (plus people keep talking badly about pidgi…

Having built upon your work and used it as a reference myself, I appreciate the effort dude :)

i'm glad to hear it was helpful to you! what kind of project did you make?

Re: XMPP: The secure communication protocol that respects privacy

#124

As a former XMPP fan, I think XMPP is extremely interesting in light of Moxie's recent web3 post [1], and most specifically the part: > A protocol moves much more slowly than a platform. After 30+ years, email is still unencrypted; meanwhile WhatsApp went from unencrypted to full e2ee in a year. You could replace email with XMPP in that sentence. (In fact, I'd bet Moxie was specifically thinking of XMPP when he wrote…

A particular subset of the XMPP story I want to share is that back in the mid-00's, the XMPP folks were trying to make it the protocol of the real-time web. I think that was a laudable goal.

One thing they particularly feared was for the web to become HTTP-only, with all the overhead that entails.

How prescient.

Re: XMPP: The secure communication protocol that respects privacy

#125

As a former XMPP fan, I think XMPP is extremely interesting in light of Moxie's recent web3 post [1], and most specifically the part: > A protocol moves much more slowly than a platform. After 30+ years, email is still unencrypted; meanwhile WhatsApp went from unencrypted to full e2ee in a year. You could replace email with XMPP in that sentence. (In fact, I'd bet Moxie was specifically thinking of XMPP when he wrote…

I'd bet he was thinking of this whole back and forth (blog posts, conference talk) with Matrix: https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom

Re: XMPP: The secure communication protocol that respects privacy

#126
post #95
post #70

Earlier quoted context omitted.

At the time of reception, the Signal server knew that there was a message from a certain IP to a certain recipient. If the message was put in the queue, the originating IP was forgotten. Once the message is delivered, the recipient is forgotten. EDIT: Signal can totally be used through Tor, so the IP can be hidden from Signal. As neighbor comments have said it still knows at that moment that a message from you is sen…

> EDIT: Signal can totally be used through Tor, so the IP can be hidden from Signal. For a centralized service like Signal, your IP doesn't matter, they own your account, literally. You can randomize it as much as you like, and your peers may too, in the end it will not hide from them who sent a message to whom and when.

Nope. As we already discussed, Signal has no idea who sent messages with Sealed Sender. The recipient finds out who sent them a message, but Signal does not.

Re: XMPP: The secure communication protocol that respects privacy

#127

The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message only if enabled and working). What about other crucial security features, see https://www.eff.org/deeplinks/2018/03/building-secure-messen... ? Then, XMPP is described as "privacy respecting" mostly because you can use a nickname instead of a phone number for…

XMPP supports additional security if the server and client support it, however some of the extension proposals (XEPs) are deferred or experimental. My hope that the Special Interest Group (SIG) for encryption pulls these together into new high-security client and high-security server profiles.

* https://xmpp.org/extensions/xep-0380.html - Explicit Message Encryption

* https://xmpp.org/extensions/xep-0429.html - Not a XEP really, but the formation of a SIG to explore a more robust end-to-end encryption support

* https://xmpp.org/extensions/xep-0420.html - Encrypting content specific to certain extensions

* https://xmpp.org/extensions/xep-0290.html - Digital signatures in XMPP

Re: XMPP: The secure communication protocol that respects privacy

#128
I can't even convince security professionals to install Signal, let alone something that requires installing a specific client configuration that may not be identical across platforms. If it's not e2ee by default I'd rather just stick to my current social graph.

Re: XMPP: The secure communication protocol that respects privacy

#129
post #4

Encryption is "activily bein worked on", sound about right - I never got encryption to work across two of my own devices with a third party. Yet I do not understand why a rewrite of messaging as [matrix] was necessary, when XMPP was already there and matrix did not even have an edit-message feature on release, perhaps not even now.

Perhaps the real distinguishing factor of Matrix isn't its technology, but its governance. Instead of an extensible, plugin-based approach like XMPP, Matrix has just a single "official" spec that can only be extended by amending the spec itself. IIRC this was one of the motivations behind Matrix's inception. As to whether one approach is better than the other is left as an exercise to the reader :) But having each ap…

Most things in matrix are namespaced. The official spec namespace is 'm', as in 'm.text', but you can extend it very liberally by just adding keys like 'com.github.mr_johnson22.matrix.foo'

Re: XMPP: The secure communication protocol that respects privacy

#130
post #125

As a former XMPP fan, I think XMPP is extremely interesting in light of Moxie's recent web3 post [1], and most specifically the part: > A protocol moves much more slowly than a platform. After 30+ years, email is still unencrypted; meanwhile WhatsApp went from unencrypted to full e2ee in a year. You could replace email with XMPP in that sentence. (In fact, I'd bet Moxie was specifically thinking of XMPP when he wrote…

I'd bet he was thinking of this whole back and forth (blog posts, conference talk) with Matrix: https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom

The story of E2EE on Matrix seems like a pure vindication of Moxie's concerns about protocol ecosystems, since it took years for them to get from an E2EE design everyone agreed on and that was working in clients to a point where they could default that E2EE on for users, because of popular straggler clients.
Post reply on HN