Modern XMPP project discussion - 2022-02-07

There has been lots of NGI funding around many open-source XMPP projects

i wonder if we can get funding to finally have a reasonable functional e2ee group chat experience, and then just through that cash at a couple of clients. Thought most of the work is already done, but just not yet enough to reach the desired goal of "reasonable functional e2ee group chat".

lalsab: does any client has e2ee group chat actually? Or you mean omemo?

oh I mean using omemo in group chat.

Ah okay. So basically we are missing a way to manage keys in group chats i am guessing

Maybe a fault to lerant way ti encrypt evenif you cant encrypt to all users of the group

> Ah okay. So basically we are missing a way to manage keys in group chats i am guessing That's the main issue. One is about the trustworthiness of the published keys, the other is about publishing keys so that they can be used anytime, but only by those part an e2ee chat. conversations and gajim make your key public afaik, but to anyone that requests. Dino doesn't make the key public for privacy concerns and only publish it to your contacts.

> Maybe a fault to lerant way ti encrypt evenif you cant encrypt to all users of the group that is required too, so that an invitation to a user who's offline atm, doesn't break the chat experience for others who might join later. ✏

inputmice is against that, but I can't make sense of it: >There is still a slight unsolved problem with users who have been added to rooms that have never been online before. But the only solution to that problem would be to ignore not being able to retrieve keys. And if we do that we might accidentally ignore non existing keys. And that's not desirable. In general (and with the exception of that one particular case) Conversations should not silently ignore errors. https://github.com/iNPUTmice/Conversations/issues/3081#issuecomment-633089859 It's not desirable to drop such an error silently, absolutely agree. There should a short warning if such issue appears.

Pop up: "sorry, but the key from $jid is unknown. You can wait with posting your message until the person comes online, or you post it now and $jid won't be able to receive it."

> that is required too, so that an invitation to a user who's offline atm, doesn't break the chat experience for others who might join later. minor correction: it only effects for users that are offline and don't host their keys publicly.

So it seems that its a client/ux problem to me. Dino's idea to have keys not being public sounds good. Another default to change for next conversations

Would a web of trust work instead? With contacts or omemo keys for signing? lalsab

Actually I'm planning to fix this on the server side

In sniket? How? MattJ

By preventing adding MUC members who don't have keys

Instead queue them, and add them to the member list when they have keys

So if i got this correctly: If not all members are online and getting the keys, nobody can send a message?

That's how Conversations works, yes

The server-side solution will make that behaviour never appear

Good idea

I assume there is gonna be a message in sniket to let the user know?

Not sure there is anything Snikket-specific here

well the deferred join is going to be weird

A join attempt to an encrypted group without published keys will return an error

It's not the join that's deferred, but the member list change

I agree that may be weird, but not universally

I have plans to expose the pending state in an upcoming XEP

right

.oO(some people would prefer to first see a XEP for the push stuff though)

That's probably sooner in my queue 🙂

The pending member list is part of a couple of MUC evolution XEPs I've been mentally drafting for a while

did you say MIX?

Absolutely not

I'm councigally obgliged to ask ;)

Why not MIX? MattJ

But yeah i think it needs rome kind of message. Otherwise the user will think its an error

> By preventing adding MUC members who don't have keys > Instead queue them, and add them to the member list when they have keys how will this look on the client side? If an invitation results in a user not appearing in a list of (invited) users, a user might expect there is an error/bug.

