[Standards] Blocking command and Privacy Lists

Holger Weiß holger at zedat.fu-berlin.de
Mon Dec 22 11:27:45 UTC 2014


* Dave Cridland <dave at cridland.net> [2014-12-22 09:19]:
> On 22 December 2014 at 01:19, Sam Whited <sam at samwhited.com> wrote:
> > XEP-0191 (Blocking command) specifies that once a contact is blocked, no
> > stanzas are delivered from them to the user:
> >
> > > Once the user has blocked communications with the contact, the
> > > user's server MUST NOT deliver any XML stanzas from the contact to
> > > the user. The block remains in force until the user subsequently
> > > unblocks commmunications with the contact (i.e., the duration of the
> > > block is potentially unlimited and applies across sessions).
> >
> > However, Gajim (and possibly other clients that use privacy lists) seems
> > to block everything but presence information.
>
> Slightly confused by this. XEP-0191 is server-side enforced, so the
> behaviour will be applied and controlled by the server, not the client.

Gajim uses XEP-0016 to block all stanzas except for <presence-in/>
notifications.

Sam and I were discussing the relationship of XEP-0191 blocklist entries
to privacy lists.  XEP-0191 doesn't mention the fact that XEP-0016
allows for blocking only some kinds of stanzas.  It just says the server

| SHOULD map the blocklist to the default privacy list, where each blocked
| JID is represented as a privacy list item of type "jid" and action
| "deny".

[ http://xmpp.org/extensions/xep-0191.html#privacy ]

To me, it's unclear whether this mapping rule is meant to also apply to
privacy list items that block some kinds of stanzas but not others.

> > From a user perspective, this seems like the expected behavior (I block
> > someone, they can't receive information about my presence or send me
> > messages, but I can still see their presence unless they block me).
> >
> > Am I interpreting everything correctly, and if so, is this something
> > that would be considered for change? I'd like to propose that the line
> > from XEP-0191 be rewritten to read something like:
> >
> > > Once the user has blocked communications with the contact, the
> > > user's server MUST NOT deliver any XML stanzas from the contact to
> > > the user except for presence stanzas. ...
>
> This would mean that probes still get sent, which seems inappropriate.
>
> Otherwise we're in the slightly weird situation that we're predicating on
> remote servers sending presence without a probe - this is quite possible,
> but could lead to some very odd behaviour when this get out of sync.

We already have this issue when implementing XEP-0016.  ejabberd was
changed just recently to send probes in order to support that use case.¹
This leaks the user's availability to the remote server's admin, but
it's the only way to make that feature usable.  As I understood it,
other servers behave that way, too.

As far as I can see, XEP-0016 itself doesn't mention outgoing probes.
It just says the presence notifications which are subject to privacy
rules

| do not include presence subscriptions, only presence information that
| is broadcasted to entities that are subscribed to a user's presence
| information.  Thus this includes presence stanzas with no 'type'
| attribute or of type='unavailable' only.

[ http://xmpp.org/extensions/xep-0016.html#protocol ]

Holger

¹ This was discussed here:

  https://github.com/processone/ejabberd/issues/275



More information about the Standards mailing list