[Standards] Expected behavior when blocking all unknown JIDs
steve.kille at isode.com
Sun Jan 15 11:35:58 UTC 2017
From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Dave Cridland
Sent: 15 January 2017 10:17
To: XMPP Standards
Subject: Re: [Standards] Expected behavior when blocking all unknown JIDs
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
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.
A setting for most users (default) where 1:1 messages from JIDs not in the roster are rejected seems good to me. Possibly allow users to change this.
If you want to 1:1 message me, it seems reasonable to require subscription.
Subscription spam problem is still unresolved in this case.
Yes, but perhaps this is not such a big deal as the current spam we are getting.
As a user, I’d like a “report as spam” button option when I get a subscription request. As well as a feel good factor, this information may help server side analysis to help block subscription spam.
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.
I don’t see this social acceptability model. I get regular linked-in requests from people I’ve never heard of. I just delete them.
It would be useful if subscription requests contained basic sender supplied context info. This would let a user distinguish between “My grandmother has died and wants to leave you her fortune…” and “I’ve seen your XEP and would like to discuss….”
This will help me decide on accepting a subscription.
Ideally, I’d like to be able to group my roster members and control which (“close friends”) get to see more information on me, so that the geoloc issue above is resolved by better control of sharing information with my roster members.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards