XSF Discussion - 2020-10-22

>Personally I think it's correct as is. I don't like the current way most clients I've used send images (OOB and the URL in the body) and in my own clients I wouldn't want to do that because I personally expect to be able to send a separate message along with an image like most commercial messengers, MMS, etc. let you do. Sam on the ML. I'd really like to be able to send a caption together with an image/file too but using the message body might cause problems as afaik you have to put the URL of the uploaded file only there and not OOB if you use OMEMO as it only encrypts the body.

OOB does support a description, but I don't know if that shows up anywhere and you can't have it in the body with this undocumented body==url method.

I'm sure somebody will document the undocumented body==url method Real Soon Now™

Any day now

after reading 66 again I too believe it should be a seperate informational xep

because retrofitting 66 to cover the current usage is … bad…

Daniel: you could change §6 into §6.1 under a new section "Application Use Cases", and add inline media as §6.2

§6 already claims: > This section is non-normative.

+1

Daniel: did you have any pending further changes on CS'21 beyond the submitted and accepted PR?

none written down

i'd still like to mention styling

Daniel: +1 to that

Daniel: but now that XEP-0443 is in Last Call, it would be better to reply to standards@ with the suggestion

I'm sure there will be plenty controversy.

i don’t want to include it in the compliance part

just mention it

...from the "UX is outside of the scope of the XSF" faction ;)

Ge0rG [08:50]: > I'm sure somebody will document the undocumented body==url method Real Soon Now™ It's been documented on modernxmpp.org for months (years?) ;)

The face when you tell people they can't write a message along with the image they are sending

send the picture, then send a message

et voilà :p

Fixing the root cause might also be a solution ;)

MattJ: next time you do an XMPP poll, ask the people whether they knew about modernxmpp.org before you asked.

Daniel: would you write that email?

I can create a PR

Never ask the people if you don't know the out come

Or something along those lines

> Daniel: but now that XEP-0443 is in Last Call, it would be better to reply to standards@ with the suggestion

sorry, the email has arrived now ✏

Wouldn't it be helpful to give the reporter the ability to send the last (or last N) received message(s) with a 0377 report? How is a server operator supposed to know whether the complaint is legit or not if no debug logging is activated? ✏

mdosch: the problem is that a user could fake a spam report in that case

I've already asked back in the day to include the stanza-id (not the stanza id, ha-ha) of the offending message, so that the server operator can pull it from the user's MAM

Ge0rG: technically you could probably put something in the privacy policy that by reporting a jid as spam you give the operator permission to access your MAM for that account

Because in proper cases it's all spam messages anyway

Or just one really

No need to provide an individual id

Daniel: as I'm not convinced of the current status of 0377 and I refuse to implement it because the current implementations are a mere simulation of handling the problem, no.

Yes, I'd also say the "report this user" is giving you consent to access this particular chat.

And my privacy policy already contains a statement about messages automatically flagged as spam

Once 0377 can report actual spam messages / ensure that they are available in the user's MAM, and once there is useful admin escalation beyond writing something to the server log file, well, then we are talking.

That's implementation, nothing to do with the XEP itself.

Zash: https://mail.jabber.org/pipermail/standards/2017-September/033356.html

Right now it's only "X reported Y for $reason", no message content or message id.

I'm sure the current implementations are well-intentioned, but they don't work against real-life spambots with throw-away JIDs, which only spam you once or at most twice and then stop being used.

So a user will eagerly "block & report" the first one, then wonder why the same spam comes from a different user, then just give up in resignation

So effectively you are teaching users that "block & report" doesn't yield the desired effect.

Given a stanza-id, the server implementation could at least block the same message from being ever sent to the user again

That thread never turned into a XEP revision? Hrm

Anyone wanna volonteer to PR?

Zash: you just did!

I have -1 spare cycles at the moment.

Zash: do the PR, then you are at -2. Repeat often enough and you'll yield an integer overflow and have almost unlimited time

Zash: while you are at it, please specify that the report may contain zero, one or many stanza-id references.

FWIW, you could just allow stuffing a list of <stanza-id xmlns='urn:xmpp:sid:0'/> elements into the <report/>

> Given a stanza-id, the server implementation could at least block the same message from being ever sent to the user again That would be a big improvement. 😃

mdosch: oh really?

Does Sam still want to be author?

Again, I think this is unnecessary and silly

Users don't report individual messages in reality

"This message from the spam bot was spam, but none of the other messages were"

Seriously? :)

If we were to use References it'd allow you to report which bit of the body of a particular message was spammy, excluding the rest of the message.

MattJ: > "This message from the spam bot was spam, but none of the other messages were" > Seriously? :) It's for the operator to have a proof that it was a spambot and not a false complaint.

How does it add proof?

Like Daniel said, could just fetch the last few messages (probably only one or two) with that "contact" (MAM 'with') and ????

Assuming these go in MAM

If they don't, a stanza id is useless

> How does it add proof? You see the message was e.g. carder spam and not the ex-girlfriend which annoyed the user. In the latter case he can block her but there is no need for the server operator to take further actions.

Right now the reports are not really useful for me.

You can go and look up messages in the archive right now, you don't need an id

I think you mean evidence, rather than proof, FWIW. But I think Matt is right, at least for the type of spam we see at the moment looking at any messages in the archive would probably be sufficient.

> martin@mdosch.de reported shark2@404.city as spammer: no reason given > martin@mdosch.de reported comprehend@default.rs as spammer: no reason given So I have to dig in the archive now?

mdosch, and what do you think a stanza id will do for you?

> I think you mean evidence, rather than proof, FWIW. Maybe, no native speaker here.

But I also think that mdosch is right in that if you rely on whole-archive searching spammers will start sending legitimate-messages between themselves to make that more onerous, and highlighting where the admin should look helps.

> martin@mdosch.de reported shark2@404.city's message 25ee8f48-851d-4cb9-8d81-3c34b1f892ce as spam: no reason given

An immense improvement!

> mdosch, and what do you think a stanza id will do for you? The server module could fetch it and add it to the notification I hope. 😃

Ah, righ,t what I say is false. You know who submitted the report, so you can look at the spammer's history with that entity.

So I'm mostly with Matt, I think.

Just get the last three messages from Spammer to reporter and add it

mdosch, as I and everyone else already said, you don't need an id to query the archive

Kev: it's about automatic processing. Having a stanza-id or a list of stanza-ids will allow the server to automatically fetch the message content and to do smart content-based blocking

While *technically* you could just fetch the message history of the user with the reported JID without explicit consent, you still don't know which of the messages are the ones that you'd like to auto-block, maybe even for other users.

OTOH, the overhead of adding a list of stanza-ids to the protocol looks rather trivial

In the case or a real Spammer it will all be spam messages

how is the server admin supposed to know who's a real spammer?

You have to sanity check that either way

How is whatever receives the reports supposed to know that I'm not trying to game the reporting system?

> In the case or a real Spammer it will all be spam messages I recently got a sub and totally innocent looking message prior to the spam.

Some also send a simple 'Hello' first. You probably don't want to block this message content automatically.

The premise of adding stanza-id(s) to the report: 1) it helps admins (false) 2) clients will expose per-message reporting in their UI (hopefully false)

Yes. But that's independent of blocking with or without message id ✏

Yes exactly. The UX flow in my client will remain as 'block this user'

Not report this message

Daniel: "block this user and report the messages to the server admin"

You could have "report this conversation"

or "block this user // [ ] report message content"

Ge0rG, all that does is tell the server information it already has?! ✏

MattJ, it'd tell the admin about messages that got trough whatever spam filters are in place, so they can be further tuned.

Zash, messages that are blocked go into the archive?

MattJ: it's also about explicit consent

MattJ: GDPR and things

Ge0rG, it's absolutely not, the wire protocol has no bearing on consent at all

MattJ, ???

yeah, right. Let the admin sort out the GDPR issues.

Ge0rG, "the client sent me some ids, therefore the user consented to me reading them" is absolutely not going to stand up in the court of GDPR :)

MattJ: given explicit message flagging (a sane UI for which is probably not too far fetched), the server could block the content of those messages automatically in the future

MattJ: no, but a privacy policy where "messages flagged by the user as spam will be inspected" will

Zash, I don't understand what you're saying - how would it tell the admin anything?

Ge0rG, so when the user reports a greeting message, the server should block all greetings?

MattJ, messages that got trough the spam filter (and into the archive), those can be reported and let the admin see what got troguh

MattJ: to that user

Zash, but that is unrelated to whether stanza ids are included in the report, no?

MattJ: I also wanted to make 0377 depend on the user having MAM

MattJ: well, technically I don't care *how* it is technically implemented, as long as there is a way for the user / client to tell the server admin which messages are spam.

but the current combination of XEP and implementations is useless for me as a server admin trying to fight spam, and that hasn't changed in some three years.

and now I'm back to doing real work.

MattJ, well, "this message right here" vs "some of the recent messages this user sent" can be useful?

Zash, only if that's exposed in the UI

which as we just heard from one of the leading client authors, it won't be

Long-press the spam, "report this" ?

and I can understand why

what Zash said.

alternatively, have a list of the last N messages with checkboxes in front

...

Optional? If left out, its "something recently in this conversation"

<-- despair

Add it to the XEP, nobody will use it for many reasons, but at least it's there and we can stop talking about it then :)

But is 'only some of those messages are spam' a realistic scenario?

It will change absolutely nothing

That would require hijacking accounts right?

Is this happening on a large scale?

If we only care about spam

377 also has some stuff about "general abuse"

