XSF Discussion - 2016-01-13


  1. dwd

    Board, anyone? I think Laura is still in a meeting that's running over.

  2. ralphm

    hi

  3. dwd

    Just us, then.

  4. dwd

    bear, ?

  5. dwd

    Oh, well. ralphm - anything happening with the Summit? And anything you need help with?

  6. ralphm

    nothing I can think of

  7. ralphm

    Just got some stickers delivered

  8. Kev

    Excellent. We like stickers

  9. ralphm

    They look great

  10. andy

    http://upload.strb.org:8081/bOdqEobC58xhgApH2NtkknvDG9s/uAzVHRT6YH8q4/97f14f1b7506484fa57532112ca25509.jpg

  11. andy is bringing stickers, too

  12. andy

    :)

  13. andy

    I'll be at FOSDEM on saturday, if anybody wants an OMEMO fish sticker :P

  14. SamWhited

    andy: Now I'm really sad I won't be there!

  15. andy

    SamWhited, give me your address and I'll mail you some

  16. SamWhited

    andy: Appreciated, but that's okay, probably not worth it to mail them all the way from the other side of the pond :)

  17. SamWhited

    (and I'm moving this weekend and am not entirely sure what my new address is anyways…)

  18. kalkin

    andy: they look awesome!

  19. ralphm

    SamWhited: never to late to book a ticket

  20. ralphm

    too late

  21. SamWhited tries to decide if an OMEMO sticker and some ribs are worth ~900 USD…

  22. kalkin

    SamWhited: Yeah we all could share a beer in bruessel on saturday :)

  23. kalkin

    SamWhited: let your company pay it. It's hmm .... an educational trip!

  24. kalkin

    :)

  25. SamWhited

    kalkin: They might, I haven't asked; I'm actually just really busy right now. I probably should have asked at least a month in advance though

  26. ralphm

    SamWhited: so no hipchat people at all?

  27. SamWhited

    ralphm: I don't think so; I was hoping the Jitsi guys were going to go, but I think they said something about doing something else that week too

  28. SamWhited

    We'll see; I'll ask my boss about it.

  29. kalkin

    SamWhited: 👍

  30. ralphm

    Jitsi used to do the Lounge with us, really sad they cancelled for this year

  31. SamWhited

    ralphm: Yah, I think they were pretty upset about that too. I know Emil was looking forward to it.

  32. ralphm nods

  33. winfried

    ralphm: who will be contacting aloft?

  34. thorsten

    Is here a party planning?

  35. ralphm

    I'd be happy to do that, but the list on the wiki isn't really filling up. Unless this is all, which would be disappointing

  36. winfried

    last call on the mailing list?

  37. ralphm

    winfried: yeah

  38. ralphm

    I'll try to do that today

  39. andy

    SamWhited, international postage is literally under 1 euro. I don't mind. It would probably just take a while to get there. But I've printed up way more stickers than I can possibly use anyway ;)

  40. SamWhited

    andy: Awesome! Sounds good then.

  41. thorsten

    andy: omemo stickers? ;)

  42. Flow

    dwd: how are PEP nodes with access-model roster related to privacy lists? Or did I get your comment in council@ wrong?

  43. Lance

    Flow: servers generally already have an implementation for doing access controls based on roster groups, because of pep/pubsub. so it shouldn't be too much additional complexity for a server to also implement roster group blocking if that is added to the blocking xep

  44. Flow

    Lance: I see, the question still is if we want that

  45. Lance nods

  46. Flow

    I'd like the idea of an ad-hoc based blocking xep

  47. Flow

    so servers can implement what they want

  48. Flow

    and the client UI would be more or less similar, no matter which client is used

  49. Flow

    that, and remove the "list" from privacy lists and then most people would be happy I believe

  50. Flow

    What I wonder is, if we need a mechanism to inform the user about blocked stanzas/messages, and if so, how it should look like

  51. Zash

    Flow: What direction?

  52. Lance

    that is already in the blocking xep, iirc, for outgoing things that are to blocked users

  53. Lance

    i would not expect to be informed that someone blocked you, if you try sending a stanza to them

  54. Flow

    Zash: incoming

  55. Flow

    i.e. a blocked entity send you a message

  56. Lance

    oh, that direction

  57. Zash

    That ... that's weird

  58. Flow

    but I always believe that the solution should be similar to what we do with email these days

  59. Flow

    i.e. a spam folder

  60. Flow

    and that's most likely not related to blocking

  61. Zash

    Did y'all see my post to the list?

  62. Flow

    because if you block someone you usually really do not want to receive anything from him/her

  63. Flow

    Zash: hard to tell :)

  64. Zash

    well, it was to operators becasue I replied to stpeter who posted to operators

  65. Zash

    Probably would have made sense to reply to standards@ too

  66. Lance

    Zash: +1, the current reporting mechanisms are not really aimed for use by end users

  67. Zash

    XEP-0287 which was mentioned seems to assume we already have the filtering in place

  68. Flow

    Zash: I do believe you can use xep287 without filtering

  69. Flow

    a server could always add <report/> and let the client report spim

  70. Flow

    or maybe even report spim over s2s

  71. Flow

    isn't that what you wanted? an easy way to report spim?

  72. Zash

    I'm a bit tired but it is not obvious to me how that would work

  73. Zash

    I was thinking something simple like this https://www.zash.se/simply-report-spam.html

  74. Lance

    +1. Add a user enterable description/reason, and maybe allow forwarding the original stanza

  75. Flow

    or use the stanza-id to link the original stanza

  76. Flow

    Zash: that does look similar to xep287 spim report

  77. Zash

    I wrote this before I saw 287

  78. Flow

    (which should also use xep359 IDs to link the spim stanza)

  79. Zash

    Flow: IDs assume that the server has those stored.

  80. Zash

    I don't want to assume that

  81. Zash

    I also don't want to attach more data to every stanza if it can be avoided

  82. Flow

    optional

  83. Lance

    The main thing lacking from 287 is optional user provided feedback, and ability to send a report without requiring a server to stamp additional data into stanzas for that purpose.

  84. Lance

    Its about more than just spam, we need a way for users to report harassment and other policy violations that aren't strictly spim

  85. Lance

    Which might not be the result of a single, particular stanza

  86. Zash

    Yeah

  87. Lance

    Arguably covered by http://xmpp.org/extensions/xep-0157.html

  88. Lance

    but it would be nice to have a more structured query, to ensure that the abuser jid is included correctly

  89. Zash

    Sounds like what I had in mind for the thing above :)

  90. Lance

    yep! just add a user comment field and i'd +1 it

  91. Lance

    the remaining question would be where to send it

  92. Zash

    To something that supports it

  93. Zash

    Either the bare server jid, your own account or maybe a remote thing that accepts reports

  94. dwd

    Flow, You've got to do group-lookup by jid to do the access-model anyway, so the privacy list additions in terms of code would not be huge.

  95. dwd

    Zash, Lance - I'd seriously look at STIX/IODEF for the reporting. I really don't like reinventing the wheel, and given they're both XML anyway it makes sense.

  96. Zash

    dwd: But NIH!! And huge XML spec

  97. fippo

    dwd: but isn't xml out of fashion?

  98. Lance

    yeah, i'd prefer to keep things simpler for clients to implement / users to use. use iodef/stix for inter-server reporting

  99. Zash

    You could write an informational spec that describes the absolute minimum of IODEF you would need as a client

  100. Flow

    I guess that absolut minimum would be something like xep287 reporting or simply-report-spam.

  101. ralphm

    and/or creating a mapping to it from a custom protocol you define. We did something similar with things like geoloc

  102. stpeter

    I'll note that we did have a bespoke format for the inter-server reporting earlier on and I changed it to IODEF because of standards compliance & existing code libraries. Zash is right that we could define a slimmed down profile of IODEF for client-to-server reporting, although a simple command that forwards a message and flags it as abusive doesn't seem completely wrong.

  103. ralphm nods

  104. Flow

    don't forget about the use case where you just want to report a malicious jid

  105. Lance

    Given the importance of the feature, I'm in favor of whatever will lead to clients and servers actually implementing it, and a simpler spec seems best for that.

  106. Flow

    such report should come optionally with a stanza in question (or a link to it's id) and a more detailed reason (spam, harrasment, fraud, ...)

  107. Flow

    Lance: exactly my thought

  108. stpeter

    sure, I don't disagree

  109. stpeter

    Flow: don't we know that a JID is malicious based on a particular stanza? (message, presence invite, etc.)

  110. Flow

    stpeter: not sure, if there is always a stanza to report at hand

  111. Flow

    but anyway the information that matters most is the JID, all other information (stanza, exact reason, ...) should be optional IMHO

  112. stpeter

    Sure.

  113. stpeter

    Flow: yes, I think you're right - and let's keep the reporting as simple as possible

  114. Kev

    > Flow: don't we know that a JID is malicious based on a particular stanza? (message, presence invite, etc.) Not really. <body>Hi there!</body> isn't malicious. Once. By the hundredth time they probably are as a set.

  115. Lance

    I've started some conversations with people working on abuse handling problems on various social media, and have gotten some useful feedback that I'll write up and send to standards@

  116. Lance

    One of the interesting points is that blocking really needs a sharing component to really do the job of mitigating/preventing abuse. otherwise the user has to receive & react to everything. (Which could be a substantial amount on other networks)

  117. Lance

    So at minimum, opening up my blocklist to let people on my roster see it would be a big help. Even better would be a way to make incorporating friends' block lists automatic (subscriptions?)

  118. stpeter

    huh interesting

  119. Lance

    federation makes things harder, of course :/, but there are other things to automatically filter on, such as age of accounts

  120. Lance

    most of that information would only be available inside each service, though

  121. fippo

    age of account... we tried that in psyc ~2003 lance :-)

  122. Lance

    fippo: as is tradition

  123. fippo

    it is still somewhat useful if the remote server is not evil. e.g. the case of a "public server" that gets abused

  124. stpeter

    I don't think that most XMPP servers have kept track of that

  125. stpeter

    although this account I'm using goes back to 1999 :P

  126. narcode

    :D

  127. narcode

    nice

  128. stpeter

    I'm still intrigued by reputation systems but I don't know if they're truly useful in practice ... http://xmpp.org/extensions/xep-0275.html

  129. narcode

    look complicated but could be really accurate“>For each room in which the user is banned (XEP-0045 "outcast"), divide the room's reputation by 10 and decrement the user's score by the result”

  130. Lance

    my server always returns a score of 100 for me, naturally :p

  131. Lance

    but I think that aside from 1) making it easy for users to report and 2) making it easier to populate block lists based on my network of friends, its a service operations problem, and not a protocol one

  132. Lance

    as in, new protocols won't solve things. operational work is needed

  133. fippo

    so apparently i've been logged in five years with one account and four years with the other since that feature was implemented. but that is way too little, probably there is a bug in t he counting!

  134. fippo

    reputation systems can make sense if we assume that it is evil clients abusing an open server

  135. stpeter

    fippo: I think we have a mix of evil servers (less common) and evil clients abusing open servers

  136. stpeter

    e.g., I'm pretty sure that buycc.me was/is an evil server

  137. fippo

    right. but there is quite some value in "public servers" (I have a hard time avoiding the term "open relay") coordinating against spam from evil clients

  138. stpeter

    yes

  139. stpeter

    by public server you mean a server that allows essentially anyone to register an account?

  140. fippo

    yeah.

  141. stpeter

    nod