Issues that remain with your proposal: (obviously it's not intended or expected to be a one thing fixes all) key exchange. A dino user would need to add anyone to their contacts before being able to write. And conv and gajim fix the underlying issue by making private information public.

Do you have a reference for Dino not making this public?

Does Dino not support OMEMO in MUC?

It does afaik

But yes you need all the muc members in roster (including yourself?)

>At some point prosody started to allow Pubsub requests through MUCs, even through semi-anonymous MUCs. If we'd make the OMEMO device list public, it would mean that people can be linked and potentially identified across MUCs by any other member although they think they're semi-anonymous. There's also an additional issue that attackers can find out whether an account exists using those OMEMO nodes, but the MUC deanonimization issue is the bigger one IMO. If prosody would stop forwarding Pubsub requests, I think we'd be fine with making the device node public. (Or did I miss something and prosody stopped doing that?)

post from fiaxh:

a comment from larma: >Zash, the point is rather that we don't need generic PEP support in MUCs, the only thing people really are interested in is Avatars. So I'd rather want to provide some method for Avatars in MUCs that would allow me to have a different Avatar in one MUC than another (or no Avatar in some MUCs). And as we do this, we could also properly spec room avatars (which IIRC use vcard-temp right now). Accessing PEP through MUC also requires both users to be in the room at the time you want to access the PEP node / avatar, which may cause issues of Avatars not being displayed.

MattJ: take a look af the Dino MUC there's a debate concerning this going on.

> Does Dino not support OMEMO in MUC? it does support OMEMO. But only between users that added each other as contact afaik.

> Would a web of trust work instead? With contacts or omemo keys for signing? lalsab this is something I'd like to have as it helps to pass on keys and assign trustworthyness to them. It can allow a user to fetch a unknown key from just anyone who has it already. But it will not solve the issue, when no body can offer the missing key yet.

Avatars already provide a way to link users across MUCs, and I can show a dozen other ways that require no help from the server

Under my proposal for server-side verification of OMEMO keys, Dino users would never be able to join an encrypted MUC

I'd argue that this is the correct behaviour

If you can't guarantee they will be able to read messages anyway, it's better they don't join than have a terrible experience

> If you can't guarantee they will be able to read messages anyway, it's better they don't join than have a terrible experience ...and make by that a terrible experience for anyone else.

MattJ: I wouldn't be that categorical. Sometimes I wish I was able to send messages anyway in this kind of group chat, otherwise there is actually no way you can tell other it doesn't work (already from downgrading, which I'm not sure many users would know that's what is needed)

Also there are still cases where people in the room can't read messages because heisenbugs (Siskin, but not just) and yeah it's annoying but we deal with it

unless downgrading*

unfortunate Dino is the only GUI client for desktop that's somewhat acceptable. (gajim sends for example files over unencrypted jingle in an e2ee session, unless they fixed that recently. While they do not comunicate such known issue well to their users, I don't trust them taking privacy as an important value)

lalsab: jingle file transfer in MUCs? I doubt that ;)

in 1:1

(this is about MUC, not 1:1)

no, this was just giving an example, how gajim has an carelessly implementation which makes me to not trust it at all.

I can't make security audits and gajim does not have one, so I judge based on information easy accessible.

MattJ: what would you propose to Dino devs?

> Also there are still cases where people in the room can't read messages because heisenbugs And I'm on a mission to stomp out any of these issues, so that stuff like this just works 100% of the time

Part of the solution to that is not allowing known-broken situations to occur, by failing early instead of just allowing the user to experience some weird situation they don't understand

At the end of the day it will be up to server owners to enable this. It will of course be enabled in Snikket if it works well. I don't mind Dino users not being able to join Snikket-hosted encrypted MUCs if it prevents the chats from breaking horribly.

They would get a join error, with <text>

How do you tell a user that their client hasn't generated keys in a way they understand and are able to remedy to that ✏

is there a snikket client for linux?

No

I'm not that surprised tbh, but there isn't an obvious way atm to change one's PEP node public status.

So if you tell users they can't because Dino. Other they learn that maybe gajim allows that, or they delete their account and recreate one with not-Dino :/

Which is an awesome experience

(At this point they need a lot of courage not to go away :))

I can't be responsible for the opinions of the Dino devs - they are choosing not to follow every other implementation in this regard

I understand they have their reasons, but what they have done is break a totally valid use of XMPP (group chat with non-contacts) with no working solution

Maybe there are reasons and we can stop banging our head against the wall and walk together in another direction ✏

