[Standards] Expected behavior when blocking all unknown JIDs

Dave Cridland dave at cridland.net
Sun Jan 15 10:17:05 UTC 2017

On 15 Jan 2017 07:39, "Evgeny Khramtsov" <xramtsov at gmail.com> wrote:

Fri, 13 Jan 2017 20:36:39 +0100
Kim Alvefur <zash at zash.se> wrote:

> If we think of blocking strangers by default as a privacy protection
> measure

Not everyone wants such rude default privacy.

I agree. I'd hate XMPP to be closed by default. One of the reasons we still
have, and use, email extensively is because it doesn't have characteristics
like this.

> Second, MUC can be made to work if the server allows traffic from
> JIDs to which directed presence has been sent.

And what about IQ? What if one wants to use http-upload service?
Probably there is a use case for messages too. So, basically, we should
accept all incoming traffic from an entity if outgoing traffic has
been sent to that entity?

Again, I agree. There's almost certainly a world of edge cases here. It
might be solvable, or more likely there is a compromise that some users are
willing to accept. But we're deep into heuristics.

> Third, subscription requests should probably not be blocked by
> default. It may be sensible UX to present blocking as an optional
> response.

Subscription spam problem is still unresolved in this case.

And this is the real problem here. We must assume the spammers read this

Another problem is you've changed the security model from being "allowing a
presence subscription allows the contact to see potentially sensitive data
about me in real time", to "allowing a presence subscription allows the
contact to message me and see potentially sensitive data about me in real

If we only allowed messaging from subscribed contacts, then we would run a
bad risk of making it more or less socially unacceptable to refuse a
subscription request - yet that might also provide them with geoloc, for
example. This feels wrong.

At minimum, you'd need to use jid decloaking (I can't recall if we made a
XEP for this, but it's essentially a poor man's session-delimited
subscription via direct presence). I'm not, though, convinced that even
this is sensible.

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/20170115/b91e7ad7/attachment.html>

More information about the Standards mailing list