[Standards] Blocking command and Privacy Lists

Kurt Zeilenga kurt.zeilenga at isode.com
Mon Dec 22 16:55:28 UTC 2014


> In summary (if I'm understanding correctly):
> 
> If you're using both privacy lists and blocklists, ensure that there is
> a direct two way mapping between the two (probably by just using the
> same backend datastore), but only if the request follows the exact
> semantics of the blocking command (eg. is a block command, or is a
> privacy list that matches the block command exactly).

Roughly…

My main point is that XEP 191 blocking protocol should have the same semantics regardless of whether one implements XEP 16 privacy lists or not.   To have semantics differ depending on whether the server implements XEP 16 privacy lists will create interoperability issues (and arguably security concerns).

Flushing my comments out a bit:

In XEP 191, a contact is either blocked or unblocked, where blocked means that all communication are blocked and where unblocked means no 191-specific blocking of communication (though there could, in theory, be other blocking for various reasons, such as possibly RFC 6120/6121 rules).

If a contact is only partially blocked by privacy lists, there’s no way to indicate this in the block list separate from “unblocked”.   It would, IMO, be bad to list a partially blocked contact as “blocked” when the semantics of “block” mean all XMPP stanzas are blocked.

And from this it follows that when a user, via Privacy Lists, changes the contact from all blocking to some blocking (or no blocking) than the 191 implementation should not only not list the contact as “blocked” but push an “unblocked” status for the contact to the user’s clients using XEP 191.   Additionally, where a contact not previously subject to any blocking or privacy list were to be come subject to partial blocking via a privacy list change, no “blocked” status should be pushed to client’s using XEP 191 as “all XMPP stanzas” are not blocked.

— Kurt


More information about the Standards mailing list