Modern XMPP project discussion - 2021-02-16

southerntofu, no

southerntofu, mod_muc_occupant_id does not disable pseudonymity, though, quite the contrary, it supports it

with widespread support for occupant-id, we could get rid of semianonymous MUCs and replace them with fully anonymous MUCs (where not even the room owners can see the real JIDs)

but that requires the occupant ID to be a viable moderation identifier, thus it must remain stable across nickname changes (otherwise we could just go with the nickname, which isn’t sufficient in all cases, for mostly technical reasons unfortunately)

(just to explain the idea behind occupant-id -- I don’t want to impose whether it’s suited for your usecase or not)

southerntofu: there is nobody _explicitly_ working on threat modeling, but usually the Council reviews and discusses security implications of new proposals

Ge0rG, though to be fair, anonymity/pseudonymity is rarely in the security considerations -- but this might be because we rarely get XEPs going in that direction

jonas’: it was the major reason why I disliked occupant id

Ge0rG, what exactly?

jonas’: the reduced anonymity and its implications

tradeoffs all the way down

Yeah, and there was no serious discussion of it

> but that requires the occupant ID to be a viable moderation identifier, thus it must remain stable across nickname changes (otherwise we could just go with the nickname, which isn’t sufficient in all cases, for mostly technical reasons unfortunately) I'm thinking it doesn't exactly need to be stable across nicknames. The MUC can cache (jid, nick, occid) n-uples for t time (5-10mn?). and if moderation is applied then MUC stills knows it. I think that's a good tradeoff

or even just tuples, (jid, occ-id)

Meaning it's not exactly a technical limitation

jonas’, b64encode(hmac_sha256(bare_jid, room._data.occupant_id_salt)) <-- unless you consider the JID to be pseudonymous (which it is in most cases, to be fair) there is no way occupant_id is pseudonymous because the id is deeply tied to the JID

once again i feel this is an acceptable tradeoff in most circumstances, however it GREATLY changes the threat model of MUCs without any consideration for that, rendering Nicks in MUCs effectively useless and tiable to the same JID

(before, the threat model was: i trust the MUC server to recognize me across Nicks, now the threat model is ANYONE can know i'm the same JID using different nicks in different circumstances, rendering the Nick system essentially useless)

Ge0rG, are these "Council" folks versed in security somehow? i mean security/privacy/pseudonymity is admittedly very specific concerns (and i'm not expert either)

southerntofu: I don't know. They are just random folks elected by the XSF members.

<sarcasm>no wonder folks are fleeing to matrix</sarcasm> ;) ;) ;)

we should probably have a privacy "team" reviewing stuff.. would anyone here would like to be part of that?

southerntofu: this place is mostly about usability and UX consistency. The XSF is the entity to consider security of the xmpp protocol. You might want to read up on the XSF and especially its council, and how to become a member there

well i didn't specially mean a team "from"/"for" modernxmpp, i agree this is a concern for the XSF (and i'm GENUINELY CONCERNED that this does not exist yet at the XSF) though i'm somewhat relunctant because they're highly bureaucratic and unwelcoming (source: i attended a few meetings to see if i could fit)

This is a concern for whomever decides to write specs for XMPP, if they want to, really :x

The XSF doesn't have a monopoly on XMPP specs.

southerntofu, mind that the council isn’t alone in deciding such things at all and will often work with feedback from the community

southerntofu, it is still pseudonymous, because you cannot map the occupant ID back to the JID. so while you cannot pick your "name" in the pseudonym, it does not allow tracing back to your real name

it is not anonymous, mind, because you are assigned a name you have no control over and which is linked to your identity via your JID

and whether it renders Nicks useless depends on what your use for nicks is ;)

I guess we can agree occupant-id removes a layer of pseudonymity

not for room admins

there it adds one

Not at the moment yes

adds?

sure

or, well, it can be used to add one

They still have access to the jid

they don’t have to anymore if we go further with occupant-id

It could be, right

you’re right, it’s not specified or implemented yet

(though, to be fair, a MUC could perfectly fake that today if it wanted to, with only minor quirks resulting from that. but then you’re also pretty much implementing yet another part of MIX, once more, in a more broken way) ✏

But that can already be done somewhat, without occupant-id. It's just that everybody ran away from fully anonymous rooms for unknown reasons. The nick race can be mitigated already, even without occupant-id

heh

I'm not even thinking about MIX though

