[Standards] Requirements for "Jid Hidden" Channels

Dave Cridland dave at cridland.net
Mon Jun 4 15:50:46 UTC 2018


On 2 June 2018 at 17:36, Steve Kille <steve.kille at isode.com> wrote:

> It is clear that much of the complexity around JID encoding that is being
> postulated as necessary, ties back to requirements to support participant
> communication through  JID Hidden channels.
>
> This note is to step back from the JID discussion, and consider JID Hidden
> channel requirements.
>
> I'm writing out a list of requirements here, which I think when agreed,
> could be usefully used as part of the introductory material to MIX-ANON.
>
> With JID Visible channels,  real JIDs are shared and participants can use
> this to communicate directly.
>
> When looking at MIX requirements, quite a few argued that we should not
> have
> JID Hidden.  A lot of other chat systems (e.g., Facebook) do not have an
> equivalent of JID Hidden.   I think that many channels will be JID Visible.
>
>
That's not been the case, though, historically. Most MUC rooms are
anonymous.


>
> It was agreed clearly that we need JID Hidden, primarily to prevent JID
> Harvesting.   This is going to be useful for public and semi-public
> channels.
>
> REQUIREMENTS:
>
> 1.  Participants can see which other participants have one or more online
> clients.
>
> 2.   Online participants can be displayed with a Nick.
>
> 3.   Participants MUST be able to see if another participant changes Nick.
>
> 4.    Participants can sent messages to other participants through the
> channel if channel policy allows this.
>
> 5.    A participant can share real JID with another participant and request
> real JID.   Can't do this currently, but it seems sensible to allow a pair
> of willing participants to shift from restricted communication through the
> channel to direct communication.
>
>
> POSSIBLE REQUIREMENTS:
>
> 6.   Participants can share presence status additional to online/offline.
> I am wondering if, in an environment where JIDs are being hidden, if it
> makes sense to share other presence stuff with  the channel.   My sense is
> that for a public MUC, it might make sense to restrict.   I would vote to
> make this a non-requirement.
>
>
If we assume that people will use MIX in the same way MUC is typically
used, then presence is usually (intentionally, I think) shared amongst
anonymous participants.


>
> 7.   Where a participant has multiple clients, other participants can see
> independent status of these clients.   I think that this is not appropriate
> for JID Hidden channels.  If you are not sharing your JID, it feels wrong
> to
> be sharing how many clients you have.
>
>
I this this depends on *why* you're hiding your JID.

In some cases, people are after perfect anonymity. In general, I think we
should ensure that it is possible to have a MIX channel which JIDs are
completely hidden (which probably includes avoiding pass-through for IQ,
etc in those cases). The two cases I can think of are the e-health case,
where we want to be able to assure participants that their identity is
secret, and the legal case where corporations wish to participate in some
collaborative venture without being definitively identified. (Cyber
collaboration, or collaborative security, is an example of the last case).

In most cases, though, people seem to want to hide their JID, but not hide
their identity. This seems to be the case in the vast majority of MUC rooms
I'm in, in fact. Your point (5) would be very useful here, since it would
allow, in principle, to subscribe to your presence through a chatroom,
which is (pretty much) the use-case here.


>
> NON REQUIREMENTS
>
>
> 8. vCard.   If you are hiding your JID,  it seems wrong to allow retrieval
> of generic information about you.   I think that getting vCard information
> about other participants should be explicitly excluded.
>
>
Well, it does seem a bit crazy - and why, back when I did the higher level
MUC implementation in M-Link, I explicitly made passing through vCard
requests an option. But it turns out most people usually want this for
avatars if nothing else.


>
> 9.  Client Disco.   I think that allowing clients to use IQ disco of JID
> Hidden participants is wrong.  If you feel that JID should be hidden, it
> does not make sense to
>
>
Totally disagree. This blocks nearly every elective feature of XMPP being
used.

You might think an anonymous client will never want to do, say, voice
calls, but I suspect that's only true if the goal is true anonymity - in
which case burner jids are more useful. In practise, though, things like
focus users in conference systems work using this.


>
>
> I appreciate that this has switched topics.   I think that getting some
> agreements here, would help to sort the JID discussion.
>
> Can we keep this thread on "JID Hidden" and see if we can agree
> requirements?
>
>
>
>
>
> Steve
>
>
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180604/d3e3ff57/attachment.html>


More information about the Standards mailing list