XSF Discussion - 2020-10-22


  1. mdosch

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

  2. Zash

    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.

  3. Ge0rG

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

  4. Zash

    Any day now

  5. Daniel

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

  6. Daniel

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

  7. Ge0rG

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

  8. Ge0rG

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

  9. flow

    +1

  10. Ge0rG

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

  11. Daniel

    none written down

  12. Daniel

    i'd still like to mention styling

  13. Ge0rG

    Daniel: +1 to that

  14. Ge0rG

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

  15. Ge0rG

    I'm sure there will be plenty controversy.

  16. Daniel

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

  17. Daniel

    just mention it

  18. Ge0rG

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

  19. MattJ

    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?) ;)

  20. Seve

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

  21. edhelas

    send the picture, then send a message

  22. edhelas

    et voilà :p

  23. Seve

    Fixing the root cause might also be a solution ;)

  24. Ge0rG

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

  25. Ge0rG

    Daniel: would you write that email?

  26. Daniel

    I can create a PR

  27. Daniel

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

  28. Daniel

    Or something along those lines

  29. Ge0rG

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

  30. Ge0rG

    (it's no problem to say "no", I'd just like to know because otherwise I'd write that)

  31. Ge0rG

    sorry, the email has arrived now

  32. mdosch

    Wouldn't it be helpful to give the reporter the ability to send the last (or last N) received messages 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?

  33. mdosch

    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?

  34. Ge0rG

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

  35. Ge0rG

    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

  36. Daniel

    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

  37. Daniel

    Because in proper cases it's all spam messages anyway

  38. Daniel

    Or just one really

  39. Daniel

    No need to provide an individual id

  40. Ge0rG

    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.

  41. mdosch

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

  42. Ge0rG

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

  43. Ge0rG

    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.

  44. Zash

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

  45. Ge0rG

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

  46. mdosch

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

  47. Ge0rG

    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.

  48. Ge0rG

    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

  49. Ge0rG

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

  50. Ge0rG

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

  51. Zash

    That thread never turned into a XEP revision? Hrm

  52. Zash

    Anyone wanna volonteer to PR?

  53. Ge0rG

    Zash: you just did!

  54. Zash

    I have -1 spare cycles at the moment.

  55. Ge0rG

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

  56. Ge0rG

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

  57. Ge0rG

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

  58. mdosch

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

  59. Ge0rG

    mdosch: oh really?

  60. Zash

    Does Sam still want to be author?

  61. MattJ

    Again, I think this is unnecessary and silly

  62. MattJ

    Users don't report individual messages in reality

  63. MattJ

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

  64. MattJ

    Seriously? :)

  65. Kev

    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.

  66. mdosch

    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.

  67. MattJ

    How does it add proof?

  68. Zash

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

  69. Zash

    Assuming these go in MAM

  70. MattJ

    If they don't, a stanza id is useless

  71. mdosch

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

  72. mdosch

    Right now the reports are not really useful for me.

  73. MattJ

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

  74. Kev

    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.

  75. mdosch

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

  76. MattJ

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

  77. mdosch

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

  78. Kev

    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.

  79. MattJ

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

  80. MattJ

    An immense improvement!

  81. mdosch

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

  82. Kev

    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.

  83. Kev

    So I'm mostly with Matt, I think.

  84. Daniel

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

  85. MattJ

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

  86. Ge0rG

    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

  87. Ge0rG

    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.

  88. Ge0rG

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

  89. Daniel

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

  90. Ge0rG

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

  91. Daniel

    You have to sanity check that either way

  92. Zash

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

  93. mdosch

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

  94. mdosch

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

  95. Daniel

    Yes. But that's independent of blocking with or without message I'd

  96. MattJ

    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)

  97. Daniel

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

  98. Daniel

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

  99. Daniel

    Not report this message

  100. Ge0rG

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

  101. Zash

    You could have "report this conversation"

  102. MattJ

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

  103. Ge0rG

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

  104. MattJ

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

  105. Zash

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

  106. MattJ

    Zash, messages that are blocked go into the archive?

  107. Ge0rG

    MattJ: it's also about explicit consent

  108. Ge0rG

    MattJ: GDPR and things

  109. MattJ

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

  110. Zash

    MattJ, ???

  111. Ge0rG

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

  112. MattJ

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

  113. Ge0rG

    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

  114. Ge0rG

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

  115. MattJ

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

  116. MattJ

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

  117. Zash

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

  118. Ge0rG

    MattJ: to that user

  119. MattJ

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

  120. Ge0rG

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

  121. Ge0rG

    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.

  122. Ge0rG

    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.

  123. Ge0rG

    and now I'm back to doing real work.

  124. Zash

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

  125. MattJ

    Zash, only if that's exposed in the UI

  126. MattJ

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

  127. Zash

    Long-press the spam, "report this" ?

  128. MattJ

    and I can understand why

  129. Ge0rG

    what Zash said.

  130. Ge0rG

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

  131. MattJ

    ...

  132. Zash

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

  133. MattJ

    <-- despair

  134. MattJ

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

  135. Daniel

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

  136. MattJ

    It will change absolutely nothing

  137. Daniel

    That would require hijacking accounts right?

  138. Daniel

    Is this happening on a large scale?

  139. Zash

    If we only care about spam

  140. Zash

    377 also has some stuff about "general abuse"

  141. Zash

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

  142. Ge0rG

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

  143. Daniel

    Well in that case the hi is spam as well

  144. Daniel

    Not something you might want to train your filter with

  145. Ge0rG

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

  146. Daniel

    But Spam nonetheless

  147. Daniel

    Yes. But it's part of a general pattern

  148. Daniel

    Ultimately you want to block that as well

  149. Ge0rG

    Yes.

  150. Ge0rG

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

  151. Daniel

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

  152. Ge0rG

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

  153. Daniel

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

  154. Daniel

    We just don't have reporting enabled

  155. Ge0rG

    Anyway, if the server admins 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!

  156. Ge0rG

    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!

  157. MattJ

    I look forward to your funding for that work :)

  158. Daniel

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

  159. Ge0rG

    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.

  160. Ge0rG

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

  161. MattJ

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

  162. Ge0rG

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

  163. MattJ

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

  164. Ge0rG

    MattJ: we also disagree on that poing

  165. MattJ

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

  166. Zash

    Ge0rG: Use it for metrics!

  167. Ge0rG

    MattJ: we also disagree on that point

  168. MattJ

    Well I'm not going into that one again

  169. Ge0rG

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

  170. Ge0rG

    it's been there since 2017 ;)

  171. MattJ

    I shall, at some point

  172. Ge0rG

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

  173. MattJ

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

  174. Ge0rG

    MattJ: yes, we all suffer under limited time

  175. MattJ

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

  176. MattJ

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

  177. Ge0rG

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

  178. Zash

    Also, how does reporting work in MUC/MIX?

  179. Ge0rG

    Zash: you can report and block the MUC

  180. Zash

    Myeah...

  181. Ge0rG

    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.

  182. Ge0rG

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

  183. Zash

    Occupant IDs

  184. Ge0rG

    but of course you could add a XEP-0421 inside

  185. Ge0rG

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

  186. MattJ

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

  187. Zash

    Vote-based XEP-0425?

  188. Ge0rG

    can you say that again, louder?

  189. Zash

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

  190. Ge0rG

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

  191. Zash

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

  192. Zash

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

  193. Zash

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

  194. Seve

    🕊

  195. MattJ

    Oh :)

  196. MattJ

    Guus?

  197. Guus

    here

  198. MattJ

    Let's have a short one

  199. MattJ

    0) Roll call

  200. MattJ

    Me

  201. Guus

    eye

  202. Guus

    aye?

  203. Guus

    me.

  204. Seve says "me"

  205. MattJ

    1) Topics for decisions

  206. MattJ

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

  207. MattJ

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

  208. MattJ

    All that remains is that Board approves

  209. MattJ

    and Ralph also sent a +1 on this via email

  210. MattJ

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

  211. Guus

    +1 for me

  212. Seve

    +1 too, thank you Martin

  213. pep.

    .

  214. MattJ

    Just in time, pep. :)

  215. pep.

    +1 for Martin :)

  216. jonas’

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

  217. MattJ

    Excellent, approved unanimously

  218. MattJ

    XSF_Martin

  219. MattJ

    2) AOB

  220. MattJ

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

  221. MattJ

    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

  222. pep.

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

  223. MattJ

    :(

  224. Zash

    :(

  225. Guus

    Sorry to hear that, pep.

  226. jonas’

    oh

  227. Seve

    Sad to hear that, hope all is right pep.

  228. jonas’

    I follow the sentiments of Guus and Seve on this one

  229. pep.

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

  230. MattJ

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

  231. MattJ

    Ok, let's wrap up the meeting

  232. MattJ

    3) Date of next

  233. MattJ

    +1w

  234. pep.

    ok

  235. Seve

    +1

  236. MattJ

    4) Meeting closed

  237. Seve

    Thank you for picking up the steering wheel today MattJ

  238. MattJ

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

  239. mdosch

    Thank you all. 😃

  240. emus

    Thanks Martin!

  241. MattJ

    mdosch, Github username? :)

  242. mdosch

    mdosch

  243. MattJ

    Shocking

  244. MattJ

    Invite sent

  245. mdosch

    Thanks

  246. jonas’

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

  247. Ge0rG

    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

  248. Ge0rG

    Probably also something about last calls.

  249. MattJ

    Huh

  250. MattJ

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

  251. MattJ

    And doesn't MIX depend on this?

  252. MattJ

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

  253. Ge0rG

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