And not exactly interested in talking about it just now either, that's yet another story

fair

jonas’, maybe MIX is indeed the way forward, i'm not aware of how widely it is implemented though

southerntofu, pretty much not at all

> A MIX channel MAY require that all participants publish presence, so that active channel participants are visible. It is not possible to enforce this in the server, so participants in a channel with this option MUST publish presence.

^ well that's weird, my client privacy settings should not be batrayed by this "MUST", though i would understand if a MIX room would not accept me without presence

This isn't a client privacy setting. If you don't want to publish presence don't join rooms that require presence, just like you wouldn't join a room that has public JIDs in MUC.

(assuming you can discover this in advance, which I'm pretty sure you can if I remember correctly how MIX works)

.. don't you think it's a bit like saying "don't go to a website with trackers" is a solution to the web tracking problem?

No

Presence is not the same as trackers.

presence information leaks metadata about when you're online to pretty much every one, so it makes sense for clients to disable it by default in my view

I disagree, it's a chat system and it's useful to know who is in a room when.

I'm not against having an invisible mode for some rooms, but others it makes sense to always require that visibility.

a server not letting me post because i didn't publish a presence, i understand.. but forcing my client to betray my expectations just to join a room? i don't understand

invisibility is yet another topic in my view, i may accept that a MUC server knows my JID, but wouldn't like it to know all my presence (disconnect/reconnect/afk..)

🤷 I don't know what to tell you, seems fine to me. Don't join rooms whos policies you disagree with. But especially if I'm developing a business focused chat like Slack or something I want to always know who's in all rooms at all times, so it makes sense ot have it as an option IMO.

as an option, yes.. meaning server may kick/reject members of the room who don't publish a presence

but here the spec goes the other way around for a reason i don't understand (why is it not possible server-side?)

Because if I'm developing a chat I don't want someone to join and get history and what not without publishing a presence, it just doesn't make sense to go through all the extra steps to let them join when I know I'm already going to kick them.

*developing a chat system that works the way I described, I mean.

The server can still kick people who aren't following its policies of course, but if you're going to have a setting there's not much point in not just enforcing it on the client side too

to me it makes perfect sense that your MUC server would hang the subscription while requesting a presence from the client, or deny the client's request to access history

Sure, and it will probably do that, but why not enforce it on the client side too?

well because it's different concerns: i want my clients to obey/serve me, you want your room to exclude certain behavior.. both are valid usecases, but forcing my clients to act against my intentions is user-hostile in my view

Your clients do serve you, either way you have to know not to join that room if you don't want to be kicked, or if you don't want to have your presence sent.

it's like if you said clients should be the ones preventing users from joining private rooms, no the server should take care of that :)

That's not what I said at all

eg. client providers user features, server provides access control

The server definitely still has to enforce its policies

then why does the spec say otherwise?

The spec does not say otherwise, it says what the client must do to have a good UX, not what the server must do.

The server obviously still has to handle clients that violate the spec, it always does.

> It is not possible to enforce this in the server, so participants in a channel with this option MUST (...)

that's what i don't understand: why is it "not possible to enforce this in the server"?

Oh I see what you're saying, I read that as "it's impossible to force a client ot send presence"

no, a phrasing like yours would have been pretty reasonable in fact :)

Actually, I'm not sure, I may be wrong, I'd need to go back and re-read this.

hmmm interesting nick registration in mix MISC

I can't remember what stuff gets automatically triggered by a join, there may be things you don't want to send to a client that doesn't send presence, in which case you can't do anything about the client that joins but doesn't send it

In which case you're right it's weird that it has to be enforced on the client

But I still don't see it as a privacy issue either way. No matter what you have to review a room in advance and not join one whos policies you disagree with

And it's not saying that you always have to send presence, just for rooms configured to require it.

i could see a "popup" for a client to let them know in advance a specific server does not match their privacy policy, and have a choice to join

Sure, I think that's a thing clients could do

it's just more complicated in terms of UI-UX to implement across clients, than a simple error message from the server rejecting you for not publishing certain information :)

I think I might have been wrong though, I think it really is impossible for the server to do this

i'm not far enough on the spec to tell (yet) :)

I can't remember what, and I can't go back and check right now, but I think it sends info on join (which is before your presence would be published), which is a problem if you don't want to allow people not to publish presence

I need to go back and re-read too though, there might have been a way for the server to just publish a fake "online" presence for you when you join or accept your presence as part of the join or something

Either way though, that MUST even if it doesn't make sense isn't a privacy issue as far as I can see.

i understand that it's not part of your threat model, but it's a valid usecase to fear repression from connects/disconnects revealing your identity to the political police

eg. we're using a server we trust in a foreign country, but our public chat was infiltrated by a police bot

Sure, but it's also perfectly valid to require it for some rooms, so don't join rooms that require it.

Which is what you'd have to do either way regardless of whether the server or the client enforces it.

if this police bot can have presence information from everyone, it can be correlated against subpoenaed ISP logs to find out who's who

which can lead activists to prison

Again, I get that, but this MUST doesn't change that either way.

without the server being compromised (that's specifically because of this last point that it's a privacy drawback)

well sure i'm not arguing against this usecase.. just like servers banning Tor, feel free to ban me from using your services because i like privacy, but i expect my client with Tor support to not silently drop Tor when conecting to a server who doesn't like Tor :P

That's a client issue though, not an issue with this MUST

The spec doesn't say "And privacy aware clients MUST NOT tell the user about this" :)

no, but it places the burden of complexity on client implementers, while dealing with it server-side SHOULD be trivial..

https://xmpp.org/extensions/xep-0407.html#usecase-user-invite <-- that's where we can add the OMEMO vetting bits i guess

If it's a privacy issue for you you *have* to deal with it client side.

Because a server could be buggy, or it could be malicious. On the other hand, if it's a server policy issue it should be dealt with server side (if that's possible, I'm still not sure). So if it's both, it has to be dealt with in both places.

yes but specifications should encourage privacy for all, not make it harder to implement :P

It doesn't make it harder to implement.

You'd have to impelment the same thing either way

sam, implementing new UI just for something like this is "harder to implement"

You'd have to do that either way if it's a thing you're concerned about

Unless you trust the server

well in my view the MUC/MIX threat model places a lot of trust in the server(s)

(not necessarily such a bad thing, though a pseudonymizing layer on user servers to prevent leaking JIDs to MUCs could be nice)

uggh, 46 pages, I forgot how long this had gotten, maybe I don't care enough to re-read this.

so yea invitation from inviter could include a special field to indicate the room mandates encryption, in which case the client (should they accept the invitation) should send their OMEMO public key BOTH in the join message, and in the acknowledgement

southerntofu: onion layering and random delays insertion also!

also white noise traffic generation!

so then the MIX server can request vetting for invitee's OMEMO key from the inviter's

i think anonymity is kinda out of scope for XMPP in fact, or is not among the top priorities at best

L29Ah, that was not part of my plan / threat model but sure that would be nice :)

All that being said, if your threat model is really state level actors that can access your ISP you need to change your behavior and not join random public MIX rooms. It doesn't really matter what the spec itself does.

if you want to hide your jid, you just register another one, and that would solve much more problems than MUC-based JID hiding

L29Ah, are you a contributor to the XMPP ecossytem? if so do you know a good place to talk privacy concerns?

sam, i wholeheartedly agree with you but the experience show people will do it anyway so we should account for that when building tools

jdev@ or xsf@ is probably fine. I don't know of any specific privacy focused rooms.

a tiny bit; i don't

this makes me think I should resurect Burner JIDs. I don't think it ever got any implementations.

it's just there are so many privacy-orienting chat protocols, and their market niche is small, that i'm not sure XMPP should concentrate in this direction

sam, nice i didn't know about this XEP! like email aliases for XMPP i love it !

in fact these days if you're federated, you're already well ahead of the IM crowd in terms of privacy

L29Ah, there's a lot of protocols out there but none to my knowledge has so many good clients on most platforms, and Jabber/XMPP is still the go-to platform for privacy-conscious folks because of Tor-friendliness and many people using it already

(also PGP, OMEMO..)

i'm not yet aware of XMPP servers that speak with both clearnet and onion/i2p jids btw

Element/matrix almost won over but is entirely unusable for people with less hardware (client & server)

L29Ah, the mapping is not done, but any prosody server can federate with .onion servers with mod_onions

but you can't (yet) have an account/resource/MUC that's exposed both as .onion and DNS addresses (and potentially others)

pep. started thinking about writing a prosody module for that (for the joinjabber MUC) but it's just an idea at the moment

(though in theory it should be really straightforward, i got it on paper :P)

yeah right now I'm mostly missing time :/