[JDEV] MUC problems
Constantin Nickonov
Nickonov at jabber.com
Fri Feb 14 10:44:38 CST 2003
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
>
More information about the JDev
mailing list