[jdev] Improving XEP-0016: Privacy Lists

Florian Schmaus flo at geekplace.eu
Fri Jan 31 12:17:22 UTC 2014


I recently added support for Privacy Lists (XEP-0016) in my Android
app and ran into some problems.

The major problem first: If a session is created with a privacy list,
that has a disallow fall-through and another rule that allows
everything from JIDs with subscription 'both', then you could easily
end in a messy situation with XMPP server implementations that process
this list to exactly, because they will block IQ stanzas originating
from the server itself. The client will still be able to send IQs to
the server, but it will never receive a reply. Those servers would
then likely also block IQ stanzas from every entity that is not in the
roster and subscribed as 'both', e.g. IQs used in XEP-0045.

I discovered such an implementation flaw in Openfire (OF-724, [1]),
and since I got commit access to Openfire's SVN, applied the simple

In order to prevent future server/client developers from making the
same mistake, I suggest to extend XEP-0016 with an implementation
notice or additional business rule, stating that under no circumstances any
possible privacy list should block stanzas originating from the users
service. Or, if privacy lists should really be able to block such
stanzas, which seems kind of pointless to me, then a note, saying that
an explicit JID allow rule may be required in such situations, should
be added.

I also suggest that XEP-0016 mentions possible unwanted side effects
caused by solely filtering on the subscription status. For example,
the previously mentioned Openfire fix only implicitly allows all
stanzas where the 'from' attribute's value is the users service. But
IQs e.g. from a MUC where 'from="room at conference.server.tld"' would
still be blocked. While this can be a valid use-case, it may not
always be what the user intended.


1: http://issues.igniterealtime.org/browse/OF-724

More information about the JDev mailing list