andyI'll be at FOSDEM on saturday, if anybody wants an OMEMO fish sticker :P
SamWhitedandy: Now I'm really sad I won't be there!
bjchas joined
andySamWhited, give me your address and I'll mail you some
SamWhitedandy: Appreciated, but that's okay, probably not worth it to mail them all the way from the other side of the pond :)
SamWhited(and I'm moving this weekend and am not entirely sure what my new address is anyways…)
kalkinandy: they look awesome!
ralphmSamWhited: never to late to book a ticket
ralphmtoo late
SamWhitedtries to decide if an OMEMO sticker and some ribs are worth ~900 USD…
kalkinSamWhited: Yeah we all could share a beer in bruessel on saturday :)
kalkinSamWhited: let your company pay it. It's hmm .... an educational trip!
kalkin:)
SamWhitedkalkin: 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
artyhas left
ralphmSamWhited: so no hipchat people at all?
SamWhitedralphm: 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
SamWhitedWe'll see; I'll ask my boss about it.
kalkinSamWhited: 👍
ralphmJitsi used to do the Lounge with us, really sad they cancelled for this year
SamWhitedralphm: Yah, I think they were pretty upset about that too. I know Emil was looking forward to it.
ralphmnods
winfriedralphm: who will be contacting aloft?
thorstenIs here a party planning?
ralphmI'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
winfriedlast call on the mailing list?
stpeterhas joined
ralphmwinfried: yeah
ralphmI'll try to do that today
intosihas left
andySamWhited, 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 ;)
SamWhitedandy: Awesome! Sounds good then.
thorstenandy: omemo stickers? ;)
intosi has joined
Lancehas joined
intosi has left
intosi has joined
Lancehas joined
dwdhas left
winfriedhas left
foss81405971has joined
foss81405971has joined
Flowdwd: how are PEP nodes with access-model roster related to privacy lists? Or did I get your comment in council@ wrong?
danielhas left
LanceFlow: 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
FlowLance: I see, the question still is if we want that
Lancenods
FlowI'd like the idea of an ad-hoc based blocking xep
Flowso servers can implement what they want
Flowand the client UI would be more or less similar, no matter which client is used
Flowthat, and remove the "list" from privacy lists and then most people would be happy I believe
Jake1984has left
Jake1984has joined
soulhas left
soulhas joined
FlowWhat I wonder is, if we need a mechanism to inform the user about blocked stanzas/messages, and if so, how it should look like
Flowhas left
ZashFlow: What direction?
Lancethat is already in the blocking xep, iirc, for outgoing things that are to blocked users
Lancei would not expect to be informed that someone blocked you, if you try sending a stanza to them
FlowZash: incoming
Flowi.e. a blocked entity send you a message
Lanceoh, that direction
ZashThat ... that's weird
Flowbut I always believe that the solution should be similar to what we do with email these days
Flowi.e. a spam folder
Flowand that's most likely not related to blocking
ZashDid y'all see my post to the list?
Flowbecause if you block someone you usually really do not want to receive anything from him/her
FlowZash: hard to tell :)
Zashwell, it was to operators becasue I replied to stpeter who posted to operators
ZashProbably would have made sense to reply to standards@ too
LanceZash: +1, the current reporting mechanisms are not really aimed for use by end users
ZashXEP-0287 which was mentioned seems to assume we already have the filtering in place
waqashas joined
FlowZash: I do believe you can use xep287 without filtering
Flowa server could always add <report/> and let the client report spim
Flowor maybe even report spim over s2s
Flowisn't that what you wanted? an easy way to report spim?
ZashI'm a bit tired but it is not obvious to me how that would work
ZashI was thinking something simple like this https://www.zash.se/simply-report-spam.html
Lance+1. Add a user enterable description/reason, and maybe allow forwarding the original stanza
Flowor use the stanza-id to link the original stanza
FlowZash: that does look similar to xep287 spim report
ZashI wrote this before I saw 287
Flow(which should also use xep359 IDs to link the spim stanza)
Ashley Wardhas left
ZashFlow: IDs assume that the server has those stored.
ZashI don't want to assume that
dwdhas left
ZashI also don't want to attach more data to every stanza if it can be avoided
Flowoptional
dwdhas left
LanceThe 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.
LanceIts about more than just spam, we need a way for users to report harassment and other policy violations that aren't strictly spim
LanceWhich might not be the result of a single, particular stanza
ZashYeah
LanceArguably covered by http://xmpp.org/extensions/xep-0157.html
dwdhas left
Lancebut it would be nice to have a more structured query, to ensure that the abuser jid is included correctly
ZashSounds like what I had in mind for the thing above :)
Lanceyep! just add a user comment field and i'd +1 it
Lancethe remaining question would be where to send it
Lancehas left
soulhas left
Lancehas joined
ZashTo something that supports it
ZashEither the bare server jid, your own account or maybe a remote thing that accepts reports
intosi has joined
dwdFlow, 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.
winfriedhas left
dwdZash, 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.
Flowhas joined
Zashdwd: But NIH!! And huge XML spec
fippodwd: but isn't xml out of fashion?
Lanceyeah, i'd prefer to keep things simpler for clients to implement / users to use. use iodef/stix for inter-server reporting
ZashYou could write an informational spec that describes the absolute minimum of IODEF you would need as a client
SouLhas left
SouLhas joined
tim@boese-ban.dehas joined
tim@boese-ban.dehas left
hexa-has left
foss81405971has joined
thorstenhas left
thorstenhas joined
foss81405971has joined
intosi has joined
Lancehas joined
Lancehas joined
foss81405971has joined
Martinhas left
Lancehas joined
Lancehas joined
goffihas left
dwdhas left
thorstenhas left
Lancehas joined
Lancehas joined
thorstenhas joined
boothj5has joined
intosi has left
FlowI guess that absolut minimum would be something like xep287 reporting or simply-report-spam.
intosi has joined
Alexhas left
ralphmand/or creating a mapping to it from a custom protocol you define. We did something similar with things like geoloc
Jake1984has joined
stpeterI'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.
ralphmnods
Flowdon't forget about the use case where you just want to report a malicious jid
Lancehas joined
LanceGiven 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.
Flowsuch report should come optionally with a stanza in question (or a link to it's id) and a more detailed reason (spam, harrasment, fraud, ...)
FlowLance: exactly my thought
sezuanhas left
stpetersure, I don't disagree
stpeterFlow: don't we know that a JID is malicious based on a particular stanza? (message, presence invite, etc.)
Flowstpeter: not sure, if there is always a stanza to report at hand
Zashhas joined
Flowbut anyway the information that matters most is the JID, all other information (stanza, exact reason, ...) should be optional IMHO
stpeterSure.
dwdhas left
artyhas joined
Ashley Wardhas joined
sezuanhas joined
SamWhitedhas left
danielhas left
intosi has joined
stpeterFlow: yes, I think you're right - and let's keep the reporting as simple as possible
moparisthebesthas left
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.
SamWhitedhas left
danielhas joined
Flowhas left
danielhas joined
moparisthebesthas joined
tim@boese-ban.dehas joined
tim@boese-ban.dehas joined
danielhas joined
intosi has joined
boothj5has left
LanceI'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@
danielhas left
LanceOne 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)
LanceSo 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?)
foss81405971has joined
stpeterhuh interesting
Lancefederation makes things harder, of course :/, but there are other things to automatically filter on, such as age of accounts
Lancemost of that information would only be available inside each service, though
fippoage of account... we tried that in psyc ~2003 lance :-)
Lancefippo: as is tradition
fippoit is still somewhat useful if the remote server is not evil. e.g. the case of a "public server" that gets abused
danielhas joined
stpeterI don't think that most XMPP servers have kept track of that
intosi has joined
stpeteralthough this account I'm using goes back to 1999 :P
danielhas left
danielhas joined
narcode:D
narcodenice
stpeterI'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
SamWhitedhas left
narcodelook 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”
Lancemy server always returns a score of 100 for me, naturally :p
moparisthebesthas joined
tim@boese-ban.dehas left
Lancebut 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
Lanceas in, new protocols won't solve things. operational work is needed
fipposo 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!
fipporeputation systems can make sense if we assume that it is evil clients abusing an open server
stpeterfippo: I think we have a mix of evil servers (less common) and evil clients abusing open servers
stpetere.g., I'm pretty sure that buycc.me was/is an evil server
boothj5has joined
boothj5has left
foss81405971has joined
stpeterhas left
boothj5has joined
goffihas left
goffihas left
fipporight. 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
intosi has joined
stpeterhas joined
waqashas left
foss81405971has joined
waqashas joined
Ashley Wardhas left
stpeteryes
stpeterby public server you mean a server that allows essentially anyone to register an account?
XSF Discussion - 2016-01-13