Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Mathieu Pasquet]

On 23.05.2020 20:08, Georg Lukas wrote:

[snip]
This is a very short and very slippery slope. I'm sure that you are
aware of the coordinated attacks on centralized social networks where
trolls mass-report accounts that they disagree with.

It's okay to block a certain sender JID on your own account without any
evidence, but I'm really hesitant to create an instrument that has even
a small chance of feeding forged evidence to server administrators.
Running a public server is hard enough already without having to
investigate such anti-abuse abuse, and I'm pretty sure that the "paid
xmpp DDoS" sellers will quickly adopt if you give them such a stick to
wield.



I concur, although I will point out that attacks on centralized social
networks do not even need to falsify the contents of the incriminated
message. They only use mass reporting together with a bogus abuse
subject, and that is enough in itself to trigger an automated removal
(or suspension) of the reported content.

Here our intent is not to flag what is or what is not acceptable for
private exchanges, but rather to get evidence linked to the report,
to determine the best course of action (assuming the abuser is on
another server, for the most part). Having one or several stanzas
attached to the report, with the guarantee that they are unaltered,
is in my opinion one of the best way to gather that information.

Mathieu
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Sat, May 23, 2020, at 14:08, Georg Lukas wrote:
> I'm not sure when you would come into a situation where you don't
> report a spam message in a timely manner but let it sit there for
> multiple weeks.

I'm not sure when we'd hit that situation either, but that's not going
to make it any less weird when it happens.


> I'm sure that you are aware of the coordinated attacks on
> centralized social networks where trolls mass-report accounts that
> they disagree with.

I am aware of them, and I do think we should try to avoid putting
burden on server operators as much as possible, but also I suspect you
have to check out reports no matter what. Although I would be more
worried that server operators would just trust what was in the payload
if we did it this way.

Mass fake reports could be a problem with sending stanza IDs as well,
especially if the attackers just use a stanza that has expired from the
archive. Either way the operator probably has to do something to verify
that the message was spam and/or actually existed or that the user
continues to send spam.

How spam reports are handled will always be very service specific too.
Servers could do anything from verifying it against the MAM archive
anyways if the specific account has a permanent archive enabled, or they
could do something more clever like generate IDs based on a signature of
the message so that they can verify that the forwarded message hasn't
been modified (this would be overkill to include in the XEP, but it has
no compatibility requirements so individual servers and services could
do something like this if they wanted and no one else would know the
difference). Anyways, just spitballing, I suspect we could find a couple
of good ways for servers to verify messages and just include a mention
of it in the security considerations if we went with a "forward the
message back" approach.


—Sam


-- 
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Georg Lukas]

* Sam Whited  [2020-05-23 15:40]:
> On Sat, May 23, 2020, at 06:24, Mathieu Pasquet wrote:
> > Sorry for the necromancer update, but would it not make sense to allow
> > stanza-id elements as children to the  and  elements?

Yeah, that's actually what also came to my mind as an easy and
straight-forward way to significantly improve the usefulness of 0377 for
server admins.

> I think that including a stanza-id is probably "good enough", but I'm
> also a little worried about the fact that you would then only be able to
> report recent messages, which feels like it would be unexpected and
> could make training a spam filter less easy.

I'm not sure when you would come into a situation where you don't report
a spam message in a timely manner but let it sit there for multiple
weeks.

> I'm now wondering if it makes sense to forward the entire original
> message and just trust that it's not all that easy to abuse [...]

This is a very short and very slippery slope. I'm sure that you are
aware of the coordinated attacks on centralized social networks where
trolls mass-report accounts that they disagree with.

It's okay to block a certain sender JID on your own account without any
evidence, but I'm really hesitant to create an instrument that has even
a small chance of feeding forged evidence to server administrators.
Running a public server is hard enough already without having to
investigate such anti-abuse abuse, and I'm pretty sure that the "paid
xmpp DDoS" sellers will quickly adopt if you give them such a stick to
wield.


Georg


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Sat, May 23, 2020, at 06:24, Mathieu Pasquet wrote:
> Sorry for the necromancer update, but would it not make sense to allow
> stanza-id elements as children to the  and  elements?

Georg and I were talking about this a few days ago and I would
definitely like to add some way to report individual messages.

I think that including a stanza-id is probably "good enough", but I'm
also a little worried about the fact that you would then only be able to
report recent messages, which feels like it would be unexpected and
could make training a spam filter less easy.

I'm now wondering if it makes sense to forward the entire original
message and just trust that it's not all that easy to abuse because a
single report probably won't result in a user being banned and even if a
potential attacker creates dozens of accounts that all report the same
user a quick look at the messaging stats (or whatever metrics server
administrators keep to track spammers) will likely show that they're not
a spammer.

—Sam

-- 
Sam Whited



-- 
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Florian Schmaus]

On 5/23/20 12:24 PM, Mathieu Pasquet wrote:
> 
> On 12.09.2017 12:45, Georg Lukas wrote:
>> * Sam Whited  [2017-09-12 01:52]:
>>> I had assumed that the server would be storing things and we didn't need
>>> to send it back, but maybe that's not always the case. This does seem
>>> like the kind of thing we might need to store or send back somehow.
>>
>> Yeah, this is going to be challenging. I'd really love to get the
>> message content and not just the sender JID on my spam reports. That
>> would require either MAM or some ring buffer of messages, which is all
>> not-so-neat, or the client to reflect the offensive message inside the
>> report, which is also challenging on it's own, and adds the security
>> problems Kim outlined.
>>
>> A trade-off solution might be to make MAM an (optional) prerequisite. A
>> client supporting MAM could add the  of an offensive message
>> into the report, giving the server a sufficiently large time window to
>> obtain the message from its MAM store.
>>
>> If either entity lacks MAM support, we fall back to blocking the JID
>> without further knowledge of the actual message content.
> 
> Sorry for the necromancer update, but would it not make sense to allow
> stanza-id elements as children to the  and  elements?

+1

It never can hurt to provide additional information, especially if it is
optional.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Mathieu Pasquet]

On 12.09.2017 12:45, Georg Lukas wrote:

* Sam Whited  [2017-09-12 01:52]:

I had assumed that the server would be storing things and we didn't need
to send it back, but maybe that's not always the case. This does seem
like the kind of thing we might need to store or send back somehow.


Yeah, this is going to be challenging. I'd really love to get the
message content and not just the sender JID on my spam reports. That
would require either MAM or some ring buffer of messages, which is all
not-so-neat, or the client to reflect the offensive message inside the
report, which is also challenging on it's own, and adds the security
problems Kim outlined.