I'm open to hearing other solutions, but if there are none, I'm obviously just going to do what I think is best

I'm not sure enumeration attacks is the answer to all our problems either, but surely it's an answer ✏

Council just refused a change based on this ✏

Loosening XEP-0030 you mean?

Yeah

Sure, it's a tricky one

council refused to change a *final* document because there was a less intrusive way to express what was needed.

I haven't seen the resolution. I only saw the "nope"

as council member, I'd kindly ask you to not make such shortened statements about rationales.

PEP affiliations, allowlist the group when joining, get OMEMO via MUC IQ routing, ???, PROFIT!

jonas’: don't get up on your high horse, mistakes happen

Zash, all of this is a possible solution that the Dino devs could implement today if they want to

and would work under my proposal

Might be an option

But they also want us to block queries to PEP nodes. We could do that in semi-anon only perhaps.

Fwiw poezio creates the node open but doesn't change permissions if it already exists, it just ensure it does permanently

But why would we allow avatars through, when they allow fingerprinting too?

Don't? :p

You can not publish one

Same rationale to me

You can not publish OMEMO, or keep it private

So I don't see why we should do "deep inspection" for this case just because avatars are shiny and ought to work

Yeah no they shouldn't work either IMO

Right. So everyone has different opinions. Same old story :)

It would be nice if you could disable iq routing

Luckily everything in XMPP is open and configurable, which is why Snikket becomes valuable - stuff just works

Zash, sure, I'm not opposed to making it optional

I think other implementations allow that

bbiaf

Is the iq routing discoverable?

We even have an open feature request. Just haven't been done. Patches welcome

Ok

Growing the access list would mean tracking affiliations of every muc right, and keeping in sync.. I guess implementations anyway do that to some extent though to send encrypted messages

MattJ: FYI, in the Dino channel I explicitly mentioned that I also don't want to get rid of avatars as a way of fingerprinting (by allowing to select different avatars per MUC and not using the users personal node / vcard for semi-anon MUC avatars anymore)

as someone who had his avatar leaked to places where it shouldn't have gone and where I can't seem to get rid of it anymore, I approve.

Publish avatars to the MUC, like some sort of pubsub service?

That's a MIX!

larma, and what do you propose to do about OMEMO?

OMEMO in semi-anon MUCs?

OMEMO in non-anonymous MUCs with strangers

If they're strangers, how do you know they're not an attacker? Also, nothing stops you from making your PEP node readable to the members of a non-anon MUC that you don't have subscription with

except keeping that in sync is terrible

I have started having a thought that maybe we could fix that with bookmarks

jonas’: we can make an extension to pubsub such that you can add "members of MUC x" to acl

larma, if they're strangers then of course you don't know who they are (regardless of protocol or encryption methods)

But I don't think that's a valid reason to not support encrypted group messaging where not everyone already knows each other

encrypted messaging for data hygiene vs. encrypted messaging for actual security purposes

People do TOFU/BTBV all the time, I don't see why it differs whether the conversation is 1:1 or group

I feel we should have obvious switches for that. Kind of like EV vs. normal certificates in TLS. ✏

larma, what about > PEP affiliations, allowlist the group when joining, get OMEMO via MUC IQ routing, ???, PROFIT!

OMEMO doesn't scale to larger groups anyway, so we need something like megolm (ratchet per room instead of ratchets per user pair) and that something probably doesn't strictly need access to everyone's personal OMEMO public keys ✏

larma, MLS?

I'm not talking about group size

Zash: seems like a hack compared to explicitly allowing members of room x

Y'all should join https://datatracker.ietf.org/group/mls/about/ and make sure it doesn't end up only being implementable for WhatsApp, Wire and Matrix

MattJ: the larger the group the more likely it is to have strangers. In your small family group you want to have subscription with all the group members anyway

larma, no, managing a bare JID allowlist is really complicated

what about multiple MUCs you're in? you have to sync it to the union of those MUCs all the time, whenever membership(! not presence) changes

