[JDEV] MUC problems
David Sutton
jabber at dsutton.legend.uk.com
Fri Feb 14 10:17:42 CST 2003
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
More information about the JDev
mailing list