XSF Discussion - 2019-08-26


  1. ralphm

    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/

  2. ralphm

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

  3. ralphm

    https://issues.prosody.im/1410

  4. ralphm

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

  5. ralphm

    (also, thanks Zash)

  6. Zash

    np

  7. Zash

    Why would MIX handle it better?

  8. jonas’

    "use case"

  9. ralphm

    because you send presence to the channel JID

  10. ralphm

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

  11. ralphm

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

  12. ralphm

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

  13. jonas’

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

  14. jonas’

    but that may be just my english

  15. ralphm

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

  16. Zash

    Not blocking full JID messages might help

  17. ralphm

    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.

  18. ralphm

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

  19. Zash

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

  20. Zash

    If full jids weren't static... sure

  21. ralphm

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

  22. ralphm

    the resource being dynamic wouldn't help

  23. jonas’

    IM-NG would help with that.

  24. ralphm

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

  25. Zash

    Not blocking like mod_block_strangers does would help too

  26. Zash

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

  27. Zash

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

  28. ralphm

    right

  29. ralphm

    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).

  30. ralphm

    And didn't want it blocked.

  31. Zash

    There are better approaches now, ask Ge0rG

  32. Ge0rG

    mod_firewall works with heuristics.

  33. Ge0rG

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

  34. Ge0rG

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

  35. ralphm

    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

  36. ralphm

    I'll check out mod_firewall

  37. ralphm

    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```

  38. Ge0rG

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

  39. ralphm

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

  40. Ge0rG

    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.

  41. ralphm

    That's a good filter

  42. Ge0rG

    ralphm: I haven't tested it

  43. Ge0rG

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

  44. ralphm

    ah

  45. ralphm

    I suppose mod_block_strangers could consider that, too

  46. Ge0rG

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

  47. ralphm

    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.

  48. Ge0rG

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

  49. ralphm

    All devs, really.

  50. Ge0rG

    Right.

  51. Ge0rG

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

  52. ralphm

    I have no idea how well MAM is deployed.

  53. Ge0rG

    There is a bunch of clients.

  54. Ge0rG

    yaxim soon to be among them

  55. Ge0rG

    // TODO: check origin

  56. ralphm

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

  57. ralphm

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

  58. Daniel

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

  59. Daniel

    also the query id

  60. ralphm

    Nice

  61. Daniel

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

  62. ralphm

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

  63. Daniel

    yes

  64. ralphm

    yay

  65. Ge0rG

    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.

  66. mathieui

    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

  67. mathieui

    (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)

  68. mathieui

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

  69. pep.

    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.

  70. mathieui

    oh I missed that because I only grepped retraction

  71. pep.

    So yeah I guess somebody could repropose it

  72. ralphm

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

  73. Ge0rG

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

  74. jonas’

    I sense sarcasm

  75. Ge0rG

    There is also an impending inter council gap.

  76. ralphm

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

  77. ralphm

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

  78. Ge0rG

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

  79. ralphm

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

  80. ralphm

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

  81. Ge0rG

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

  82. Ge0rG

    I'd have to check my mailbox.

  83. ralphm

    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."

  84. ralphm

    Ge0rG: no, in here

  85. Ge0rG

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

  86. Ge0rG

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

  87. ralphm

    Sure, it's been 32 °C here

  88. Lance

    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.

  89. ralphm

    Lance: but back in the game now?

  90. Lance

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

  91. ralphm

    🤣

  92. Ge0rG

    🙈🙉🙊

  93. Lance

    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.

  94. ralphm

    Do you mean beyond people retracting their own messages?

  95. Lance

    Yeah. Admin/moderator cleanup cases

  96. ralphm

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

  97. Lance

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

  98. ralphm

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

  99. Ge0rG

    Everything should be IQs, especially messages.