A trade-off solution might be to make MAM an (optional) prerequisite. A
client supporting MAM could add the  of an offensive message
into the report, giving the server a sufficiently large time window to
obtain the message from its MAM store.

If either entity lacks MAM support, we fall back to blocking the JID
without further knowledge of the actual message content.


Georg


Sorry for the necromancer update, but would it not make sense to allow 
stanza-id elements as children to the  and  elements?


That would make for a pretty simple change, keeping existing
implementations working, but would also allow updated server implementations
to extract the message contents from the local MAM archive (if enabled).
If there is no archive, then the situation is the same as what it
currently is.

Mathieu
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Tue, Sep 12, 2017, at 10:06, Evgeny Khramtsov wrote:
> And say bye-bye to namespace delegation?

Does namespace delegation only work on top level IQs (I guess it would
have to unless you wanted to do some weird forward-lookahead type
stuff)? I hadn't actually considered it because I didn't know anyone was
using it.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Tue, 12 Sep 2017 09:21:00 -0500
Sam Whited  wrote:

> Would not making it a dependency and merging it into the Blocking XEP
> solve this for you as well?

And say bye-bye to namespace delegation? At the moment we
don't have any plans to add XEP-0377 functionality (largely because we
don't know what to do with the collected reports yet), but ejabberd
supports namespace delegation and anyone can add spam reporting support
to ejabberd using this delegation.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Tue, Sep 12, 2017, at 09:16, Holger Weiß wrote:
> But I still believe it's wrong to let one feature depend on another one
> without a technical reason.  Dependencies can lead to issues

Would not making it a dependency and merging it into the Blocking XEP
solve this for you as well?

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Holger Weiß]

* Matthew Wild  [2017-09-12 12:35]:
> On 12 September 2017 at 12:10, Guus der Kinderen
>  wrote:
> > I'd much more prefer a solution where spam is reported (as a stand-alone
> > action, not embedded in a block), with an implementation guideline that
> > reads something like "Upon receiving a report, the server SHOULD ensure that
> > the reporter does not receive any more data from the reported JID" (but then
> > in better XEP-speak). That text could even suggest that a block / privacy
> > list entry is made on behalf of the reporting entity.
> 
> But now the client doesn't know if it needs to also send a blocking
> request to the server, or if this is going to happen automatically.

I agree we shouldn't add such a guideline to XEP-0377.  The XEP should
specify how to report spam to the local server, and nothing else.

But I still believe it's wrong to let one feature depend on another one
without a technical reason.  Dependencies can lead to issues, some of
which have been mentioned in this thread.  So they should only be
introduced if necessary, and this one just isn't.

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Matthew Wild]

On 12 September 2017 at 12:47, Guus der Kinderen
 wrote:
> Not all blocking comes from SPAM reports. XEP-0191 isn't duplicated by
> creating a SPAM report, as it also allows you to block entities for any
> other reason (annoying automated messages, in-laws, etc).

I agree, not all blocking comes from spam reports. I didn't mean to
imply that it did, quite the opposite. But all spam reports are
blocking. And we already have a protocol for blocking.

> As for delivery: at the very least, you can do the same as what the current
> XEP tells you to do: report it to the server that manages your blocklist.
> Furthermore, you *can* report it to any entity that reports the capability.
> Maybe I'm missing the point that you're trying to make here?

Yes, sorry, I could have been clearer here. My intention is to say
that I think reports should go to the user's home server for many
reasons. I don't think attempts to do otherwise would be successful.

> As for modern/popular UIs. These were the first three I had open (yes, I
> should get back to work, I know):
>
> GMail gives me a button for spam reporting, but a distinct (and more
> elaborate) "Filters and Blocked Addresses" settings panel.
> Facebook gives two distinct options: "Block" and "Report"
> Twitter gives me three distinct options: "Mute", "Block" and "Report"

Yeah, I didn't mean to say that having multiple buttons in the UI is
wrong. More like, the action is tied as far as UX goes:

  - Gmail: spam report button removes the message from inbox, and
feeds back into Gmail's spam filter
  - Facebook: Reporting also blocks
  - Twitter: Reporting also blocks (mute would likely be a client-side
feature in XMPP, at least at this stage)

> I'm all for a single report-spam-and-dont-get-any-from-that-jid-anymore, but
> I don't feel that we should require this to be built on XEP-0191.

So, a new blocking protocol that is used sometimes? Two block lists?
Or do we need to define some (complex) interaction between the two
blocking protocols? Actually make that three, because most people are
still attempting to seamlessly support XEP-0016 as well.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Florian Schmaus]

On 12.09.2017 13:35, Matthew Wild wrote:
> On 12 September 2017 at 12:10, Guus der Kinderen
>  wrote:
>> I'd much more prefer a solution where spam is reported (as a stand-alone
>> action, not embedded in a block), with an implementation guideline that
>> reads something like "Upon receiving a report, the server SHOULD ensure that
>> the reporter does not receive any more data from the reported JID" (but then
>> in better XEP-speak). That text could even suggest that a block / privacy
>> list entry is made on behalf of the reporting entity.
> 
> But now the client doesn't know if it needs to also send a blocking
> request to the server, or if this is going to happen automatically.
> 
> Reasons not to make spam reporting separate:
> 
>   - If we always make it block JIDs, we're essentially duplicating
> (and obsoleting) XEP-0191 for one specific use-case. Needless and
> confusing XEP overlap.
>   - Ambiguity as to where the spam reports should go (we've been down
> this road before - send them to the originating server?)
>   - New (but overlapping) protocol for clients to implement
>   - The separation will encourage implementations to show separate UI
> actions with ambiguous consequences, even though are both "blocking"
> at the end of the day.
> 
> Reasons to do combined block-and-report:
> 
>   - Because why wouldn't you want to block a spammer?
>   - All other popular/modern communication systems work this way from
> the user's perspective, and it's what they would expect
>   - The annotation is useful information to the server, but it's not
> essential. Clients don't *have* to include it.
>   - If they do include it, it's a nice atomic operation.
> 
> Reasons to base this on XEP-0191:
> 
>   - Already implemented in clients and servers
>   - Spam annotation is optional for clients, basic blocking will
> always work with no changes to client or server.
>   - Servers will ignore the annotation if they don't understand it
>   - No ambiguity about whether a spam report also blocks. It's a
> blocking request with optional report, not a report with optional
> block.
> 
> Reasons why we need spam reporting at all:
> 
>   - As many have mentioned, blocking individual spammer JIDs is
> futile, but reports will allow the server to gain insight into what
> spam is slipping through,
>  which may be fed back into $algorithms and help prevent more spam
> from reaching more users.

Excellent summary. Having  als child of a blocking command sure
is nice but I do wonder if we additionally need the ability to just
report spam (and eventually ham).

For example in Gmail "Report Spam" does not automatically lead to the
spammer being blocked in some cases.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Guus der Kinderen]

Not all blocking comes from SPAM reports. XEP-0191 isn't duplicated by
creating a SPAM report, as it also allows you to block entities for any
other reason (annoying automated messages, in-laws, etc).

As for delivery: at the very least, you can do the same as what the current
XEP tells you to do: report it to the server that manages your blocklist.
Furthermore, you *can* report it to any entity that reports the capability.
Maybe I'm missing the point that you're trying to make here?

As for modern/popular UIs. These were the first three I had open (yes, I
should get back to work, I know):

   - GMail gives me a button for spam reporting, but a distinct (and more
   elaborate) "Filters and Blocked Addresses" settings panel.
   - Facebook gives two distinct options: "Block" and "Report"
   - Twitter gives me three distinct options: "Mute", "Block" and "Report"

I'm all for a single report-spam-and-dont-get-any-from-that-jid-anymore,
but I don't feel that we should require this to be built on XEP-0191.

On 12 September 2017 at 13:35, Matthew Wild  wrote:

> On 12 September 2017 at 12:10, Guus der Kinderen
>  wrote:
> > I'd much more prefer a solution where spam is reported (as a stand-alone
> > action, not embedded in a block), with an implementation guideline that
> > reads something like "Upon receiving a report, the server SHOULD ensure
> that
> > the reporter does not receive any more data from the reported JID" (but
> then
> > in better XEP-speak). That text could even suggest that a block / privacy
> > list entry is made on behalf of the reporting entity.
>
> But now the client doesn't know if it needs to also send a blocking
> request to the server, or if this is going to happen automatically.
>
> Reasons not to make spam reporting separate:
>
>   - If we always make it block JIDs, we're essentially duplicating
> (and obsoleting) XEP-0191 for one specific use-case. Needless and
> confusing XEP overlap.
>   - Ambiguity as to where the spam reports should go (we've been down
> this road before - send them to the originating server?)
>   - New (but overlapping) protocol for clients to implement
>   - The separation will encourage implementations to show separate UI
> actions with ambiguous consequences, even though are both "blocking"
> at the end of the day.
>
> Reasons to do combined block-and-report:
>
>   - Because why wouldn't you want to block a spammer?
>   - All other popular/modern communication systems work this way from
> the user's perspective, and it's what they would expect
>   - The annotation is useful information to the server, but it's not
> essential. Clients don't *have* to include it.
>   - If they do include it, it's a nice atomic operation.
>
> Reasons to base this on XEP-0191:
>
>   - Already implemented in clients and servers
>   - Spam annotation is optional for clients, basic blocking will
> always work with no changes to client or server.
>   - Servers will ignore the annotation if they don't understand it
>   - No ambiguity about whether a spam report also blocks. It's a
> blocking request with optional report, not a report with optional
> block.
>
> Reasons why we need spam reporting at all:
>
>   - As many have mentioned, blocking individual spammer JIDs is
> futile, but reports will allow the server to gain insight into what
> spam is slipping through,
>  which may be fed back into $algorithms and help prevent more spam
> from reaching more users.
>
> Spam reporting is by no means the thing that will end all spam, but
> it's an essential component.
>
> Regards,
> Matthew
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Matthew Wild]

On 12 September 2017 at 12:10, Guus der Kinderen
 wrote:
> I'd much more prefer a solution where spam is reported (as a stand-alone
> action, not embedded in a block), with an implementation guideline that
> reads something like "Upon receiving a report, the server SHOULD ensure that
> the reporter does not receive any more data from the reported JID" (but then
> in better XEP-speak). That text could even suggest that a block / privacy
> list entry is made on behalf of the reporting entity.

But now the client doesn't know if it needs to also send a blocking
request to the server, or if this is going to happen automatically.

Reasons not to make spam reporting separate:

  - If we always make it block JIDs, we're essentially duplicating
(and obsoleting) XEP-0191 for one specific use-case. Needless and
confusing XEP overlap.
  - Ambiguity as to where the spam reports should go (we've been down
this road before - send them to the originating server?)
  - New (but overlapping) protocol for clients to implement
  - The separation will encourage implementations to show separate UI
actions with ambiguous consequences, even though are both "blocking"
at the end of the day.

Reasons to do combined block-and-report:

  - Because why wouldn't you want to block a spammer?
  - All other popular/modern communication systems work this way from
the user's perspective, and it's what they would expect
  - The annotation is useful information to the server, but it's not
essential. Clients don't *have* to include it.
  - If they do include it, it's a nice atomic operation.

Reasons to base this on XEP-0191:

  - Already implemented in clients and servers
  - Spam annotation is optional for clients, basic blocking will
always work with no changes to client or server.
  - Servers will ignore the annotation if they don't understand it
  - No ambiguity about whether a spam report also blocks. It's a
blocking request with optional report, not a report with optional
block.

Reasons why we need spam reporting at all:

  - As many have mentioned, blocking individual spammer JIDs is
futile, but reports will allow the server to gain insight into what
spam is slipping through,
 which may be fed back into $algorithms and help prevent more spam
from reaching more users.

Spam reporting is by no means the thing that will end all spam, but
it's an essential component.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Tue, 12 Sep 2017 13:10:54 +0200
Guus der Kinderen  wrote:

> By not tying this XEP to Blocking, the XEP becomes even easier to
> implement, but also more versatile. As a slightly embarrassing, but
> truthful, illustration: if this XEP would not have been dependent on
> Blocking, it would now already be in Openfire (I tried, but failed,
> as the privacy list implementation in Openfire is too complex to
> easily integrate this).

That's what I'm trying to say here. This is clearly a problem of
software dependencies. Reducing them resolves the problem.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Guus der Kinderen]

Although I agree that not receiving messages from the reported entity is a
good thing. I'm still not comfortable with embedding the spam-reporting in
blocking functionality.

I'd much more prefer a solution where spam is reported (as a stand-alone
action, not embedded in a block), with an implementation guideline that
reads something like "Upon receiving a report, the server SHOULD ensure
that the reporter does not receive any more data from the reported JID"
(but then in better XEP-speak). That text could even suggest that a block /
privacy list entry is made on behalf of the reporting entity.

You'd still not have the inconvenience of needing two queries, while you
keep the XEP more open to processing the report in any other way than only
blocking the reported JID - which in my opinion is under-utilizing the
potential power of this XEP.

By not tying this XEP to Blocking, the XEP becomes even easier to
implement, but also more versatile. As a slightly embarrassing, but
truthful, illustration: if this XEP would not have been dependent on
Blocking, it would now already be in Openfire (I tried, but failed, as the
privacy list implementation in Openfire is too complex to easily integrate
this).


On 12 September 2017 at 12:11, Daniel Gultsch  wrote:

> I have implemented the XEP in Conversations and find it very useful.
>
> I actually like the bundling with the blocking XEP for two reasons.
>
> 1) 'Reporting' a JID comes at a cost of not being able to receive
> messages from that JID again. Yes it is reversible and yes this
> doesn't protect us from scripts reporting arbitrary jids but it does
> create some inhibition for the casual user. (Unblocking is at least
> some clicks away in Conversations). => Bundling it with blocking will
> reduce the noise.
> 2) By bundling it with blocking we 'force' a consistent UI among
> clients. Clients don't have to offer two different actions for
> blocking and reporting. Instead reporting is just another checkbox in
> the block dialog. Yes; if those are two separate IQ commands I *can*
> use the same bundled UI but I don't have to.
>
> Re: What Dave said about not bothering to block spammers; a) when all
> clients bundle the UI there is no cost for blocking b) especially
> domain blocking can be rather useful - I've personally blocked a
> couple of 'weird' domains under the assumption that I will never ever
> receive legitimate message from that domain.
>
> cheers
> Daniel
>
>
> 2017-09-11 19:13 GMT+02:00 Jonas Wielicki :
> > XEP-0377 (Spam Reporting) has been Deferred because of inactivity.
> >
> > Abstract:
> > This document specifies a mechanism by which users can report spam and
> > other abuse to a server operator or other spam service.
> >
> > URL: https://xmpp.org/extensions/xep-0377.html
> >
> > If and when a new revision of this XEP is published, its status will
> > be changed back to Experimental.
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Tue, 12 Sep 2017 12:11:45 +0200
Daniel Gultsch  wrote:

> By bundling it with blocking we 'force' a consistent UI among
> clients.

And on the other hand 'forces' server devs to put all functionality
into a single module or building modules dependencies. In the case of
clients you can add "UI Consideration" section, but what can you do in
the case of servers?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Georg Lukas]

* Dave Cridland  [2017-09-12 11:02]:
> FWIW, I've never bothered blocking any spammers, because it looks like
> they always use a throwaway address anyway.

I think the push behind the Spam Reporting XEP is to allow the server
admins who are not in the lucky position of getting spammed already, to
have a look at the spam messages and to adjust their global spam filters.

If there is a sufficiently short cycle between reporting and stopping
that kind of message server-wide, this might become a good tool in our
ongoing fight, even with spammers using throw-away JIDs.


Georg


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Georg Lukas]

* Sam Whited  [2017-09-12 01:52]:
> I had assumed that the server would be storing things and we didn't need
> to send it back, but maybe that's not always the case. This does seem
> like the kind of thing we might need to store or send back somehow.

Yeah, this is going to be challenging. I'd really love to get the
message content and not just the sender JID on my spam reports. That
would require either MAM or some ring buffer of messages, which is all
not-so-neat, or the client to reflect the offensive message inside the
report, which is also challenging on it's own, and adds the security
problems Kim outlined.

A trade-off solution might be to make MAM an (optional) prerequisite. A
client supporting MAM could add the  of an offensive message
into the report, giving the server a sufficiently large time window to
obtain the message from its MAM store.

If either entity lacks MAM support, we fall back to blocking the JID
without further knowledge of the actual message content.


Georg


signature.asc
Description: PGP signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Tue, 12 Sep 2017 12:25:55 +0200
Jonas Wielicki  wrote:

> Nobody said that the element necessarily has the same namespace as
> currently used by other XEP-0191 elements.

So I can easily add elements such as  inside a 
because why not? There is only SHOULD and also guys from XSF do this.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Jonas Wielicki]

On Dienstag, 12. September 2017 12:11:45 CEST Daniel Gultsch wrote:
> I have implemented the XEP in Conversations and find it very useful.
> 
> I actually like the bundling with the blocking XEP for two reasons.
> 
> 1) 'Reporting' a JID comes at a cost of not being able to receive
> messages from that JID again. Yes it is reversible and yes this
> doesn't protect us from scripts reporting arbitrary jids but it does
> create some inhibition for the casual user. (Unblocking is at least
> some clicks away in Conversations). => Bundling it with blocking will
> reduce the noise.
>
> 2) By bundling it with blocking we 'force' a consistent UI among
> clients. Clients don't have to offer two different actions for
> blocking and reporting. Instead reporting is just another checkbox in
> the block dialog. Yes; if those are two separate IQ commands I *can*
> use the same bundled UI but I don't have to.

That’d be a great use-case for a Usability Considerations section in the XEP. 
I think that bundling this in the UI makes enough sense to add some wording to 
the XEP.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Jonas Wielicki]

On Dienstag, 12. September 2017 12:59:48 CEST Evgeny Khramtsov wrote:
> > That is the whole point of extensibility.
> 
> No, as I see it, the point of extensibility is to add elements within
> another namespaces instead of injecting elements into existing ones.

Nobody said that the element necessarily has the same namespace as currently 
used by other XEP-0191 elements.

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Daniel Gultsch]

I have implemented the XEP in Conversations and find it very useful.

I actually like the bundling with the blocking XEP for two reasons.

1) 'Reporting' a JID comes at a cost of not being able to receive
messages from that JID again. Yes it is reversible and yes this
doesn't protect us from scripts reporting arbitrary jids but it does
create some inhibition for the casual user. (Unblocking is at least
some clicks away in Conversations). => Bundling it with blocking will
reduce the noise.
2) By bundling it with blocking we 'force' a consistent UI among
clients. Clients don't have to offer two different actions for
blocking and reporting. Instead reporting is just another checkbox in
the block dialog. Yes; if those are two separate IQ commands I *can*
use the same bundled UI but I don't have to.

Re: What Dave said about not bothering to block spammers; a) when all
clients bundle the UI there is no cost for blocking b) especially
domain blocking can be rather useful - I've personally blocked a
couple of 'weird' domains under the assumption that I will never ever
receive legitimate message from that domain.

cheers
Daniel


2017-09-11 19:13 GMT+02:00 Jonas Wielicki :
> XEP-0377 (Spam Reporting) has been Deferred because of inactivity.
>
> Abstract:
> This document specifies a mechanism by which users can report spam and
> other abuse to a server operator or other spam service.
>
> URL: https://xmpp.org/extensions/xep-0377.html
>
> If and when a new revision of this XEP is published, its status will
> be changed back to Experimental.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Tue, 12 Sep 2017 11:34:26 +0200
Jonas Wielicki  wrote:

> You are wrong, I think. RFC 6120, Section 11.4 Validation:

The section says nothing about servers. And the receiving entity is a
server in our case.

> That is the whole point of extensibility.

No, as I see it, the point of extensibility is to add elements within
another namespaces instead of injecting elements into existing ones.

> Also, XML Schemas in XEPs are non-normative anyways

Yes, and that's pity.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Jonas Wielicki]

On Dienstag, 12. September 2017 12:05:27 CEST Evgeny Khramtsov wrote:
> Tue, 12 Sep 2017 10:02:26 +0100
> 
> Dave Cridland  wrote:
> > I don't think so. We're just adding an element, so it could be done
> > with just a new disco feature, I think.
> 
> Hum, am I missed something? Strict xmpp entities could not allow
> elements not defined in schema, no?

You are wrong, I think. RFC 6120, Section 11.4 Validation:

> Clients are advised not to rely on the ability to send data that does not
> conform to the schemas, and SHOULD ignore any non-conformant elements or 
> attributes on the incoming XML stream.

"schemas" in there refers to the RFC 6120 schemas, but I think this 
generalizes nicely. That is the whole point of extensibility.

(Also, XML Schemas in XEPs are non-normative anyways from my understanding. 
Possibly for this exact reason.)

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Tue, 12 Sep 2017 10:02:26 +0100
Dave Cridland  wrote:

> I don't think so. We're just adding an element, so it could be done
> with just a new disco feature, I think.

Hum, am I missed something? Strict xmpp entities could not allow
elements not defined in schema, no?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Dave Cridland]

On 12 September 2017 at 09:35, Evgeny Khramtsov  wrote:
> Mon, 11 Sep 2017 18:14:38 -0500
> Sam Whited  wrote:
>
>> That sounds good to me, I'll see if I can't prepare an update to do
>> that. Since the blocking command is draft I'm not sure that it's
>> possible.
>
> There is a problem, because we need to bump XEP-0191's namespace
> (there is no  element defined within current namespace).
>

I don't think so. We're just adding an element, so it could be done
with just a new disco feature, I think.

> Ah, and another issue against wrapping:  could be handled
> separately by an external entity, see XEP-0355.
>
> Having all that, given that some folks also suggest handling it
> separately I think we shouldn't wrap.

My mind isn't made up on this, but I'm inclined toward not wrapping it
in '191. It's not clear to me that blocking and spam reporting are
inherently interlinked. In particular, my reporting a spammer might
result in another user having those messages blocked, while I might
equally block a jid for some non-spammy reason.

FWIW, I've never bothered blocking any spammers, because it looks like
they always use a throwaway address anyway.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Mon, 11 Sep 2017 18:14:38 -0500
Sam Whited  wrote:

> That sounds good to me, I'll see if I can't prepare an update to do
> that. Since the blocking command is draft I'm not sure that it's
> possible.

There is a problem, because we need to bump XEP-0191's namespace
(there is no  element defined within current namespace).

Ah, and another issue against wrapping:  could be handled
separately by an external entity, see XEP-0355.

Having all that, given that some folks also suggest handling it
separately I think we shouldn't wrap.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Jonas Wielicki]

On Montag, 11. September 2017 18:51:35 CEST Sam Whited wrote:
> On Mon, Sep 11, 2017, at 17:39, Kim Alvefur wrote:
> > The SPAM payload itself is of interest for further analysis, so a way to
> > get it would be nice. But we don't want to make it easy to lie and
> > submit something and claim it came from an innocent. Perhaps a message
> > id, that could be corelated with either an archive or some simple
> > buffer?
> 
> I had assumed that the server would be storing things and we didn't need
> to send it back, but maybe that's not always the case. This does seem
> like the kind of thing we might need to store or send back somehow.

I think it makes sense to specifically address a message. The server can of 
course source the last N messages from the archive concerning the reporeted 
JID, but that seems error prone to me.

On the other hand, users could have difficulties to report a SPAM attack which 
consited of multiple messages if only a single one (even if multiple ones can 
be reported, it’s more work and unlikely to happen) can be reported.

Not sure there’s a good and easy solution here.


> > Since you can send out multiple stanzas without waiting for a reply,
> > there doesn't have to be any additional roundtrips. A network stack can
> > even return the responses in the same TCP segment.
> 
> A service operator can't guarantee that the clients connected to them
> will do that though.

If a client can’t pipeline stanzas, it has worse issues (it would likely block 
while waiting for MAM to download on connect for example). This should, IMO, 
not be an argument.



As for the XEP in general, it is unclear to me what the features actually say. 
The features are phrased to announce support for "Spam Reporting". The use 
with the blocking command looks a bit example-ish to me, and if future uses in 
other places are planned, having a separate feature indicating support for 
embedding into the blocking command seems reasonable.


That said, I’m strongly in favour for making this a separate IQ. Merging this 
in XEP-0191 seems wrong to me (do one thing and do it well). Having this 
extend XEP-0191 in the way it currently does also seems wrong to me. It at 
least needs to clearly specify a feature which indicates support for embedding 
the report into the blocking command. I think in that case I’m fine with it, 
but still not happy.


A separate IQ seems semantically more reasonable, especially since experience 
shows that blocking a JID is rarely useful. If anything, blocking a domain is 
useful, but then we’re back to "how does the server learn which messages from 
this domain were actually SPAM?".


For the Security Considerations: I would argue that it definitely needs more. 
It appears that a client can harm the reputation of a JID by blocking it as 
spam. This should be mentioned, since it possibly attacks the availability of 
the affected JID for others, too. I think something along the lines of 
"Servers should take care when using the spam reports for actions besides 
blocking the JID for the reporting user, unless the spam report has been 
verified to be actually spam in some way." would make sense.


kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Florian Schmaus]

On 12.09.2017 00:39, Kim Alvefur wrote:
> On Mon, Sep 11, 2017 at 12:32:09PM -0500, Sam Whited wrote:
>> On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote:
>>> XEP-0377 (Spam Reporting) has been Deferred because of inactivity.
>>
>> Hi all. Spam reporting was just (correctly) deferred. Several servers
>> have implemented it, but only a handful of operators and client
>> developers, as far as I can tell so I wanted to see what the experience
>> with it is so far:
>>
>> Is there anything missing you think a spam reporting XEP must do?
> 
> The SPAM payload itself is of interest for further analysis, so a way to
> get it would be nice. But we don't want to make it easy to lie and
> submit something and claim it came from an innocent. Perhaps a message
> id, that could be corelated with either an archive or some simple
> buffer?

Definitely that.

>> Was your implementation experience (clients and servers) smooth?
> 
> I think it's fine. I can understand wanting it to be a standalone IQ
> request instead and I have nothing against changing it to that.

I also that that it would be far better design if it was a standalone IQ.

> Since you can send out multiple stanzas without waiting for a reply,
> there doesn't have to be any additional roundtrips. A network stack can
> even return the responses in the same TCP segment.

Exactly that, the roundtrip argument does not apply. Also the argument
that (client) libraries may not perform this optimization is going into
the wrong direction. We had a similar situation with MAM (remember the
'fin' message?), where a bad protocol design was justified with "it's
easier to impement". Good that we switched and do the right thing now.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Mon, Sep 11, 2017, at 17:39, Kim Alvefur wrote:
> The SPAM payload itself is of interest for further analysis, so a way to
> get it would be nice. But we don't want to make it easy to lie and
> submit something and claim it came from an innocent. Perhaps a message
> id, that could be corelated with either an archive or some simple
> buffer?

I had assumed that the server would be storing things and we didn't need
to send it back, but maybe that's not always the case. This does seem
like the kind of thing we might need to store or send back somehow.

> Since you can send out multiple stanzas without waiting for a reply,
> there doesn't have to be any additional roundtrips. A network stack can
> even return the responses in the same TCP segment.

A service operator can't guarantee that the clients connected to them
will do that though.

> XEP-0191 allows blocking multiple JIDs at a time, which one has to keep
> in mind when implementing 337 as it currently is.

I hadn't actually thought of that; that seems like a UI concern that
it's probably worth mentioning in the XEP. Thanks!

> From what I've understood of current spammer tactics, it doesn't really
> help to block individual JIDs, as they seem to be used only once.

That may be so. Does it hurt to block them somehow though?

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Mon, Sep 11, 2017, at 17:51, Evgeny Khramtsov wrote:
> Well, actually I'm open to find a compromise. If the author insists on
> wrapping it into  element and says that this is a "blocking
> reason", then I'm fine with defining this in XEP-0191. This should not
> be a problem, right? Because it's assumed that spam reporting is
> unusable outside XEP-0191 anyway.

That sounds good to me, I'll see if I can't prepare an update to do
that. Since the blocking command is draft I'm not sure that it's
possible.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Mon, Sep 11, 2017, at 17:39, Evgeny Khramtsov wrote:
> Deprecating something doesn't magically solve the problem and force
> operators/users to update software (remember vcard avatars or private
> storage, though, they are not formally deprecated, but deprecation will
> not change anything). So we *must* be interested. And yes, this is
> complicated to support, we should deal with this.

I disagree, they'll get the new functionality when they upgrade. If not,
they don't get it. We can't be backwards compatible forever and this
isn't even a lack of backwards compatibility, it's a new feature so they
have to implement something either way.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Tue, 12 Sep 2017 00:05:07 +0200
Philipp Hörist  wrote:

> It just makes me sad, that not even about something basic and easy
> like reporting a jid for spam, we can find to an agreement.

Well, actually I'm open to find a compromise. If the author insists on
wrapping it into  element and says that this is a "blocking
reason", then I'm fine with defining this in XEP-0191. This should not
be a problem, right? Because it's assumed that spam reporting is
unusable outside XEP-0191 anyway.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Mon, 11 Sep 2017 22:28:29 +
Sam Whited  wrote:

> XEP-0016 is deprecated so I am not interested in making this more
> complicated to support it.

Deprecating something doesn't magically solve the problem and force
operators/users to update software (remember vcard avatars or private
storage, though, they are not formally deprecated, but deprecation will
not change anything). So we *must* be interested. And yes, this is
complicated to support, we should deal with this.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Kim Alvefur]

Hi,

On Mon, Sep 11, 2017 at 12:32:09PM -0500, Sam Whited wrote:
> On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote:
> > XEP-0377 (Spam Reporting) has been Deferred because of inactivity.
> 
> Hi all. Spam reporting was just (correctly) deferred. Several servers
> have implemented it, but only a handful of operators and client
> developers, as far as I can tell so I wanted to see what the experience
> with it is so far:
> 
> Is there anything missing you think a spam reporting XEP must do?

The SPAM payload itself is of interest for further analysis, so a way to
get it would be nice. But we don't want to make it easy to lie and
submit something and claim it came from an innocent. Perhaps a message
id, that could be corelated with either an archive or some simple
buffer?

> Was your implementation experience (clients and servers) smooth?

I think it's fine. I can understand wanting it to be a standalone IQ
request instead and I have nothing against changing it to that.

Since you can send out multiple stanzas without waiting for a reply,
there doesn't have to be any additional roundtrips. A network stack can
even return the responses in the same TCP segment.

> find any part of using it especially painful?

XEP-0191 allows blocking multiple JIDs at a time, which one has to keep
in mind when implementing 337 as it currently is.

> How are you using it and is the data it provides you useful or should
> more information be attatched? etc.

I haven't quite figured out where the data should go yet, but made it so
that other plugins can hook into it. 

>From what I've understood of current spammer tactics, it doesn't really
help to block individual JIDs, as they seem to be used only once.

-- 
Regards,
Zash
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On September 11, 2017 4:44:27 PM CDT, Evgeny Khramtsov  
wrote:
>So, probably? Or are you absolutely sure?

No, but this isn't designed to be a one size fits all solution to every problem 
under the sun, it's supposed to provide a simple, easy to implement  solution 
for saying that you blocked someone because the message was spam. Would meeting 
it with the blocking command xep not fix your initial concerns without making 
it mite complicated?

>Another question is what if the server doesn't have XEP-0191 module
>running, but, instead, have XEP-0016 running? Ah, I forgot, we don't
>care about backward compatibility anymore.

XEP-0016 is deprecated so I am not interested in making this more complicated 
to support it. Again, let's keep it simple. It's hard to find a balance between 
"enough" features and "everything under the sun", but I think supporting 
alternative, deprecated blocking methods leans towards the latter.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Philipp Hörist]

No not for me,

in fact having one spam XEP on its own, and a second one with a report
function in blocking command, makes implementation for clients more
complicated. (not much although, we talking here about checking for one
more feature)
Roundtrips is not a good argument for me either, because how many people
are you going to block a day? thats nothing in comparison with the traffic
we are generating.

It just makes me sad, that not even about something basic and easy like
reporting a jid for spam, we can find to an agreement.

But go on.

Philipp

2017-09-11 23:58 GMT+02:00 Evgeny Khramtsov :

> Mon, 11 Sep 2017 23:52:46 +0200
> Philipp Hörist  wrote:
>
> > Afterwards we could do the addition to blocking command for the report
> > function, as long as there is discovery for this additional feature to
> > blocking command
>
> I'm curious what problem does this solve? Is there a problem for a
> client to send two stanzas instead of one?
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Mon, 11 Sep 2017 23:52:46 +0200
Philipp Hörist  wrote:

> Afterwards we could do the addition to blocking command for the report
> function, as long as there is discovery for this additional feature to
> blocking command

I'm curious what problem does this solve? Is there a problem for a
client to send two stanzas instead of one?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Philipp Hörist]

Hi,

As this is about SPAM we should aim for something very simple that everyone
will implement.

I think the XEP should be standalone, not tied to anything else at first.
So Server developers can implement it without having to implement anything
else.

Afterwards we could do the addition to blocking command for the report
function, as long as there is discovery for this additional feature to
blocking command i see no problem with that from the point of a client
developer.

Philipp



2017-09-11 23:44 GMT+02:00 Evgeny Khramtsov :

> Mon, 11 Sep 2017 16:32:23 -0500
> Sam Whited  wrote:
>
> > but if it is a spam report you probably always want it to result in a
> > block.
>
> So, probably? Or are you absolutely sure?
> Another question is what if the server doesn't have XEP-0191 module
> running, but, instead, have XEP-0016 running? Ah, I forgot, we don't
> care about backward compatibility anymore.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Mon, 11 Sep 2017 16:32:23 -0500
Sam Whited  wrote:

> but if it is a spam report you probably always want it to result in a
> block.

So, probably? Or are you absolutely sure?
Another question is what if the server doesn't have XEP-0191 module
running, but, instead, have XEP-0016 running? Ah, I forgot, we don't
care about backward compatibility anymore.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Guus der Kinderen]

Blocking Reason and Spam Reporting 2.0 could happily coexist. :-)

On 11 Sep 2017 23:32, "Sam Whited"  wrote:

> On Mon, Sep 11, 2017, at 16:29, Evgeny Khramtsov wrote:
> > Let me answer. Because he thinks that those two actions should be
> > always performed together. But in this case why do we need to have a
> > spam reporting mechanism? Let's assume that the blocked person is
> > always a spammer.
>
> Maybe this should hav been called "blocking reason". The reason for a
> block might not always be spam, but if it is a spam report you probably
> always want it to result in a block.
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Mon, Sep 11, 2017, at 16:29, Evgeny Khramtsov wrote:
> Let me answer. Because he thinks that those two actions should be
> always performed together. But in this case why do we need to have a
> spam reporting mechanism? Let's assume that the blocked person is
> always a spammer.

Maybe this should hav been called "blocking reason". The reason for a
block might not always be spam, but if it is a spam report you probably
always want it to result in a block.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Mon, 11 Sep 2017 23:07:57 +0200
Holger Weiß  wrote:

> I think it's obvious that you're not responding to the actual question
> here, and I wonder why :-)

Let me answer. Because he thinks that those two actions should be
always performed together. But in this case why do we need to have a
spam reporting mechanism? Let's assume that the blocked person is
always a spammer.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Mon, Sep 11, 2017, at 16:08, Holger Weiß wrote:
> Your assumption might be right or wrong.  Using a separate query copes
> with both cases.

It also means the block and the spam report are no longer correlated and
that there are more round trips with the server. Both of these don't
seem desirable to me.

As is, this XEP is very simple, I'd like to keep it that way.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Holger Weiß]

* Sam Whited  [2017-09-11 15:32]:
> I don't see why you'd want to report spam without also blocking the
> sender personally.

Your assumption might be right or wrong.  Using a separate query copes
with both cases.

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Holger Weiß]

* Sam Whited  [2017-09-11 15:54]:
> On Mon, Sep 11, 2017, at 15:39, Evgeny Khramtsov wrote:
> > What is the problem with this??? The software should be modular and, if
> > possible, there should be as less dependencies between modules as
> > possible. 
> 
> I agree with this. Why does this imply you need two modules? Build it
> into the blocking command module.

I think it's obvious that you're not responding to the actual question
here, and I wonder why :-)  If you do see a downside in using a separate
query, I'd be interested as well.

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Mon, 11 Sep 2017 15:54:33 -0500
Sam Whited  wrote:

> On Mon, Sep 11, 2017, at 15:39, Evgeny Khramtsov wrote:
> > What if we decide to report SPAM to a separate entities?  
> 
> That is out of the scope of this spec; that's more complicated, and is
> not something that is allowed by this specification.
> 
> > Really, we're now creating problems out of nothing.  
> 
> I don't understand how this creates any problems; it is an XEP that
> lets you provide a reason when you block something.
> 
> > Let's just use a separate query.  
> 
> I don't think this is any better.
> 
> > What is the problem with this??? The software should be modular
> > and, if possible, there should be as less dependencies between
> > modules as possible.   
> 
> I agree with this. Why does this imply you need two modules? Build it
> into the blocking command module.

OK, I'm done. Do whatever you want.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Mon, Sep 11, 2017, at 15:39, Evgeny Khramtsov wrote:
> What if we decide to report SPAM to a separate entities?

That is out of the scope of this spec; that's more complicated, and is
not something that is allowed by this specification.

> Really, we're now creating problems out of nothing.

I don't understand how this creates any problems; it is an XEP that lets
you provide a reason when you block something.

> Let's just use a separate query.

I don't think this is any better.

> What is the problem with this??? The software should be modular and, if
> possible, there should be as less dependencies between modules as
> possible. 

I agree with this. Why does this imply you need two modules? Build it
into the blocking command module.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Guus der Kinderen]

I'm not arguing that the XEP should define anything but the payload (and
how entities do the initial reporting to their domain).

Although there's no harm in blocking the sender of the spam that you
reported, tying the two XEPs together implies that there are no other ways
to prevent the spam after the report.

To draw a parallel: when I mark an email as spam, I don't get a new inbound
mail filter rule. I'm depending on my service provider to ensure that I,
but perhaps also others, won't be bothered by the reported spam.

I'd propose to modify this XEP a little to do only pretty basic reporting
(to allow an end-user to send in a spam report) and have some
recommendations on what implementations could do with such reports
(blocking, sharing, what not), but leave the details of those actions to be
described in XEPs.


On 11 September 2017 at 22:32, Sam Whited  wrote:

