Description of feature:
Full-anonymous rooms, as previously described in 0045, (and then removed).
Motivation:
The idea is that only the component really needs to know the realjid of the person it's talking to, the rest doesn't. MUC admins operations should be allowed on the in-room JID.
There might be more things to take into account, but nothing coming to mind atm.
MattJ
on
Any use cases for this? Maybe the admins shouldn't be admins if you don't trust them with JIDs?
pep.
on
The use case is privacy. muc admins shouldn't need access to realjids to perform administrative operations. You will know better about the feasability of this feature, I am just trying to remove information where it is not needed.
I heard this was supported in previous versions of prosody/mod_muc, btw.
Jonas Wielicki
on
This would require a concept like proxy JIDs in MIX-ANON. At which point you can use MIX-ANON.
Otherwise, operations like banning an occupant are a race condition since they operate on nicknames. An occupant which changes their nickname quickly will be un-bannable (just like they’re un-kick-able currently).
Jonas Wielicki
on
Ugh, I recall a lengthy discussion. The situation could (and probably should, in case of fullanon) be improved by rate-limiting nickname changes (possibly to an extent where changing the nickname is not allowed at all). This would give moderators/admins time to act in case of an abuser.
Requests which go against a nickname which has just left or rejoined the room still need to be considered though. "just left" can be handled with a short-lived cache of (nickname->real JID) pairs to allow retro-actively banning a user which just left. "just joined" should probably not allow the ban unless the nickname belongs to the same real JID which is already found in the cache.
This still leaves open the attack vector of leaving and joining repeatedly with different nicknames. This can be prevented by keeping a list of recently-left real JIDs and apply rate-limiting on rejoins.
All in all, this is a rather complex thing which probably miniscule use. But it can be done, sure.
pep.
on
I would argue this should be the default, but I already see haters arriving in numbers.
If you really want to annoy people in a room, SASL EXTERNAL is also a thing, and you'll need the support of your operator anyway.
pep.
on
SASL ANONYMOUS, not EXTERNAL.
pep.
on
> All in all, this is a rather complex thing which probably miniscule use. But it can be done, sure.
As said in prosody@, for me the minuscule use-case is rather on the kick/ban end. As an admin of some rooms for quite some time now, I have never had to use them. And if I had to, eg spamwave, that would require the server admin in most cases anyway.
Also, I still have to use the GDPR card from my hand.
Description of feature: Full-anonymous rooms, as previously described in 0045, (and then removed). Motivation: The idea is that only the component really needs to know the realjid of the person it's talking to, the rest doesn't. MUC admins operations should be allowed on the in-room JID. There might be more things to take into account, but nothing coming to mind atm.
Any use cases for this? Maybe the admins shouldn't be admins if you don't trust them with JIDs?
The use case is privacy. muc admins shouldn't need access to realjids to perform administrative operations. You will know better about the feasability of this feature, I am just trying to remove information where it is not needed. I heard this was supported in previous versions of prosody/mod_muc, btw.
This would require a concept like proxy JIDs in MIX-ANON. At which point you can use MIX-ANON. Otherwise, operations like banning an occupant are a race condition since they operate on nicknames. An occupant which changes their nickname quickly will be un-bannable (just like they’re un-kick-able currently).
Ugh, I recall a lengthy discussion. The situation could (and probably should, in case of fullanon) be improved by rate-limiting nickname changes (possibly to an extent where changing the nickname is not allowed at all). This would give moderators/admins time to act in case of an abuser. Requests which go against a nickname which has just left or rejoined the room still need to be considered though. "just left" can be handled with a short-lived cache of (nickname->real JID) pairs to allow retro-actively banning a user which just left. "just joined" should probably not allow the ban unless the nickname belongs to the same real JID which is already found in the cache. This still leaves open the attack vector of leaving and joining repeatedly with different nicknames. This can be prevented by keeping a list of recently-left real JIDs and apply rate-limiting on rejoins. All in all, this is a rather complex thing which probably miniscule use. But it can be done, sure.
I would argue this should be the default, but I already see haters arriving in numbers. If you really want to annoy people in a room, SASL EXTERNAL is also a thing, and you'll need the support of your operator anyway.
SASL ANONYMOUS, not EXTERNAL.
> All in all, this is a rather complex thing which probably miniscule use. But it can be done, sure. As said in prosody@, for me the minuscule use-case is rather on the kick/ban end. As an admin of some rooms for quite some time now, I have never had to use them. And if I had to, eg spamwave, that would require the server admin in most cases anyway. Also, I still have to use the GDPR card from my hand.