[JDEV] MUC problems

Thu Feb 13 09:05:09 CST 2003

David,

It's true that one of the requirements for JEP-0045 was to be compatible
with the groupchat protocol -- but not with the JCF protocol. As a matter of
fact, it was introduced because the JCF protocol was not extensible enough
and too complex. The SHA-hashed JID's simply weren't very useful.

As I mentioned earlier, if you want to have accountability, the best way to
do this within the spirit of the JEP is to have complaints sent through the
room as invitations currently are. The room can then send the real JID of
the offender to the owner/admin (even if he's offline). The owner/admin can
process the complaint at his/her leisure. What good will a SHA-hashed
version do if the offender is not on-line at the time the complaint is
received? You can't un-hash it to discover the culprit's identity. So, are
you going to add some complex logic into the server to notify an admin when
someone with a particular SHA-hashed JID (on a watch-list) comes on-line?
That seems more complex than a "dedicated reporting service".

And another thing: if you're in the room and I offend you, and I change my
JID, you can track me. But if I'm the least bit clever (and don't want to be
tracked), all I have to do is leave and come back in. This is, of course, a
good thing for anonymity (or semi-anonymity, whatever).

Constantin

> -----Original Message-----
> From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> Sent: Wednesday, February 12, 2003 9:51 PM
> To: jdev at jabber.org
> Subject: Re: [JDEV] MUC problems
> 
> 
> Hello,
> 
>   Part of the initial requirements of JEP-0045 was to provide backward
>   compatibility with the groupchat protocol.
> 
>   However, you are missing my point if you believe my issues are with
>   maintaining backwards compatability. This is important to 
> me, but not
>   the crux of my issue.
> 
>   The JEP already has the provision for room 
> owners/admins/moderators to
>   be able to view a persons real jid at all times. In MUC, there is no
>   such thing as a completely anonymous room, only semi-anonymous.
>   However, you have to also take real-world events into 
> place, and it is
>   not safe to assume that there will always be a room moderator+
>   available at all times. This was proven multiple times whilst an
>   earlier version of MU-Conference was running on jabber.org. 
> Even with
>   the enhanced abilities, if a troublemaker came on and there were no
>   admins around, there was nothing that could be done except to take
>   note of the SHA hash jid. 
> 
>   This issue is likely to come up again and again, so I have put this
>   mechanism in place to provide accountability whilst maintaining the
>   semi-anonymous environment. The fact that SHA hashes have 
> been used in
>   regards to users, not just in mu-conference, is a bonus. As I have
>   already pointed out, tracking a user when they keep changing nick is
>   easily done if you are already in the room. If abuse keeps 
> reoccuring,
>   then the SHA jid can be given to the admin, to allow them to be able
>   to tie events together. In areas such as Educational or Corporate,
>   where it is can be more damaging than just an acting up room member,
>   we have a safety mechanism in place.  
> 
>   There is no such thing as an anonymous room, and to be frank, there
>   can never be one. Say I am the server admin for a 
> conference service.
>   All I have to do is run the jabberd in debug mode, and I 
> know exactly
>   who you are and what you are sending/receiving. Likewise, the server
>   admin on the jabber server your client has connected to can do the
>   very same thing. 
> 
>   The current system is already far more secure than any of 
> the existing
>   conference/conferencing components which you can find out 
> anyones real
>   jid whether they want you to know it or not. If a user wishes to
>   inform an admin of an abuse, they can send the SHA version to the
>   admin, who can then note it and watch out for further abuses. A
>   dedicated reporting service is also out of the sphere of 
> this JEP, in
>   my oppinion, since it serves no use in other situations 
> where MUC can
>   be utilised, such as multi-way MSN conversations or in IRC gateways.
> 
>   If you wish, I can think about coding in a room option that would
>   allow people to disable the SHA hash jid if they really feel they
>   have to. I just want to allow people to have that choice, 
> rather than
>   say 'I can't see a reason for it, so why bother' I also want to be
>   able to offer this along with room message filtering to help expand
>   the potential userbase.
> 
> Regards.
> 
>   David
> 
> On Wed, Feb 12, 2003 at 02:00:58PM -0700, Constantin Nickonov wrote:
> > I understand what you're saying about backward 
> compatibility, David. This
> > wasn't the intent of MUC, but is not prohibited, either. 
> The problem is that
> > your implementation will likely become the de-facto reference
> > implementation, and future mimickers will attempt to stay 
> true to what you
> > do now. In the long run, the result will be confusing at 
> best. There's a
> > reason for the demise of the JCF protocol (for which there 
> isn't a JEP) and
> > the introduction of MUC.
> > 
> > The MUC protocol proposes a solid affiliation/role 
> hierarchy, and I submit
> > to you that even in anonymous rooms, the owner/admin (and 
> perhaps the
> > moderator) should still have access to everyone's real JID. 
> And so, any
> > channel abuse issues, with which you're concerned, can be 
> resolved without
> > employing an extra representation of the JID. And even if 
> you want to allow
> > users to file complaints against someone who's being 
> abusive while the cat
> > (admin, owner, etc.) is away, this can be accomplished via 
> a message that's
> > intercepted by the service a la invitations sent through 
> the room (MUC-0045,
> > section 6.6).
> > 
> > Furthermore, some anonymity is lost when you track a SHA-hashed
> > representation of a user's JID (which never changes) -- even between
> > sessions. One could easily argue that this representation 
> is every bit as
> > identifying of the user as his/her real JID. The idea 
> behind anonymity is
> > that a user can come into a room and no one knows who the 
> user is... not who
> > the user's been in the past... not anything about the user.
> > 
> > > -----Original Message-----
> > > From: jabber at dsutton.legend.uk.com 
> > > [mailto:jabber at dsutton.legend.uk.com]
> > > Sent: Wednesday, February 12, 2003 11:14 AM
> > > To: jdev at jabber.org
> > > Subject: Re: [JDEV] MUC problems
> > > 
> > > 
> > > 
> > > Hello Constantin,
> > > 
> > >   Yes, you can communicate via the SHA hash jid, if it is 
> > > enabled in the
> > > configuration. This was also the same behaviour in the 
> > > conferencing module
> > > available previously, and I know of people who have express 
> > > concern to me
> > > to keep the browse ability as compatible as possible. The 
> > > current method
> > > which I checked into CVS is the way that I want to keep it. 
> > > 
> > >   If you were in an anonymous room, then you would be able to 
> > > track when a
> > > user changes nick, and I want the same functionality in browse. 
> > > 
> > >   I would also say that although you currently see no reason 
> > > for tracking
> > > this way, it is a function that I would like, and can see 
> > > others needing in
> > > the future. This becomes especially true in cases of channel 
> > > abuse, and for
> > > that reason alone I believe that the SHA hash representation 
> > > for anonymous
> > > users needs to stay.
> > > 
> > > Regards,
> > > 
> > >   David
> > > 
> > > Constantin Nickonov writes:
> > > > 
> > > > > -----Original Message-----
> > > > > From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> > > > > Sent: Wednesday, February 12, 2003 2:57 AM
> > > > > To: jdev at jabber.org
> > > > > Subject: Re: [JDEV] MUC problems
> > > > > 
> > > > > 
> > > > > Hi there,
> > > > > 
> > > > >   I can understand your point as well, so have come 
> up with this
> > > > >   compromise. When you browse a room, the jid given will be 
> > > > > the room jid
> > > > >   + nick. What happens if you browse further depends on the 
> > > > > room. If the
> > > > >   room is unanonymous, or you are a room admin, then you 
> > > will see the
> > > > >   users real jid. If you are a normal user and not 
> > > allowed to see real
> > > > >   jids, then you will see the SHA hash jid version. That way 
> > > > > we keep to
> > > > >   the spirit of the jep, whilst allowing tracking of 
> user->nick
> > > > >   relations.
> > > > > 
> > > > >   This has been checked into the mu-conference cvs. Does this 
> > > > > sound good
> > > > >   to you?
> > > > 
> > > > And where else will the SHA-hashed version of the JID be 
> > > used? Can clients
> > > > send directed messages, etc., to the SHA-hashed version? I 
> > > really don't
> > > > see the need to "track people" in this way. In the end, if 
> > > the room is
> > > > anonymous, a user shouldn't really be "trackable" when in 
> > > it. If it's
> > > > non-anonymous, you have the real JID and don't need to 
> > > complicate things
> > > > (which you've already conceded).
> > > > 
> > > > The two-phase browse seems like a good idea, i.e., get the 
> > > in-room JID
> > > > from a room browse, and then dig deeper for the user's 
> real JID by
> > > > browsing to the in-room JID.
> > > > 
> > > > > 
> > > > > Regards,
> > > > > 
> > > > >   David
> > > > > 
> > > > > On Tue, Feb 11, 2003 at 10:28:55AM -0700, Constantin 
> > > Nickonov wrote:
> > > > > > I understand what you're trying to do. The problem is that 
> > > > > your methods
> > > > > > conflict with the intent of JEP-0045, which will eventually 
> > > > > result in
> > > > > > fragmentation of the standard, i.e., when two or more 
> > > > > implementations of MUC
> > > > > > accomplish the same thing in incompatible ways. Perhaps the 
> > > > > JEP should be
> > > > > > more specific when it comes to laying out the 
> 'jabber:iq:browse'
> > > > > > capabilities (which are being phased out in favor of 
> > > > > disco), but it seems to
> > > > > > me the re-introduction of SHA-hashing for this purpose is 
> > > > > not a good thing.
> > > > > > 
> > > > > > Sure, you can talk about race conditions, like when I 
> > > > > browse to get a list
> > > > > > of users and one of them chooses that moment to change his 
> > > > > nick, making my
> > > > > > subsequent user-level browse requests invalid. But why not 
> > > > > just return the
> > > > > > real JID (if it's allowed by the room) in the room-level 
> > > > > browse result?
> > > > > > Something like this:
> > > > > > 
> > > > > > SENT: <iq type='get' to='room at muc.server'>
> > > > > >         <query xmlns='jabber:iq:browse'/>
> > > > > >       </iq>
> > > > > > READ: <iq type='result' to='user at server/resource' 
> > > > > from='room at muc.server'>
> > > > > >         <conference xmlns='jabber:iq:browse' name='room' 
> > > > > type='public'>
> > > > > >           <ns>http://jabber.org/protocol/muc</ns>
> > > > > >           <user name='nick1' jid='user2 at server/resource'/>
> > > > > >         </conference>
> > > > > >       </iq>
> > > > > > 
> > > > > > In the case of an anonymous room, the 'jid' attribute could 
> > > > > be omitted (or
> > > > > > contain the in-room JID for that user, i.e., 
> > > > > 'room at muc.server/nick2').
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> > > > > > > Sent: Tuesday, February 11, 2003 8:59 AM
> > > > > > > To: jdev at jabber.org
> > > > > > > Subject: Re: [JDEV] MUC problems
> > > > > > > 
> > > > > > > 
> > > > > > > Hello there,
> > > > > > > 
> > > > > > >   We are both correct in this situation. The JEP 
> does define 
> > > > > > > how the jid
> > > > > > >   is to be handled for a presence packet, and 
> > > > > MU-Conference follows
> > > > > > >   that. You will never see the SHA1 string in a 
> > > presence packet. 
> > > > > > > 
> > > > > > >   On the other hand, the system of using an iq 
> request, xmlns
> > > > > > >   jabber:iq:browse, to discover the room roster is not 
> > > > > covered by the 
> > > > > > >   JEP. In order to maintain sanity, I have opted to 
> > > > > continue using the
> > > > > > >   existing methods. If you require to see the real jid, 
> > > > > and you are
> > > > > > >   allowed, then browsing the SHA1 resource will reveal 
> > > > > the true jid. I
> > > > > > >   have to use the sha1, since it allows you to track 
> > > the user more
> > > > > > >   consistantly - as I tried to explain before, I could use
> > > > > > >   'girls at conference.localhost/NICK' for the 
> nickname reported 
> > > > > > > by browse,
> > > > > > >   the problem is that if users swap nicknames, I 
> have no way 
> > > > > > > of knowing
> > > > > > >   that is what happened. The SHA1 string is unique to 
> > > that user.
> > > > > > > 
> > > > > > > Regards,
> > > > > > > 
> > > > > > >   David
> > > > > > > 
> > > > > > > On Tue, Feb 11, 2003 at 08:12:16AM -0700, Constantin 
> > > > > Nickonov wrote:
> > > > > > > > see below
> > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: David Sutton 
> [mailto:jabber at dsutton.legend.uk.com]
> > > > > > > > > Sent: Monday, February 10, 2003 8:51 PM
> > > > > > > > > To: jdev at jabber.org
> > > > > > > > > Subject: Re: [JDEV] MUC problems
> > > > > > > > 
> > > > > > > > <snip>
> > > > > > > > 
> > > > > > > > > The hex string is actually a SHA1 hash of the 
> users real 
> > > > > > > jid. Its used
> > > > > > > > > to reference a user, but not reveal the true jid. 
> > > If the room 
> > > > > > > > > is set up to allow people to see the real jid, then 
> > > > > just browse
> > > > > > > > > 
> > > > > > > 
> girls at conference.localhost/13c6a01dc31309e331c2b018640b9c03b85
> > > > > > > 34327 and
> > > > > > > > > it will show you the true jid. This also 
> helps to keep 
> > > > > > > compatability to
> > > > > > > > > existing clients that are used to this form with the
> > > > > > > > > groupchat/conferencing module. The real jid 
> is used as 
> > > > > > > the reference, as
> > > > > > > > > a person can keep changing their nick throughout a 
> > > > > > > session, but they
> > > > > > > > > can't change their real jid
> > > > > > > > 
> > > > > > > > The problem with this is that the MUC standard 
> (JEP-0045) 
> > > > > > > specifies how
> > > > > > > > nicknames are passed along with presence 
> information, and 
> > > > > > > how they are
> > > > > > > > changed -- and SHA-hashing isn't the way.
> > > > > > > > 
> > > > > > > > Entering a room (JEP-0045, section 6.2):
> > > > > > > > 
> > > > > > > >   SENT: <presence to='foo at muc.server/nick1'>
> > > > > > > >           <x xmlns='http://jabber.org/protocol/muc'/>
> > > > > > > >         </presence>
> > > > > > > >   READ: <presence from='foo at muc.server/nick1' 
> > > > > > > to='user at server/resource'>
> > > > > > > >           <x 
> xmlns='http://jabber.org/protocol/muc#user'>
> > > > > > > >             <item affiliation='owner' 
> > > jid='user at server/resource'
> > > > > > > > role='moderator'/>
> > > > > > > >           </x>
> > > > > > > >         </presence>
> > > > > > > > 
> > > > > > > > Changing the nick (JEP-0045, section 6.4):
> > > > > > > > 
> > > > > > > >   SENT: <presence to='foo at muc.server/nick2'/>
> > > > > > > >   READ: <presence type='unavailable' 
> > > from='foo at muc.server/nick1'
> > > > > > > > to='user at server/resource'>
> > > > > > > >           <x 
> xmlns='http://jabber.org/protocol/muc#user'>
> > > > > > > >             <item nick='nick2' affiliation='owner'
> > > > > > > > jid='user at server/resource' role='moderator'/>
> > > > > > > >             <status code='303'/>
> > > > > > > >           </x>
> > > > > > > >         </presence>
> > > > > > > >         <presence from='foo at muc.server/nick2' 
> > > > > > > to='user at server/resource'>
> > > > > > > >           <x 
> xmlns='http://jabber.org/protocol/muc#user'>
> > > > > > > >             <item affiliation='owner' 
> > > jid='user at server/resource'
> > > > > > > > role='moderator'/>
> > > > > > > >           </x>
> > > > > > > >         </presence>
> > > > > > > > 
> > > > > > > > The MUC protocol wasn't designed to be fully 
> > > > > > > backward-compatible with the
> > > > > > > > JCF draft.
> > > > > > > > 
> > > > > > > > Constantin
> > > > > > > > _______________________________________________
> > > > > > > > jdev mailing list
> > > > > > > > jdev at jabber.org
> > > > > > > > http://mailman.jabber.org/listinfo/jdev
> > > > > > > 
> > > > > > > -- 
> > > > > > > David Sutton
> > > > > > > Email: dsutton at legend.co.uk
> > > > > > > Jabber: peregrine at legend.net.uk
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > jdev mailing list
> > > > > > jdev at jabber.org
> > > > > > http://mailman.jabber.org/listinfo/jdev
> > > > > 
> > > > > -- 
> > > > > David Sutton
> > > > > Email: dsutton at legend.co.uk
> > > > > Jabber: peregrine at legend.net.uk
> > > > > _______________________________________________
> > > > > jdev mailing list
> > > > > jdev at jabber.org
> > > > > http://mailman.jabber.org/listinfo/jdev
> > > > > 
> > > > _______________________________________________
> > > > jdev mailing list
> > > > jdev at jabber.org
> > > > http://mailman.jabber.org/listinfo/jdev
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > jdev mailing list
> > > jdev at jabber.org
> > > http://mailman.jabber.org/listinfo/jdev
> > > 
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> 
> -- 
> David Sutton
> Email: dsutton at legend.co.uk
> Jabber: peregrine at legend.net.uk
> 