> On Mon, Sep 11, 2017, at 15:29, Guus der Kinderen wrote:
> > I'm not sure if the "reporting" bit should automatically go hand in hand
> > with "blocking" specifically. There might be value in defining an entity
> > that simply just receives spam reports. Obviously, end-users generally
> > report spam because they want it to stop, but the goal of reporting could
> > be broader. I'd not be opposed to a XEP that does just that: manage spam
> > reports. The blocking bit is a logical extension to that, but there might
> > be other extensions: things like analysis, and reports sharing with
> > trusted
> > other parties, etc.
>
> That's fair, and maybe you could reuse the same payload for that, but I
> don't think this XEP should be expanded to cover anything else like
> report sharing. It's just about sending the report to the server in the
> first place. I don't see why you'd want to report spam without also
> blocking the sender personally.
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Mon, 11 Sep 2017 15:24:13 -0500
Sam Whited  wrote:

> In retrospect this flexibility feels poor to me; let's just have one
> way to do things (which should be an extension of the blocking
> command, IMO).

What if we decide to report SPAM to a separate entities? Really, we're
now creating problems out of nothing. Let's just use a separate query.
What is the problem with this??? The software should be modular and, if
possible, there should be as less dependencies between modules as
possible. I don't see any problems with a separate request. Or are you
trying to optimize traffic here again? :)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Mon, 11 Sep 2017 22:21:17 +0200
Guus der Kinderen  wrote:

> spam can be reported to any entity that advertises support,
> and could be inlined with Block if/when desired.

So a server should support both methods? This is even worse.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Mon, Sep 11, 2017, at 15:29, Guus der Kinderen wrote:
> I'm not sure if the "reporting" bit should automatically go hand in hand
> with "blocking" specifically. There might be value in defining an entity
> that simply just receives spam reports. Obviously, end-users generally
> report spam because they want it to stop, but the goal of reporting could
> be broader. I'd not be opposed to a XEP that does just that: manage spam
> reports. The blocking bit is a logical extension to that, but there might
> be other extensions: things like analysis, and reports sharing with
> trusted
> other parties, etc.

That's fair, and maybe you could reuse the same payload for that, but I
don't think this XEP should be expanded to cover anything else like
report sharing. It's just about sending the report to the server in the
first place. I don't see why you'd want to report spam without also
blocking the sender personally.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Guus der Kinderen]

I'm not sure if the "reporting" bit should automatically go hand in hand
with "blocking" specifically. There might be value in defining an entity
that simply just receives spam reports. Obviously, end-users generally
report spam because they want it to stop, but the goal of reporting could
be broader. I'd not be opposed to a XEP that does just that: manage spam
reports. The blocking bit is a logical extension to that, but there might
be other extensions: things like analysis, and reports sharing with trusted
other parties, etc.



On 11 September 2017 at 22:24, Sam Whited  wrote:

> On Mon, Sep 11, 2017, at 15:21, Guus der Kinderen wrote:
> > The integration with block is an optional part of the XEP, isn't it? I'm
> > reading it as: spam can be reported to any entity that advertises
> > support,
> > and could be inlined with Block if/when desired.
>
> Right now the only mechanism for reporting is the blocking command.
> However, the payload was described in such a way
> that it could be reusable if we wanted it to have its own special IQ
> later.
>
> In retrospect this flexibility feels poor to me; let's just have one way
> to do things (which should be an extension of the blocking command,
> IMO).
>
> —Sam
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Mon, Sep 11, 2017, at 15:21, Guus der Kinderen wrote:
> The integration with block is an optional part of the XEP, isn't it? I'm
> reading it as: spam can be reported to any entity that advertises
> support,
> and could be inlined with Block if/when desired.

Right now the only mechanism for reporting is the blocking command.
However, the payload was described in such a way 
that it could be reusable if we wanted it to have its own special IQ
later.

In retrospect this flexibility feels poor to me; let's just have one way
to do things (which should be an extension of the blocking command,
IMO).

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Mon, Sep 11, 2017, at 14:56, Evgeny Khramtsov wrote:
> I actually reported the issue here:
> https://mail.jabber.org/pipermail/standards/2017-January/031883.html
> 
> TL;DR: I don't like the inclusion of  element inside 
> element and, thus, will not implement it in such form. There should be
> a separate request for blocking.

Thanks!

After looking at it again, I do agree that it feels weird having this in
a separate spec. However, I don't think it feels weird having it be a
part of the blocking command (correlating the block and the reason for
the block makes lots of sense in my mind). Maybe this should be merged
into tXEP-0191 if that's still possible? Then everything is in one
place.

That being said, I also don't mind if it remains separate. If you
arbitrarily split some concept of modules base don XEP, that's your
choice, the XEPs shouldn't have to be formatted in such a way to make
sure that your modules don't have interdependencies. Just put this
functionality in whatever your blocking command extension is and be done
with it.

—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Guus der Kinderen]

The integration with block is an optional part of the XEP, isn't it? I'm
reading it as: spam can be reported to any entity that advertises support,
and could be inlined with Block if/when desired.

On 11 September 2017 at 21:56, Evgeny Khramtsov  wrote:

> Mon, 11 Sep 2017 12:32:09 -0500
> Sam Whited  wrote:
>
> > Is there anything missing you think a spam reporting XEP must do? Was
> > your implementation experience (clients and servers) smooth? Did you
> > find any part of using it especially painful? How are you using it and
> > is the data it provides you useful or should more information be
> > attatched? etc.
>
> I actually reported the issue here:
> https://mail.jabber.org/pipermail/standards/2017-January/031883.html
>
> TL;DR: I don't like the inclusion of  element inside 
> element and, thus, will not implement it in such form. There should be
> a separate request for blocking.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Evgeny Khramtsov]

Mon, 11 Sep 2017 12:32:09 -0500
Sam Whited  wrote:

> Is there anything missing you think a spam reporting XEP must do? Was
> your implementation experience (clients and servers) smooth? Did you
> find any part of using it especially painful? How are you using it and
> is the data it provides you useful or should more information be
> attatched? etc.

I actually reported the issue here:
https://mail.jabber.org/pipermail/standards/2017-January/031883.html

TL;DR: I don't like the inclusion of  element inside 
element and, thus, will not implement it in such form. There should be
a separate request for blocking.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] DEFERRED: XEP-0377 (Spam Reporting)

[Sam Whited]

On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote:
> XEP-0377 (Spam Reporting) has been Deferred because of inactivity.

Hi all. Spam reporting was just (correctly) deferred. Several servers
have implemented it, but only a handful of operators and client
developers, as far as I can tell so I wanted to see what the experience
with it is so far:

Is there anything missing you think a spam reporting XEP must do? Was
your implementation experience (clients and servers) smooth? Did you
find any part of using it especially painful? How are you using it and
is the data it provides you useful or should more information be
attatched? etc.

Thanks,
Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___