XSF Discussion - 2024-02-27

MattJ, it appears the semantics of the 'trust' attribute value are not defined in https://xmpp.org/extensions/inbox/xep-reporting-account-affiliations.html? is 100 high trust? or is it 0? I mean, I can guess that it is probably 100 that expressed the most trust, but I can not find this spelled out in the specification

Yeah, trust=0 is no trust, trust=100 is full trust. I can clarify this in the next update.

I'm still undecided about the embedding vs querying thing

Querying would put more load on the "victim" than the origin of whatever stanzas, right?

Yeah

MattJ, I haven't formed an opinion on embedding or not. That said, with embedding there is the danger of spoofing the information which should be also discussed in the specification and the specification should spell out countermeasures

countermeasures could include:

https://xmpp.org/extensions/inbox/xep-reporting-account-affiliations.html?#spoofing

right those, plus I wonder if a second hop server could also be required strip the embedded element if the sender doesn't announce the feature

uh, wait the spoofing section doesn't discuss the recipient ignoring the info element

is there a guide somewhere how to operate your own rtbl list that others can source?

MSavoritias fae.ve, it's "just" a simple pubsub node, so not really

so how would i go to making one for joinjabber and our prosody server?

Component "something.joinjabber.org" "pubsub"

so, unless I am missing something, a receiving client not using a xep-raa aware server could be xep-raa compliant and still be subject to spoofing? ✏

ah just an extra component okay

flow, I hadn't anticipated clients implementing RAA at all

does prosody have a guide how to add stuff manually in a pubsub node?

MattJ, ahh, so who is processing the <info/> element?

MSavoritias fae.ve, Prosody doesn't support that, you need to use some XEP-0060 client

damn :/ on to find a client then

MSavoritias fae.ve, libervia might be a good fit for this, but I haven't tested

I somehow assumed that the <info/> information is also processed by receiving clients

ah libervia is not packaged for guix

especially since it can also be embedded in <presence/> ✏

flow, for 1:1 stuff, the server will use it to filter stuff before it reaches a user's clients

For a MUC, the MUC would use it as part of whatever policies it applies (e.g. whether to automatically grant voice or not)

which server, the one of the sending entity or the one of the receiving entity?

ah i see also https://xmpp.org/extensions/xep-0377.html needs to be updated

flow, the receiving entity of course. The sending entity can just not forward it if it decides it's spam/abuse.

MattJ, what if only the sending server supports raa and not the receiving? then no filtering, for example of <info/> in <presence/>, will take place, or am I missing something? ✏

If only the sender supports, nothing will change

Both the sending and receiving server need to support it

how can you guarantee the constellation that both servers support it? seems easy to create a situation where only the sending server supports it ✏

Sure, that will be quite common

But the failure case is... just what we have today

RAA only adds, so there's no "problem" if the receiving server doesn't do anything with the info

but then the receiving server will not strip the element and a spoofed <info/> may arrive a the receiving client

The client doesn't need to do anything with that info

But if it does, it will need to follow the rules in the XEP to verify it

maybe, but the, potentially spoofed, <info/> arrives at the client and I assume sooner or later clients will be tempted use that information

flow, then they have to read the XEP or?

Then the client authors should read the XEP

Yes

Anything anyone sends you can be "spoofed"

not sure what you are trying to say, we cannot prevent people from exchanging stanzas with whatever content

MattJ, my initial point was that the xep does not mandate the receiving client to put spoofing countermeasures in place

just make it clear that this is information intended for servers, and clients shouldn't process it?

in § 7.2, in only says that "Receiving servers MUST ignore <info/>"

flow, right, I think this is because the XEP says things like "the receiving server MUST [...]" but it should say "receiving entity MUST [...]"

Because I did not expect that clients would implement this stuff

But they can if they want, the XEP will need some clarification

MattJ, now you got where I was heading at :) ✏

So I'll fix that, but also clarify a bit more my intention that the filtering decisions are typically expected to be implemented at the server level

I don't like a world where one of my clients is filtering spam locally, but it still arrives at all my other clients

it is also not clear to me why it is assumed by many that clients will not process the information. It seems kind of helpful for clients too

What will the clients do with it?

for example, visually indicate the trust level?

For what purpose?

Presumably by the time the user received the spam, they know it's spam

I'd like to stop it before it gets into their MAM archive

I hadn't really the spam use-case in mind, more like that if I am in a groupchat I may want to know if the other participants are on a burner jid or not

Mmm, right

to be clear, I am perfectly fine if the specification mandates that the element is removed before it arrives at the recipient

It can't really mandate that, because as you pointed out, the receiving server(s) might not support it

however, as we have figured out, you can't gurantee that this will happen because the recipient's server may not support xep-raa

So it's just in the same category of all the other information that might be included in a stanza, untrusted by default

well you can mandate it if the recipients server announce support for xep-raa

however, there appears to be little gain doing so

Hmm, I may actually be interested in not showing I'm on a burner jid :x

It's the same account after all ✏

s/all the other information/all the other information later embedded in the stanza by entities that are not the sending entity/ ✏

Same authenticated person rather

flow, you can't necessarily trust what's put in the stanza by the original entity, e.g. if they include <x xmlns="muc" affiliation="owner">

MUCs obviously strip that, but my point is that sending entities can lie too

MattJ, that <x/> wouldn't survive the MUC component and therefore not arrive at the recipient, would it?

Correct

so in a MUC I can trust the content of <x/>, but not if it was send in a 1:1 message (however, it is probably of little value there)

but in general, I really think we should tighten security, especially with regard to spoofing, by explicitly spelling out what each, of the usually 4 involved entities, is supposed to add/verify/strip/trust. given our history with spoofed informations issues, for example with carbons ✏

xep raa already did a good job, but it was missing the reciving client side. Of course, I get that this was because the author had in mind that the client does not see or process the <info/>. However, as we have established, it can not be guaranteed that the <info/> element arrives at the reciving client

I don't think it was missing the receiving client side, it's just that I wrote "server" instead of the more general "entity"

Because that was the only intended use case, but you're right that it could be used by clients too if they follow the same rules

MattJ: sure, wasn't trying to criticize you. I guess we are on the same page

heads up. i sent a proposal to update XEP-0377: Spam Reporting

to the mailing list

(i dont have a github account)

MSavoritias fae.ve, did you miss > Reports MAY contain a user provided message explaining or providing context about the reason for the report

sounds a client can put anything in there what you wish, exactly the label you mention

thats for the text tho no? not the reason urn

the text field that is

if i can add any reason in the urn then yeah thats what i want

fwiw I also think these categories aren't exactly.. adequate. It's certainly not the only two options, it's also not entirely clear what these options mean

> heads up. i sent a proposal to update XEP-0377: Spam Reporting > > to the mailing list > > (i dont have a github account) Discussing this on the mailing list is the correct way fwiw. You don't need a github account for that

MSavoritias fae.ve, if you can put anything in a defined attribute, its free text, exactly what you have with the <text> element in the XEp

of course we could extend the defined reasons, but they will never be complete

i think we are talking past each other here. i mean i want to do: urn:xmpp:reporting:hate-speech

or urn:xmpp:reporting:transphobia

I may or may not make sense to register additional reasons. I don't think it makes sense to have two free text fields (duplicating text)

Daniel, title / description wouldn't be too bad imo

hmm maybe. basically the usecase is that: i would like to be able to have categories on a db with these reports

Or maybe some predefined reasons on the entity to report to, dunno

(that means another round-trip though)

One is for automation / check box thingy and thus should offer a limited amount of options (even if one of the options might be 'other') the other is where the user can enter a description

and as a server operator/person that uses an app to see what categories a block belongs too

as said makes sense to add a few more

but free text is already possible

i simply doubt that its much use when users pick the category

admin has to read the messages anyway

Certainly we don't have the same considerations regarding moderation :P

apparently its supported already to add stuff https://xmpp.org/extensions/xep-0377.html#registrar-reporting

i just fail to see why i should care about the category a users picks for a message he does not like

Using the examples from the mailing list post: is there a situation where you would want to filter out hate speech but allow transphobia? I don't think so. Is there harm in just categorizing them as "abuse" and using the text field for more detail if needed?

(that's what xmppbl.org basically does)

not that specifically. but imagine if somebody wants to block cryptocurrency

but somebody else doesnt

There are a practically infinite number of kinds of abuse, and it's going to be impossible to define them all

So it's hard to know, if we start, where to stop

sure. thats why pep. said to make it free form :)

and if we don't stop, it will just become equivalent to the existing <text> field

The <text> field is already there for that

a synopsis on top or tags could work the same way

the text is more a description tho no? its no tags or categories

I think support for multiple reasons could be the answer, if any

So that implementations that only support "urn:xmpp:reporting:abuse" can still understand that, but implementations that understand more detail can use the more detailed reasons

pep.> Or maybe some predefined reasons on the entity to report to, pep.> (that means another round-trip though)

That'd be tricky? Not really?

also just thought about it

we should have references too

Add that to disco#info somewhere on the entity and other entities can query it?

To avoid breaking compatibility too much, it probably just makes sense to define child elements for additional "tags"

yeah, im sure as hell dont implement every month the newest fancy phobia anyone wants to tag

lovetox, wtf?

fancy phobia?

if they are customizable you dont have to :)

a visual example of what i am thinking at https://gui.fediseer.com/instances/censured

MSavoritias fae.ve: what use case do you have in mind where you need categorization? My personal use case is 'user reports unwanted content', admin takes a look, bans account if necessary

it has instance, reasons/categories and evidence

lovetox, maybe you're not subject to these and good for you, but don't dismiss them as if it didn't exist ✏

lovetox, I'd like to remind you about XEP-0458, section 2.2, 2.3, 2.4 and 2.5 ✏

> a visual example of what i am thinking at https://gui.fediseer.com/instances/censured Daniel this is what i have in mind ^

it has multiple reasons and also evidence/reciepts

I don't think that level of detail can really be enshrined in a XEP, and I don't think even a registry (at the XSF anyway) would suit that data

not xsf no. but what if we had fediseer in xmpp ?

as a seperate project

if you mean level of detail by multiple reasons no

jonas’, are you saying im breaching code of conduct, because as a developer i state that i will not every month add new phobias to a list of report reasons?

lovetox, yes, very much.

the terminology "fancy phobias" is dismissive at the very least.

i think a customizable field for reasons and a reciept that can be url or a picture or something would be a good step to make this usable

(Also "phobia" isn't the proper term, but that's another debate, these words do contain "-phobia" currently so..)

which again its basically what fediseer already does.

i dont see how an admin can use rtbl or get reports without evidence atm. and an rtbl without categories/reasons or evidence is not very transparent

the current rtbl does have reasons ftr

but no evidence indeed

Yeah currently the rtbl is based on trust on specific individuals ✏

> the current rtbl does have reasons ftr right sorry. i meant reasons beside abuse and spam

me too

it's essentially a free-form field

MSavoritias fae.ve, it has text descriptions for the entries, often explaining what occurred, and where

I say "often" because it's not strictly enforced, especially if there is a wave of JIDs in short succession, but that's partly the fault of the tooling which could be improved

As far as I can tell, Fediseer has no canonical list of reasons

It just relies on freeform text and word matching

it does yeah.

i do think that adding more reasons on the urn is impractical.

because they will become too many and/or be restrictive

the more reasons there are, the less helpful is it to you as admin

my main thought was that "reason" could be used to automatically short or put in categories a blocklist

but you should not block people automatically because someone reports them ..

That's obviously not what is being discussed

another example https://tweaking.thebad.space/location/4e1cca60-50b7-4f24-b9ed-2e31ee9fce57 it has a seperate description which is text for us. and also a reference that is evidence or reciepts

MSavoritias fae.ve, probably just encourage people to add a reason, and use something like https://github.com/Fediseer/fediseer/blob/c72866a4eeb875e7624a4cebdb871294ad1cbf2b/fediseer/apis/v1/censures.py#L71

so filter on the text you mean?

> but you should not block people automatically because someone reports them .. if you trust the blocklist you should. and it already happens with rtbl

the current instance that is

