[JDEV] MUC problems
David Sutton
jabber at dsutton.legend.uk.com
Fri Feb 14 11:26:48 CST 2003
Hello Constantin.
Thank you for the complement. I do value your input and have taken it
on board. I believe that there is probably better ways out there, but
also feel that this comes under the MUC Services JEP.
I still think SHA hash is a valid method, but it will be optional and
easy to disable ;)
Regards,
David
On Fri, Feb 14, 2003 at 09:44:38AM -0700, Constantin Nickonov wrote:
> I'm sorry if my responses have sounded over-bearing. I, too, have talked to
> the JEP author (and have some experience with implementing the JEP-0045
> protocol). It's pretty clear that we both believe in what we're saying, and
> it's not a bad thing to have a little passion. If it's not implicit in my
> responses, you are to be commended for your efforts. Perhaps this discussion
> should've taken place on the foundation mailing list, as a more formal "call
> for experience" exchange.
>
> In any case, the best thing about Jabber is its extensibility. I just wanted
> to go on record with some points of view -- just as you did -- for the
> benefit of others who may be looking to implement MUC. It was never meant to
> be dismissive or as a personal attack.
>
> I still maintain that accountability can be achieved without SHA-hashes,
> however. :)
>
> > -----Original Message-----
> > From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> > Sent: Friday, February 14, 2003 9:18 AM
> > To: jdev at jabber.org
> > Subject: Re: [JDEV] MUC problems
> >
> >
> > Hello,
> >
> > On Fri, Feb 14, 2003 at 08:26:05AM -0700, Constantin Nickonov wrote:
> > > OK, I'll try one more time to make the point that
> > SHA-hashes are useless and
> > > counter-productive...
> > >
> > > 1. Useless
> > >
> > > If a room is not (semi)anonymous, participants have access
> > -- via either
> > > browse or disco -- to the other participants' real JID's.
> > So why not just
> > > use that to "track" nick changes? After all, the SHA-hash
> > is a direct
> > > derivative of the JID.
> > >
> > This is common sense, and there would be no hash.
> > >
> > > If a room is (semi)anonymous, noting the SHA-hash of an
> > offensive person's
> > > JID doesn't do a whole lot of good -- not for the person
> > doing the noting,
> > > and not for an administrator who receives the complaint.
> > SHA-hashing is a
> > > one way street, so there's no good way to deduce the real
> > JID and take
> > > action. Sending complaints through the service (like
> > invites), however, is
> > > an option that allows the real JID to be added to the
> > complaint (by the
> > > service) and passed on to the admin.
> > >
> > If you read my previous postings more carefully, I already
> > explained how
> > this would work. The aim is to provide a link for administrators to be
> > able to tie events together. A room admin who purely reacts to one
> > message from a user, without witnessing the event themselves,
> > it someone
> > I would be worried about. An abuse may be a one-off event,
> > and in which
> > case the admin won't have to do anything. However, if an abuse takes
> > place whilst an admin is online and available, they can then tie this
> > event to other events that they had been informed about.
> >
> > Also, sending complaints through the service is outside the
> > scope of the
> > JEP. We are talking about a specific application using the
> > MUC protocol,
> > not the MUC protocol itself. It was always noted that there would be a
> > requirement for a MUC Services JEP, once the MUC JEP was
> > finalised. What
> > I am providing is the possibility for people to have some protection
> > now. I've already said I can make this into an option, so your
> > overbearing attitude is confusing me. I subscribe to the view
> > that there
> > is more than one way of doing something, and look forward to a formal
> > specification for extending MUC with Services, however at the
> > same time,
> > there is still likely to be some switch hidden away to allow the hash
> > jid to be enabled for those who want to use it. I would also like to
> > point out that it will not be you fielding support calls or people
> > wanting a mechanism such as this in place for accountability.
> > My aim is
> > to provide flexibility, which is why I agreed to make it a switch.
> > >
> > > 2. Counter-productive
> > >
> > > If a room is (semi)anonymous, the SHA-hash reveals the
> > identity of everyone.
> > > Sure, it doesn't give away their true JID so that people
> > can send spam to
> > > them, etc. But it allows context to be established, where
> > none is desired.
> > > The resource portion of a SHA-hashed version of a user's
> > JID may be (unless
> > > you're concatenating the room JID to the user's JID prior
> > to hashing) the
> > > same in every room, which opens a can of worms. Also,
> > ordinary, non-abusive
> > > people cannot change their nicknames and avoid being
> > tracked -- contrary to
> > > the definition of "anonymous".
> > >
> > > If a room isn't (semi)anonymous, then... see section "1. Useless".
> > >
> > One thing of note is that there is no such thing as a fully anonymous
> > room. This is the point I tried to bring up earlier, and obviously
> > failed. Let me ask you this question. What is wrong with
> > being, at least
> > in part, accountable for your actions? If you are abiding by the rules
> > of the room, there is no reason for anyone to even bother looking. If
> > you are not, then there is a reason to check. This technology could
> > quite easily be used in forums for younger children, where you want to
> > provide a safety mechanism to protect the children against potential
> > abuse. This time of scenario is why room message filtering is
> > on my todo
> > list as well.
> > > ---
> > >
> > > There's nothing wrong with a MUC implementation supporting
> > both disco and
> > > browse, even though the latter may be removed from the JEP
> > at some point.
> > >
> > The thing is that you could have fooled me with the way that
> > you do not
> > seem to take my points fully on board before telling me i'm blatently
> > wrong. A discussion is a two way street, and I have made concessions
> > trying to provide a balance or half-way point.
> >
> > I personally asked Peter Saint-Andre to review this thread,
> > when he had
> > time, because I value his input and he is also the JEP
> > author. I removed
> > browse because things were not clear and I was investigating how to
> > ensure that I followed the spirit of the JEP. I also stated
> > that I would
> > re-enable browse as an option once everything is cleared up. I'm sorry
> > that you seemed to have missed those points I made.
> >
> > Regards,
> >
> > David
> >
> > > > -----Original Message-----
> > > > From: David Sutton [mailto:jabber at dsutton.legend.uk.com]
> > > > Sent: Thursday, February 13, 2003 10:40 PM
> > > > To: jdev at jabber.org
> > > > Subject: Re: [JDEV] MUC problems
> > > >
> > > >
> > > > Hello all,
> > > >
> > > > I've spent some time thinking about this over the evening.
> > > >
> > > > On Thu, Feb 13, 2003 at 03:01:33PM -0600, Peter Saint-Andre wrote:
> > > > > First of all, the question here is related more to browse
> > > > implementation
> > > > > than MUC implementation. Unfortunately, the browse
> > > > specification is not
> > > > > consistent with usage such as this:
> > > > >
> > > > > <iq
> > > > > type='result'
> > > > > id='1011'
> > > > > to='xxx at localhost/coccinella'
> > > > > from='girls at conference.localhost'>
> > > > > <conference xmlns='jabber:iq:browse' name='girls'
> > type='public'>
> > > > > <ns>http://jabber.org/protocol/muc</ns>
> > > > > <user name='mats'
> > > > >
> > > > jid='girls at conference.localhost/13c6a01dc31309e331c2b018640b9c
> > > > 03b8534327'/>
> > > > > </conference>
> > > > > </iq>
> > > > >
> > > > > The browse JEP (which is incomplete) does not seem to allow
> > > > <conference/>
> > > > > as a root element for the jabber:iq:browse namespace (there
> > > > is no DTD or
> > > > > schema so we can't be sure, but it appears that <item/>
> > is the root
> > > > > element and as we know only one root element should be
> > allowed). In
> > > > > addition, it does not define <user/> as a child element
> > of the root
> > > > > element. So I would say that the above stanza is
> > > > questionable from the
> > > > > perspective of browse.
> > > > >
> > > > I will review the browse and see if it is possible to
> > return with a
> > > > result which follows the meaning of the JEP. The existing
> > method was
> > > > used to provide compatability to the existing conference
> > > > system running
> > > > on jabber.org.
> > > > >
> > > > > Second, given the ambiguities involved in browse, it
> > may behoove the
> > > > > author of JEP-0045 to remove all references to browse and
> > > > require support
> > > > > for disco only. However, I am loath to do so until disco
> > > > goes to Draft, so
> > > > > it is possible I will hold off on submitting JEP-0045 to
> > > > the Council until
> > > > > disco is advanced to Draft.
> > > > >
> > > > Until the debate on browse reaches some stability, i've
> > removed the
> > > > browse code from the MU-Conference cvs. I've already
> > heard from people
> > > > who feel that it is a bad idea to remove browse, as it
> > > > already has place
> > > > in many of the existing clients. Another expressed
> > concern that disco
> > > > made it more complicated to retrieve the data necessary.
> > What I may do
> > > > is make browse an optional extra which can be enabled or
> > > > disabled at the
> > > > service admins choice. If I do this, then the SHA hash idea (for
> > > > representing a users true jid, not roster entry) may also be
> > > > an option.
> > > > I really perceive this being of use in certain situations, even if
> > > > others may not yet.
> > > > >
> > > > > Third, I would agree with Constantin that the hashed
> > > > resource in the 'jid'
> > > > > attribute in the stanza shown above is inconsistent with
> > > > the spirit of
> > > > > MUC. Note example 10 in version 1.3 of JEP-0045:
> > > > >
> > > > I think that the issue is being slightly missed here. the
> > response to
> > > > disco#items already does report in the syntax given
> > below. The current
> > > > debate about SHA hash jids is in relation to browsing for
> > a users real
> > > > jid, not for a room roster. I had already rewritten
> > browse (and disco
> > > > iirc) so that for the room listings, it reported them in
> > the format
> > > > roomname at service/nick. Only browsing a user for their true jid in
> > > > semi-anonymous rooms returned a hash, to provide a form of
> > > > accountability. Does this make the point I am trying to
> > make clearer?
> > > >
> > > > On the issue of disco, I also recall a debate going on
> > > > because the exact
> > > > details of what items were to be returned was not
> > defined. There are
> > > > several possibilities, such as room roster, member list,
> > > > moderator list,
> > > > admin list and so on. Was a decision made on which data should be
> > > > returned, and if there was a way to return any of the other
> > > > information
> > > > via the disco interface?
> > > > >
> > > > > Example 10. Room Returns Disco Item Results (Items are Public)
> > > > >
> > > > > <iq
> > > > > type='result'
> > > > > from='darkcave at macbeth.shakespeare.lit'
> > > > > to='hag66 at shakespeare.lit/pda'
> > > > > id='disco4'>
> > > > > <query xmlns='http://jabber.org/protocol/disco#items'>
> > > > > <item jid='darkcave at macbeth.shakespeare.lit/firstwitch'/>
> > > > > <item jid='darkcave at macbeth.shakespeare.lit/secondwitch'/>
> > > > > </query>
> > > > > </iq>
> > > > >
> > > > > In this instance, the user information is public and the
> > > > implementation
> > > > > returns each user's room JID (not a hash).
> > > > >
> > > > > If user information is *not* public, then the
> > > > implementation SHOULD return
> > > > > empty results, not hashed information, as in Example 11:
> > > > >
> > > > > Example 11. Room Returns Empty Disco Item Results (Items
> > > > are Private)
> > > > >
> > > > > <iq
> > > > > type='result'
> > > > > from='darkcave at macbeth.shakespeare.lit'
> > > > > to='hag66 at shakespeare.lit/pda'
> > > > > id='disco4'>
> > > > > <query xmlns='http://jabber.org/protocol/disco#items'/>
> > > > > </iq>
> > > > >
> > > > > Or at least so it seems to me. Thoughts?
> > > > >
> > > > Disco returning an empty list makes sense, although it
> > was this that
> > > > reminded me of the point I made above regarding different lists.
> > > >
> > > > Hope this makes my point a little clearer.
> > > > >
> > > > > Peter
> > > > >
> > > > > --
> > > > > Peter Saint-Andre
> > > > > Jabber Software Foundation
> > > > > http://www.jabber.org/people/stpeter.php
> > > > >
> > > > > On Tue, 11 Feb 2003, 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
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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
> >
> > --
> > 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
--
David Sutton
Email: dsutton at legend.co.uk
Jabber: peregrine at legend.net.uk
More information about the JDev
mailing list