that's crazy effort

Maybe not, if the MUC tells you about affiliation changes

Zash, then you still need to check whether that JID is member in *any* of the other MUCs you're in where you want OMEMO to be allowlisted ✏

and what if the user added that JID manually to the node in the first place, and the peer only coincidentally joined one of those MUCs? ✏

jonas’: no, I didn't mean to copy the member list to my personal nodes allow list, I meant to explicitly put a "members of MUC x" on the allowlist and then the pubsub service would verify if, at time of request, the requestee is a member of MUC x

That's where we could invent a Bookmarks 2 extension

jonas’: and yes, I'm aware that current pubsub can't do that

Current MUC spec also can't do IQs, so what

It does describe IQ to full JID, and implementations have supported IQ to bare for certain payloads as a de-facto standard for literally decades

Except it works differently in various non-standard ways.

I.e. ejabberd handles vcard requests to the full JID.

(unless that changed recently)

They implemented it the "wrong" way at first, and afaik they just never removed that handling to the full JID

But I'm pretty sure ejabberd's mod_muc now operates the same way as Prosody's (and other servers)

It is not specified thus it would also be fully valid to have a MUC that routes the IQ back to the sender. Be prepared to see you own avatar with every user in a MUC ;) ✏

There are other de-facto standards around, it's more sensible to document them than go against them in silly ways :)

If a server dev reflected them back to the sender, they would quickly see that avatars don't work

In lieu of a standard, doing what works is obviously the best approach

We just have standards so that "what works" is clear and interoperable

MattJ: I'd say we don't have standards for IQ in MUCs. Some don't do them, some send them to bare jid, some send them to (a perceivably randomly picked) full jid of the user and some send them to different jids depending on the IQ payload. That's not a de-facto standard, that's a mess.

"It works with $thing"-development.

Maybe we can agree on: 1) We disable IQ routing for semi-anon MUCs by default. You can still enable it on non-anon MUCs because they likely don't cause unintentional data leaks there. 2) We build something new for avatars in semi-anon MUCs where avatars are stored with the MUC server and users can pick a different avatar for each MUC. Probably want to make a mapping from 0421 occupant-ids to avatar hash and then have a 0084-like pubsub node on the MUC jid to fetch avatars by hash.

In the long term, sure. I'm pretty sure people are not going to want to live without avatars until the network is fully upgraded to this new standard though...

Given that previous versions of common servers leaked your JID or a hash thereof when sending IQs, I'd question if people want to send IQs in semi-anon MUCs if they are not certain the MUC server does not leak their JID...

Luckily, most people don't know these things

Disable avatars and they'll quickly find out :)

(and switch to Matrix, where avatars work... and your address is always visible to everyone in groups you join)

(and possibly to everyone not on Matrix as well)

Fwiw in some of my circles we just don't do avatars.. So that'd be a plus

(Just to counter the "everybody wants avatar". I'd say "your use-case wants avatars)

Sure

I'm totally open to a flag to disable MUC IQs in Prosody

EverybodyWants(X):- False.

But the average server/user is not going to enable that

Me too. Patches welcome!

MattJ, not sure about that "switch to Matrix". All the users I know that tried Matrix and did not stick with it did so because they did not want their address to be shared with all members of groupchats

I'm totally open to write patches :) I just need a slightly different situation so I can invest time in all that

And I need to take a walk while the sun is shining!

https://share.bouah.net/M3x3OrR7GTP1ggDl/gHJG_z0PRWWndATMyeYEcw.jpg

Zash: Sunny pictures ^

What the lack-of-snow?

https://cerdale.zash.se/s/c2hQh88IQxXqPCNctZ4AObFD/27zlaLISTZeQOTptxdp-mw.jpg

> But I don't think that's a valid reason to not support encrypted group messaging where not everyone already knows each other people might know each other irl. Someone makes a group chat and sends invites. Not everyone has everyone in their contact list. This breaks chat experience until everyone adds at least every dino user.