[jdev] XEP 0172 in MUCs

[Thijs Alkemade]

Hello,

As a client developer, I'm a bit confused about how XEP 0172 (User Nickname) is intended to be used with MUCs. From the XEP:

"A user MAY specify his or her persistent nickname as well. This may be desirable because the user's preferred room nickname is already taken or because the service "locks down" room nicknames."

So should a client should interpret the XEP-0172 nickname as a replacement for the MUC-nickname? This could lead to confusing situations with the same nick being used multiple times. If the service locks down room nicknames, then it supposedly has a good reason for that, and implementing a way to circumvent that sounds like a bad idea.

The reason I'm asking this is because Google Talk (the web interface) uses, for ad-hoc private group chats, random strings as room nicks, and then sends the user's real name as a <nick> element. I think all users would rather see the real name instead of the random string, but I'm worried about the implications of changing this. I've read the Security Considerations of XEP-0172, but I don't think that really answers this.

Regards,
Thijs
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-uns...@jabber.org
_______________________________________________

[Peter Saint-Andre]

Hallo Thijs,

On 1/4/12 10:26 AM, Thijs Alkemade wrote:
> Hello,
>
> As a client developer, I'm a bit confused about how XEP 0172 (User
> Nickname) is intended to be used with MUCs. From the XEP:
>
> "A user MAY specify his or her persistent nickname as well. This may
> be desirable because the user's preferred room nickname is already
> taken or because the service "locks down" room nicknames."
>
> So should a client should interpret the XEP-0172 nickname as a
> replacement for the MUC-nickname?

I think it would be supplemental.

> This could lead to confusing
> situations with the same nick being used multiple times. If the
> service locks down room nicknames, then it supposedly has a good
> reason for that, and implementing a way to circumvent that sounds
> like a bad idea.

I think you're right.

> The reason I'm asking this is because Google Talk (the web interface)
> uses, for ad-hoc private group chats, random strings as room nicks,
> and then sends the user's real name as a <nick> element. I think all
> users would rather see the real name instead of the random string,
> but I'm worried about the implications of changing this. I've read
> the Security Considerations of XEP-0172, but I don't think that
> really answers this.

I agree with you that it's preferable to allow real roomnicks. We might
want to update XEP-0172 to make that clearer, or even deprecate its use
in chatrooms...

Peter

--
Peter Saint-Andre
https://stpeter.im/

[Waqas Hussain]

I strongly support deprecating its use in chatrooms.

We've seen this cause issues in the Prosody chatroom. This was on my
list of things to post on the standard list, but somehow I never did.

This issue that we saw was different clients showing users different
nicks for the same user, users auto-completing the wrong nick, and
conversations getting derailed due to that. A quick survey of the
participants in that discussion showed that the affected clients had
no visual indication that the nick being displayed and in the UI
wasn't the real room nick. This has obvious security implications,
e.g., it easily allows impersonation.

--
Waqas Hussain