[JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)

[Jean Louis Seguineau]

Jim,

Well, my idea was that this kind of xml would be interpreted as

1- I, as the query originating user, don't want to have anything to do with
jack at jabber.org , hence the "deny" without any kind of sub elements in the
<item> tag,
2- jill at jabber.org will be denied to receive/send any <message> and <iq> (as
specified by the tags contained in the <item> element) from the originating
user (the one that is seting-up the list)
3- jill at jabber.org will be allowed to receive/send <presence> (as specified
by the <presence> tag contained in the <item> element) to the originating
user.

If filtering specific namespaces comes into the picture, I gather the
easiest way to transcribe this kind of constraint would be to include <ns>
tags inside the <iq> tag, as most namespaces in Jabber are used by info
queries. A possible use could be

 <iq type="set" id="2">
   <query xmlns="jabber:iq:privacy">
     <item jid="jill at jabber.org" type="deny">
       <iq>
         <ns>jabber:iq:browse</ns>
         <ns>jabber:iq:oob</ns>
        </iq>
    </item>
  </query>
</iq>

which could be interpreted as jill at jabber.org is denied to receive/send any
<iq> packets that pertain to the jabber:iq:browse and jabber:iq:oob
namespaces, and may receive/send other iq packet to the originating user.

This is obviously not a real life case, just a way to show how the xml tags
would look like.

As to why I propose this xml syntax rather than modifying the <query>
element, I tend to agree with Peter in that we should keep the protocol from
going in too many directions. The <query> element doesn't provide any
support for attributes outside the xmlns. To keep some kind of consitency in
the way we build new xml snippets, it is probably best to achieve the
requested result by specifying differently the inner elements, like the
<item> tag.

Now the way this would work in practice is a matter of :
1- agreement of what the defaul behaviour must be
2- implementation at the server level.

A possible combined white/black list could be to say that anybody not in the
blacklist is automatically "allowed". Some others may like the oposite,
where anything which is not in the whitelist is automatically black listed,
and probably the best (IMHO) appraoch would be to have the choice of the
default server behaviour by setting some switch in the configuration file
(note that this last approach would certainly require that the client be
able to query what the defaul behaviour of the server is).

As to the way this should be implemented at the server level is at this
stage a bit premature. But I would think that having this information
arranged as "attributes" of a user profile that would be interpreted by a
rule engine could be a way to go.

Coming to the relation that may exists between the privacy namespace and the
"invisible" attribute in the presence tag, my understanding is that the
"invisible" state is a transient user status, i.e. something that is only
valid for the duration of it being set in a user session, whereas the
privacy namespace manages a persistent state that should be enforced every
time the user logs in and create a user session. Again what the server
should do is a matter of agreement, but I would be thinking that if you have
denied somebody to receive your presence information at the level of the
privacy namespace this will take precedence on any subsequent change to
"invisible" status, as the server should not relay that presence info
anyway.

Does it make sense?

Jean-Louis

> Message: 7
> To: jdev at jabber.org
> Subject: Re: [JDEV] On Privacy/Invisibility (aka: Buddy Permit/Deny)
> Date: Sun, 17 Mar 2002 10:50:59 -0500 (EST)
> From: jseymour at LinxNet.com (Jim Seymour)
> Reply-To: jdev at jabber.org
>
> "Jean Louis Seguineau" <jean-louis.seguineau at antepo.com> wrote:
> >
> [snip]
> >  What I meant was to use
> > something like:
> >
> > <iq type="set" id="2">
> >   <query xmlns="jabber:iq:privacy">
> >     <item jid="jack at jabber.org" type="deny"/>
> >     <item jid="jill at jabber.org" type="deny">
> >       <message/>
> >       <iq/>
> >     </item>
> >     <item jid="jill at jabber.org" type="allow">
> >       <presence/>
> >     </item>
> >   </query>
> > </iq>
> [snip]
>
> Forgive me if my comments are nonsense.  I'm relatively new at Jabber
> and XML.
>
> It seems to me the above doesn't work.  How would a combined deny/allow
> list work in practice?  Specifically: what should the server do in the
> presence of both, but the absence of a particular JID on either list?
> Allow?  Deny?  And in the above scenario, what should the server do?
> First JID match wins or last JID match over-rides?
>
> Here are my thoughts, such as they are and keeping the caveat I
> mentioned above in mind.
>
> First of all: I believe "whitelisting" support needs to happen at the
> start.  Particularly if the goal is to provide support similar to that
> of AIM.  What I'm mainly working on is Jabber support in Gaim, so both
> "blacklisting" and "whitelisting" capability would make things
> considerably easier for consistency's sake.
>
> I'm wondering if something more like this wouldn't work better
> (warning: possibly completely brain-dead XML follows):
>
>     <iq type="result" id="1">
>      <query xmlns="jabber:iq:privacy" type="deny">
>       <item jid="romeo at jabber.org"/>
>       <item jid="juliet at jabber.org">
>        <message/>
>       </item>
>      </query>
>     </iq>
>
> Which would provide for:
>
>     <iq type="result" id="1">
>      <query xmlns="jabber:iq:privacy" type="permit">
>       <item jid="romeo at jabber.org"/>
>       <item jid="juliet at jabber.org"/>
>      </query>
>     </iq>
>
> Then an empty "deny" list would be "permit everybody" and an empty
> "permit" list would be a "deny everybody".
>
> Admittedly: I'm not sure how this would work in conjunction with
> "Client Requests to Filter a Specific IQ Namespace" (in the proposal).
>
> I'm wondering what the thoughts are wrt interaction between "privacy,"
> subscription requests, presence and the new "invisible" stuff in 1.4.2?
> Would privacy "trump" these?  In other words:  if a JID was denied (or
> not allowed--same thing): would/should the server automatically not
> propagate subscription requests from the denied JID to the client?
> And/or should it not propagate presence info back to the denied JID?
>
>
> Regards,
> Jim
> --
> Jim Seymour                  | PGP Public Key available at:
> jseymour at LinxNet.com         |
http://www.uk.pgp.net/pgpnet/pks-commands.html
> http://jimsun.LinxNet.com    |
>
>
>
> --__--__--
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>
>
> End of jdev Digest
>