MattJ, one client author is not going to use it and another client author refuses to implement unless stuff... how2resolve?

Daniel: yes it is, because many spam bots start with a "hi" and then only follow up with spam if you respond

Well in that case the hi is spam as well

Not something you might want to train your filter with

Daniel: but not every hi is spam, whereas every spam message is

But Spam nonetheless

Yes. But it's part of a general pattern

Ultimately you want to block that as well

Yes.

But I won't come closer to that goal by receiving spam reports about messages that are only "hi"

If I was to report it manually I'd report that initial message as well

Except maybe if I get full XML of those messages from which I can derive even more things.

I often block people after sending me a single hi and nothing else

We just don't have reporting enabled

Anyway, if the server developers would rather fix the tooling than change the XEP, and if everybody is in agreement that all messages from a reported JID must be spam, then please just go on and implement the tooling! ✏

I look forward to your funding for that work :)

It doesn't seem too far fetched to actually do get some funding for that

I've said time and again that user spam reporting is worthless for me without having full XML of the offending content. Actually I'd even want to see the full presence XML, but nobody is storing that anyway.

MattJ: ironically, my existing approach works well enough without user reports.

Sure, I don't blame you for not wanting user reports right now, as they're unnecessary for anything you are doing

having to manually inspect user reports would actually worsen the situation for me.

But we need to have the protocol there and implemented, because we can do useful things when it is

and that includes capturing full XML if needed, even withot stanza ids

Ge0rG: Use it for metrics!

MattJ: we also disagree on that point ✏

Well I'm not going into that one again

MattJ: in that case please go on and implement useful things with the existing protocol

it's been there since 2017 ;)

I shall, at some point

I'd eagerly use it once it is actually reducing the cost for me vs. what I'm doing now

I've been doing a lot, but I have a lot to do in many different areas

MattJ: yes, we all suffer under limited time

I've put some serious research into this topic, including what existing tools and frameworks we can lean on (if properly integrated)

We're not the first people to suffer from spam and abuse :)

MattJ: yes, and there will be a time when xmpp spammers start to learn from other spammers

Also, how does reporting work in MUC/MIX?

Zash: you can report and block the MUC

Myeah...

well, you *could* implement 0377 on a MUC JID, but reports don't contain a timestamp or a message reference, so you'd end up reporting a random nickname.

good luck finding out who owned that nickname from the server's MAM

Occupant IDs

but of course you could add a XEP-0421 inside

I still think that 0421 is a sort of a privacy violation

Now for MUC... stanza-id would be useful :)

Vote-based XEP-0425?

can you say that again, louder?

Detaching the reporting from the blocking also makes more sense with MUC

would a report generate a popup on all logged in room moderators' clients?

There's prior art for that kind of thing, with asking for voice

I'd probably stick some ⚠️ symbol with a counter on the message or something, plus a notification

Said the server developer who isn't working on a client.

🕊

Oh :)

Guus?

here

Let's have a short one

0) Roll call

Me

eye

aye?

me.

1) Topics for decisions

1.1) Martin Dosch to be appointed to the Editor Work Team

This is a motion from Ralph via email. Martin applied, and has been approved by Council per the process (who knew?)

All that remains is that Board approves

and Ralph also sent a +1 on this via email

I am also +1, and thank Martin for volunteering :)

+1 for me

+1 too, thank you Martin

.

Just in time, pep. :)

+1 for Martin :)

%s/Martin/mdosch/ for local mentions :)

Excellent, approved unanimously

XSF_Martin

2) AOB

Looks like Trello has been tidied (thanks to Ralph/whoever did that)

There are a number of "Awaiting feedback" items that I'm not inclined to wade through right now unless someone wants to pick one up specifically

Just a note from me to say I'm not reapplying as member (membership expiring this quarter), nor for board.

:(

:(

Sorry to hear that, pep.

oh

Sad to hear that, hope all is right pep.

I follow the sentiments of Guus and Seve on this one

Yeah. I'm just spending my time differently. I'm more useful elsewhere

You'll be missed, though I hope you're not departing the community :)

Ok, let's wrap up the meeting

3) Date of next

+1w

ok

+1

4) Meeting closed

Thank you for picking up the steering wheel today MattJ

I'll send minutes for this and the previous meeting shortly

Thank you all. 😃

Thanks Martin!

mdosch, Github username? :)

mdosch

Shocking

Invite sent

Thanks

mdosch, also xmpp:editor@muc.xmpp.org?join

MattJ: somebody complained that 313 still recommends storing MUC messages in user archives in https://xmpp.org/extensions/xep-0313.html#business-storeret-user-archives - would be nice to change that

Probably also something about last calls.

Huh

As I suspected, that was added in the revision I wasn't involved in :)

And doesn't MIX depend on this?

(though we concluded that was generally not a good thing)

What message type does mix use? Do I even want to know?