I just added the "evidence" part to Prosody's mod_spam_report_forwarder a day or two ago. I think Conversations already supports it.

ah so its just the xep lagging behind

ok

No, see for example here where it references two messages: https://xmpp.org/extensions/xep-0377.html#example-5

ah so basically you give the stanza-ids to the server operator as evidence and they search them on their server?

Yes

But does the entity that get these have access to these messages?

Well Prosody does this for you automatically

hmm. okay then. this seems better than just links tbh

pep., Prosody will include the full message in an external report

That format could be documented in the XEP, I'm using it for a bunch of things

It's just <forward>

I guess if you're in a MUC you should report that to the MUC? Or would you report that to your own server? both? all involved entities?

Good question, I don't think we have MUCs sorted yet

I guess yes, report to the MUC

Since MUCs are "opt in" anyway, it's not exactly up to your own admin to deal with that stuff (unlike incoming presence/messages)

But I can also imagine it might be useful to report a MUC elsewhere, so we should have a standard way to do that

also MUCs, have moderators ..

That could be reported to moderators of the MUC by the MUC itself maybe. Also if moderators are away that can be forwarded to operators

though sometimes spamers join, and then you actually want to report them to their home server

Yeah, so in that case it ideally goes to the MUC, which has their JID (even if the reporter does not)

Another use case is banning someone, and including a report for their server

... i think this will get confusing or is a thin line

because people get removed from MUCs for a lot of reasons

and not all are stuff that you need to report to their server operator

Sure

Most other platforms make it quite straightforward. Removing someone from a group and flagging/reporting them are different UI actions.

Flagging/reporting will generally also block/remove them though

reporting could be very useful depending on what they did yeah

Assuming you have the power to do that (if you're not the owner of the group, it may need an admin or someone else to take action)

i would expect a server operator to delete a user that is transphobic

for example

oh i see server operators will have fun, remember me to never become one

And for the record, there is probably stuff that we want to do that I consider strictly outside the scope of XEP-0377

lovetox, indeed, I don't advise it

do we need a feature to flag server operators that dont agree with our reports?

I would also expect servre operators to delete transphobic users. The least we can do is give them the information. If it doesn't happen I'd probably defederate

lovetox, are you seriously going this way?

> do we need a feature to flag server operators that dont agree with our reports? flag where

defederate probably yeah

I mean, questioning the necessity of these actions

thats why i have been asking about the rtbl

pep., did you not just say the same thing? if a server operator does not agree with your reports you "defederate" which means blocking

Yes blocking

> do we need a feature to flag server operators that dont agree with our reports? I think they are talking about creating a block list (that you don't have to subscribe to)

That's what fediseer is about

yep. its a blocklist

If a server operator does not handle reports to ensure the traffic their server emits conforms with the values of a specific block list, that block list should probably block that server, but I'm not sure whether that needs protocol?

Sure. You can't expect everyone to just know that

personally the question came because i saw the rtbl used 377 so i was wondering if I could use it to make a "badspace" for xmpp

as in the blocklist

can server be blocked in third party MUCs? Say you are A and block B, but A.user and B.user meet in C.MUC

they can talk to each other or?

Yeah no these two users can still talk via third-party

they can, yeah

> personally the question came because i saw the rtbl used 377 so i was wondering if I could use it to make a "badspace" for xmpp I'd say "yes", definitely

AFAICT, again, the badspace list is just freeform

and if you want to communicate more than that, take advantage of XMPP's extensibility and layer in some tagging

The additional tags don't need to be part of XEP-0377, you can just provide info for consumers of the list (if you want them to understand the tags)

But current solutions seem to be doing fine (?) without that

yeah tbh the biggest problems with this is: governance model, appeals and how to deal with people who dont like you

i doubt xmpp is going to be the problem

I have been thinking about those things too

the easiest i have thought is to have jj CoC as the rules and have the abuse room as a place for reports

appeals is the tricky part.

> and how to deal with people who dont like you step 1: get a hoster with DDoS mitigation.

MattJ: the main raa spoofing problem is if the receiver supports but not the sender, right?

singpolyma, right

If a recipient of the stanza doesn't support RAA then it doesn't matter if it's spoofed