[Standards] MUC2 - The case for removing semi-anonymous
dave at cridland.net
Fri Jun 26 11:55:14 UTC 2015
On 26 Jun 2015 07:24, "Steve Kille" <steve.kille at isode.com> wrote:
> > I would like us to Get This Right, though. People have been mumbling
about replacing MUC for years, and I’ve always been resistant;
> > the discussions at the summit this year persuaded me that we finally
have requirements that MUC1 can’t easily meet, but I really do
> > not want us to do MUC2 now and MUC3 in 2017 to fix the stuff we got
wrong in MUC2.
> [Steve Kille]
> Kev - I strongly agree with this goal.
I think a key criterion for success will be if MUC2 can meet all commonly
deployed use-cases across both XEP-0045 and other multiparty chat
(including non-XMPP cases).
> It seems to me that the default semi-anonymous MUC1 is generally seen as
"the way MUC works" and is not a conscious option selection choice.
It's tempting to go that way, but it's very close to saying "I disagree
with the outcome, so the evidence must be wrong."
The problem is that the only evidence we have as to how desirable this
feature is is the number of chatrooms commonly using it. That *could*
easily be that it's the default in many servers, but that in turn raises
the question of why that's so.
In short, I don't claim to know, but I hesitate to ascribe all such use to
ignorance on behalf of the administrators.
What I can tell you is that when I asked about the Prosody default (it's
semi-anonymous), the response was that "we try to make the defaults privacy
friendly"; this implies that the default, at least, was a conscious choice.
I've a feeling that M-Link defaults the same way for the same reason -
maybe that's changed (and if not, maybe it should).
> I've not seen use where this behaviour seems particularly desirable. I
have seen significant customer concern about controlling mis-leading use of
nicks and people misrepresenting themselves in MUCs. I suspect that
non-anonymous would be better behaviour for many MUC users, but there has
not been active consideration to use it.
So what you're saying is that in all the chatrooms I'm usually in, only the
Openfire project leads have considered how to configure their chatroom? I'd
note for the record that I'm usually present in both Prosody chatrooms and
XSF chatrooms (xsf@ and jdev@), all of which are semi-anonymous. It seems
odd to me that anonymity is such a problem if the administrators there are
content to leave it in place - they're hardly unaware of "the way MUC
works". After all, many of those administrators are on this thread.
I think within government, military, and enterprise, strong identity is an
absolute requirement, but I'd note that "misleading use of nicks and people
misrepresenting themselves in MUCs" is soluble already by nickname
enforcement and registration, as part of XEP-0045. So if your customers are
concerned about that, you should show them that, as well as (of course) the
Finally, I'd note that under the semi-anonymous model, both the chatroom
itself and any administrators are fully aware of the real jid of the
occupant, and can act directly upon it - so the scope for abuse is limited
entirely to what the chatroom allows. (Unless the abuse is also possible by
> MUC2 will allow MUCs to allow users to read MUCs without sharing
presence. This seems a highly desirable option (lots of reasons). This
option will allow people to read MUCs anonymously, which I think for some
MUCs can be a sensible and desirable privacy option.
I don't think that the absence of presence means (or should mean) that
subscriptions are anonymous or invisible. Part of basic privacy would be
being aware of people reading your messages, even those messages to a group.
The only way to read such messages would be if the archive was available to
> I think that if you want to share your presence with the group or send a
message to a group, that enforcing that you also share your jid is highly
desirable. In XMPP the jid is "who you are". I can't see a clear use
case for allowing people to post to a MUC without clearly identifying
I absolutely agree that making non-anonymous "better" is highly desirable.
In a number of markets, and certainly in Isode's and Surevine's, "hiding"
the real jid behind an occupant jid is problematic, and the relative
obscurity of the real jid in MUC means that non-anonymous rooms are
somewhat of a second-class citizen. From a technical standpoint, having the
address of an occupant, and therefore the identity, selected by that
occupant causes a number of issues, including security ones.
However, just because non-anonymous is useful for some markets should not
preclude anonymity for others.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards