XSF Discussion - 2019-08-26

Interesting issue, regarding matching phone numbers in Telegram: https://www.forbes.com/sites/zakdoffman/2019/08/25/chinese-agencies-crack-telegram-a-timely-warning-for-end-to-end-encryption/

Just debugged an interesting issue with MAM messages being filtered out for MUCs, with prosody and mod_block_strangers.

https://issues.prosody.im/1410

I think that MIX would handle that better, but it is a good use case to keep in mind.

(also, thanks Zash)

np

Why would MIX handle it better?

"use case"

because you send presence to the channel JID

Zash: so archived messages come in from the same JID, and wouldn't be a 'stranger'

Zash: oh, and a channel is also a contact if you consider roster integration

jonas’: hmm? This is not a valid use case?

I’m not sure if I’d call it a use case :)

but that may be just my english

I meant the use case of wanting to block messages from strangers, and not getting any MUC archives (at all).

Not blocking full JID messages might help

Just because MUC is weird in that you send presence to room@server/nick, and get archived messages from room@server, and the filter cannot easily know the former.

Zash: it wouldn't help not getting spam, though.

You could keep track of outgoing stanzas of other types, eg the iq stanza

If full jids weren't static... sure

Zash: because a server will happily send messages directed to a full JID to whichever other resource.

the resource being dynamic wouldn't help

IM-NG would help with that.

well, MIX would also help, but for now we have neither

Not blocking like mod_block_strangers does would help too

ralphm: I think the full JID "redirect" works by treating the message as a bare jid, and then mod_block_strangers would block it

So then if resources were session identifiers instead of long-term easily guessable device identifiers then it would be hard for spammers

right

And indeed, maybe mod_block_strangers isn't the best approach. I can imagine various cases where you'd receive a message stanzas from a non-contact that you didn't direct presence to (bare or full).

And didn't want it blocked.

There are better approaches now, ask Ge0rG

mod_firewall works with heuristics.

Also blocking messages from strangers, server-wide, is a very bad idea.

There is a prosody module to keep track of MUCs, so mod_block_strangers could at least plug into that for whitelisting purposes

Ge0rG: so far mod_block_strangers worked pretty well for me, and the module you refer to is mentioned in the ticket linked above :-D

I'll check out mod_firewall

Ge0rG: also, I think that if you define rules for mod_firewall, you have to take this issue into account, as I don't think it is covered by the example in the documentation: ```# Rule to bounce messages from senders not in the roster who haven't been sent directed presence NOT IN ROSTER? NOT SENT DIRECTED PRESENCE TO SENDER? BOUNCE=service-unavailable```

ralphm: my rules depend on the user not being in the roster, but there are some other elements involved.

So do you think MAM archives for MUC work properly with mod_firewall?

ralphm: there is a disapproved SPAM WG for that, in which you can become a member after signing an NDA with the blood of your first-born.

That's a good filter

ralphm: I haven't tested it

ralphm: I assume so, because my heuristics strongly depend on the message body, and MAM fetches don't have a body

ah

I suppose mod_block_strangers could consider that, too

I'm anticipating the MAM version of https://rt-solutions.de/de/2017/01/cve-2017-5589_xmpp_carbons/

Well, sure, if a client isn't checking that it actually requested MAM and is waiting for <fin/>, and/or doesn't check the origin, this is going to suck.

ralphm: you know how client developers work? It works? ship ip!

All devs, really.

Right.

So all I need to do is: 1) wait for wide-scale MAM deployment 2) request an appropriate number of CVE IDs

I have no idea how well MAM is deployed.

There is a bunch of clients.

yaxim soon to be among them

// TODO: check origin

I have used gajim and conversations for a long time, I must be spoiled

Curious if Daniel knows of-hand if Conversations is checking the origin.

not reading the entire backlog? but checking the from of MAM messages? yes i do

also the query id

Nice

so even if one check fails; you'd have to guess a random query id

So if it doesn't match it just ignores it (for the purposes of being interpreted as a MAM message).

yes

yay

I had to work around the regular message parser parsing MAM messages, because it's running in a separate thread pool and I couldn't control when it ends. Luckily, this also fixed the issue.

Hi, someone just asked me about https://xmpp.org/extensions/inbox/message-retraction.html and I could not find any strong rejections of this, so maybe it could go forward? Half of the usage can be substituted by message corrections (removing messages you sent accidentally), the other half (moderating messages of other people in public channels) can be really needed

(e.g. you have a public channel and would like to be able to remove dick picks from the history after banning the one who sent it)

(especially if people are using a client which, for user-friendliness reasons, displays pictures by default)

MR 20190626T13:10:14Z 000 <dwd>  So it looks, to me, that message-deletion was almost accepted, but had its name changed as a result of council feedback - but I can't see it actually getting rejected. MR 20190626T13:10:47Z 000 <pep.>  Somebody not following up? MR 20190626T13:10:59Z 000 <dwd>  It was four years ago, though. But I think the general feel back then was that as long as we called it "retraction" and not "deletion", it'd be OK. MR 20190626T13:11:19Z 000 <dwd>  pep., Very hard to tell. I suspect it fell through the inter-council gap.

oh I missed that because I only grepped retraction

So yeah I guess somebody could repropose it

FWIW, retraction is much better than deletion indeed, as the latter can not actually be guaranteed.

I'm sure nobody from council will try to block this until reference attachments are sorted out

I sense sarcasm

There is also an impending inter council gap.

I don't see an issue accepting it as a XEP.

Of course there are comments on it. One obvious one: what kind of id to pass.

ralphm: maybe you didn't keep up with the submission of Reactions, then.

The example shows the stanza id, but it is not explicit.

Ge0rG: you missed all the messages I sent last week?

ralphm: messages to standards@? Maybe I've just skimmed them and forgot immediately, because there was nothing I disagreed with?

I'd have to check my mailbox.

But yes, I do wonder what happened with "ah, yes, we should indeed have a XEP covering this use case. Accepted. Now, let's write the long email on things that could be better in this proposal."

Ge0rG: no, in here

ralphm: can I repeat my excuse? It was a very long and very hot day, and my train is late.

When the train eventually arrives, I'll try to find a seat where I can use my laptop to read up on things.

Sure, it's been 32 °C here

I'm author on that proto xep, but very little memory about it now. I burned out on a lot of stuff around that time, so probably lost in a todo pile.

Lance: but back in the game now?

Enough to say send it back to Council for a vote and feedback.

🤣

🙈🙉🙊

My (extremely vague) recollection is that the part that I actually wanted was MUC moderation controls, and there were some questions if doing moderation via messages was appropriate vs having iq methods on a room.

Do you mean beyond people retracting their own messages?

Yeah. Admin/moderator cleanup cases

I'd expect those to be operations on the channel, indeed with iqs, with notifications coming from the room.

Right. I think _that_ is what waylaid the proposal from moving forward, and would still need to be solved.

Well, I don't think it should hold up the spec from being accepted.

Everything should be IQs, especially messages.