#social 2017-10-11
2017-10-11 UTC
cdchapman joined the channel
# 
saranix Re: anti-abuse tooling: http://dedis.cs.yale.edu/dissent/
cdchapman, ajordan, dlehn, dlongley, adam, xmpp-social, jankusanagi_, timbl, bigbluehat, mattl, melody, cwebber and jungkees joined the channel
# cwebber hey!
# cwebber meeting in < 10 minutes :)
# xmpp-social [ajordan] Lol I'm glad you said that
# xmpp-social [ajordan] I thought it was in an hour :P
# cwebber :)
# cwebber melody rhiaro Gargron aaronpk jaywink wilkie tsyesika ben_thatmustbeme sandro nightpool puckipedia: ^^^^ see you in the meeting? :)
# cwebber (and anyone else! I just selected the usual suspects off-the-top-of-my-head)
# cwebber oh and nightpool
# cwebber I'm sure I missed people
# cwebber that's still helpful!
# puckipedia wait, is it now?
# cwebber isn't it??
# cwebber it looks like it :)
# puckipedia yeah, have to kinda get this to work again
# cwebber sandro: the audio works this week if you want to call in ;)
# cwebber trackbot, start meeting
RRSAgent joined the channel
# 
RRSAgent logging to http://www.w3.org/2017/10/11-social-irc
Zakim joined the channel
# cwebber present+
# melody present+
# puckipedia present+
# puckipedia scribenick: puckipedia
# puckipedia cwebber: first item on the agenda, social working group updates
# puckipedia cwebber: the main thing is that I need to get the test suite out in two weeks, then I'll gather implementation reports
# puckipedia cwebber: oh, and another big point is that websup is at PR
# puckipedia aaronpk: which is the last stage before recommendation. So we are looking for more member companies to weigh in
# puckipedia cwebber: a few things on the agenda, next one is activitypub's mediaUpload endpoint. maybe we should shuffle that to the end
rowan joined the channel
# puckipedia cwebber: let's talk about anti-abuse tooling
# puckipedia cwebber: generally the topic is letting users be protected against abuse, like a gamergate pile-on. we do have some things in the existing protocols and applications. Mastodon has a few cross-server filtering tools, we have a block tool in AP, don't know if there's something in webmention, aaronpk, is there something for filtering?
# puckipedia aaronpk: it's out of scope. it's up to the receiver to decide what to do with it. webmention just gets you to "yes, this thing exists", not about who it is or whether it is usefule
# puckipedia cwebber: so, melody, I'm volunteering you, melody has been doing some work in the anti-abuse tooling space
# puckipedia melody: the work i've done so far isn't directly related to this
# puckipedia cwebber: I know it's a bit on the stop, but I actively encouraged her to be on the call, because her work is invested in these spaces
# puckipedia melody: I have a continued investment in this area, I'm still trying to get my bearings around what level of tooling, and like, which protocols are relevant to the ideas I have for anti-abuse in the social web
# puckipedia melody: I'm having trouble contextualizing where the stuff I'm doing fits in the big picture
# puckipedia cwebber: it's good to hear your perspective from this space, what would be useful is to kind of list out the possible avenues for anti-abuse tooling. this is something we're not going to resolve on this call
# puckipedia cwebber: I don't think we need to use a queue, let's just get listed out the general avenues that we know
# cwebber - Blocklists
# cwebber - Block "activity"
# cwebber - Word filtering
# puckipedia cwebber: one other route might be word filtering, specifically a blacklist of words you don't want to see, that starts to move down the direction of bayesian spam filtering
# cwebber - Bayesian inference
# puckipedia cwebber: instead of explicitly listing what you don't want, ahve a bayesian filter compile what you want based on what you mark
# cwebber q+
# cwebber ack cwebber
# puckipedia cwebber: this inference might slowly move to more neural-type approaches, unfortunately these involve having a very large corpus, a local bayesian filter doesn't involve a lot of work
# puckipedia cwebber: the risk is that this can falsely flag people
# cwebber - neural networks
# puckipedia cwebber: in AP and webmention, each has *a* public endpoint anyone can send a message to, whether to reply to a post, or to a user there's an endpoint to send to. another option is to instead have a web of trust of people you are allowing in. so a whitelist, and you might look at the list of people you trust and see who *they* trust
# cwebber - web of trust
# puckipedia cwebber: maybe we can say well, our public inbox is only for people we trust, but maybe there's another inbox that is for anyone, which would require a payment mechanism, so if you're not in my trust network, you can send a message but it costs 5 cents
# puckipedia cwebber: this makes spam useless, because it costs people to spam people, and makes dogpiling expensive
# puckipedia cwebber: if, it turns out "oh, this is someone I hadn't marked", you can refund it
# puckipedia cwebber: downside is that it can incorporate more pay-to-play
# cwebber scribenick: cwebber
# cwebber puckipedia: I also have some thoughts for anti-abuse
# cwebber puckipedia: for example in mastodon a block is sent to the corresponding server which of course can be controlled by that person
# cwebber puckipedia: in activitypub it's kept kind of implementation-specified whether it's sent
# cwebber puckipedia: going to come back to this potentially
# cwebber puckipedia: I just thought of a flag activity, for example if you think that person is malicious you send a flag activity, but you send a flag activity not delivered to that actor, for example a flag activity to a malicious user on a non-malicious server
# puckipedia scribenick: puckipedia
# puckipedia cwebber: a way this could be done is, the actor has an endpoints property, which is for server-wide shared endpoints
# puckipedia cwebber: so those are not specific to the user, but to the server. something which was suggested was, well, couldn't we have a server-wide actor, in the endponits, where you could deliver the flag activity
# cwebber scribenick: cwebber
# cwebber puckipedia: I think that would be nice because you could say it's the server admin, so you could send a message to the server admin, so you could send a message to that actor as well
# cwebber puckipedia: maybe that actor could also be a public announcement system. For instance, if thes server sends out announcements it's from that actor
# puckipedia scribenick: puckipedia
# puckipedia cwebber: there is a generalized topic I'd like to discuss, one thing we've talked about except for possibly neural network, can be federated. and maybe even user-run
# puckipedia cwebber: so it's possible a user is in control of their blocklist, and a user can even run, client-side, their own filtering tools. a concern is, sometimes when anti-abuse tooling comes up, will you need a large centralized node?
# puckipedia cwebber: we need to talk about this, there was more of a push a year ago, when there was more faith from people who are concerned with protecting people for social justice reasons, that these neural network types will protect people
# puckipedia cwebber: I've seen a shift that people have become more suspicious. we've seen these networks pick up institutional racist/sexist biases of the system
# puckipedia cwebber: are there reasons why a centralized system can do things a decentralized system can't do?
# cwebber ack ajordan
# melody q+
# puckipedia ajordan: so I will fully admit to not having followed this discussion, but you just mentioned running things client-side. I would like to say that is, in my view, unideal. client-side solutions only work for one client, so you get an inconsistent timeline across client, and you still have to pay the cost of network traffic before you can filter it out
# puckipedia ajordan: I really would like not to push this to the client
# cwebber ack melody
# puckipedia melody: I agree with ajordan, if you have a keyword filter list you want those to be in place no matter which client. it ends up being pretty important that those things work. coming from a tumblr background, there's a few good browser extensions that have keyword filtering with differing sensitivity, but it falls flat if you use it on mobile that you wouldn't have seen on the desktop.
# cwebber q+
# puckipedia melody: I don't know if you need deep centralization, but one thing that hasn't been discussed is allowing some method of assessing risk of a message, you could use some kind of algorithm like a spam filter, or base it on keywords, or based on someone that isn't on your web of trust. carrying this info with the message would give clients the ability to surface messages with different kinds of risk with a customized amount of risk at any given moment when
# puckipedia you're interacting with your timeline/inbox/whatever
# puckipedia cwebber: we got consensus that we don't want disjointness between clients. we want ability, on the client-server level, that they all share the same data and don't get out of sync. the other point seems to be wrapping things in an envelope, so you get the message, and the server wraps it in an envelope with a level of risk
# cwebber ack ajordan
# puckipedia ajordan: I am not convinced this is not dangerously close to full centralization, but I think it would be interesting to, instead of standardising these anti-abuse things directly, if we standardise a way for a client to say to a server "please send this post to this other service for me" and the service is allowed to, either add stuff to a post (risk assessment), or, y'know, reject it entirely
# puckipedia ajordan: if we did that, servers wouldn't have to worry about this as much, and you could iterate on anti-abuse protocols independently. and servers don't have to reimplement it, and you'd get pretty wide-spread good tooling for free
# cwebber ack cwebber
# puckipedia cwebber: I agree that this simplifies things for implementors of AP servers. If we ask someone "we'd love to see more AP implementations", you can implement the server isntead of also adding the other complex tooling. this is a strong advantage, and we've got aggregration of information
# puckipedia cwebber: but it effectively irradicates privacy from the system, and that might be a large point of concern, this could be a target for state actors, malicious actors who would like to see private posts, or even do the reverse, target it to their own needs
# puckipedia cwebber: but it also has upsides in simplifying things
# puckipedia cwebber: activityspam was a server that did spam filtering for you, at the costs of what we just discussed
# cwebber q:
# cwebber q?
# cwebber ack ajordan
# puckipedia ajordan: you say it eradicates privacy, can you clarify?
# puckipedia cwebber: the concern is that, say, I send a message to you directly. then we have some anti-spam central server, and you and I both run private nodes. We have the impression that I'm sending something directly and thus it's a private channel. in fact, this other server, the anti-spam server, would see the communication. you would have the level of surveillance Google has over Gmail servers, which is equivalnt to the privacy if you use the anti-spam service
# puckipedia cwebber: it opens the possibility for centralized surveillance
# puckipedia ajordan: even if we run private nodes, I could still send the message to others
# melody q+
# puckipedia cwebber: by encouraging many nodes to use a centralized service we open the door to, e.g. activityspam is running out of money, "oh hey, we could just sell our data to an advertising company"
# cwebber ack melody
# puckipedia cwebber: but we're encouraging a dangerous centralized service
# puckipedia melody: just thinking about the other side, how breaking it off into a separate service might help iterating, if there isn't client side support for having to deal with the messages. if this is beign iterated on separately then only clients that know about the other service will know what to do with the information
# puckipedia cwebber: either we say accept/reject, or we need to standardize the envelope
# cwebber q?
# puckipedia cwebber: anything else somebody would want to talk about?
# cwebber q+
# puckipedia melody: it's sort-of related to something else I know has been discussed, which is the sensitive flag, which I think was mostly discussed in the context of content warnings. I'm wondering if there's a possibility for using that for anti-abuse purposes as well, having a standardized way of "hide this by default" sounds like it could be a useful tool
# cwebber ack cwebber
# puckipedia melody: but it might require some additional information to be useful for that case, like a [??] message or some other information to go with it
# puckipedia cwebber: the sensitive flag, we adopted it because it's what Mastodon uses, there's both a sensitive flag and a content warning system, the CW system allows you to add a human-readable description
# puckipedia cwebber: the sensitive flag is more a generalized "not safe for work/whatever" type flag, and but it doesn't give context what that means
# puckipedia cwebber: it's like actor/server-specific to make that decision
# puckipedia cwebber: another route that isn't implemented in Mastodon or the spec was having tags that are themselves marked as sensitive. this would allow users to set more careful filtering, maybe a user is fine seeing steven universe spoilers, but they don't want to see pornography or graphic violence. maybe another person is fine with pornography but not okay with those other two
# puckipedia cwebber: maybe someone doesn't want to see politics by default
# puckipedia cwebber: this would be more closely related to content warning as a user-typed field and tags combined. the upside is that you're more precise, the downside is that people might not actually do it
# cwebber q?
# puckipedia melody: that's a lot of what I had in mind, like, users on tumblr are fairly happy with managing a list of things they don't want to see, it seems the ability to state the message being collapsed by default with a reason, then use for any of these approaches
# cwebber q+ to talk about danger of "sensitive" boolean
# puckipedia melody: you could use it by having that reason be typed in by the creator, and then trip the flag, or you could have it be on the recipient end like a user of tumblr and have the server decide to add the reason and the flag
# puckipedia melody: so that flag plus reason is common to both of those approaches
# cwebber ack cwebber
# puckipedia cwebber: the reason the sensitive flag is an extension in AP instead of in the AS spec is there's a lot of concerns of a per-post boolean with a flag, we've seen problems. on youtube, marking stuff that was meant for LGBT, not even sexually explicit, being marked as NSFW
# puckipedia cwebber: we've seen this with reporting on war crimes etc etc that might not be graphically explicit, but gets marked
# puckipedia cwebber: so if we go for boolean, we should carry contextual information with it
# puckipedia cwebber: a good next step is to capture what we said on a wiki page, what we think is the future direction for this
# puckipedia cwebber: if there's any volunteers, I'd rather not do this alone
# puckipedia melody: I might be able to help with that in the near future, I'm pretty busy this week
# puckipedia cwebber: melody, would you want to collaborate with this starting next month?
# puckipedia melody: I think that's doable
# cwebber q?
# cwebber PROPOSED: Have this meeting extend to 90 minutes rather than 60
# cwebber +1
# puckipedia +0
# melody +0
# puckipedia cwebber: it doesn't seem there's any strong exuberance to keep going an hour and a half, so we'll push the topics to next week. I feel like the follower migration is a whole meeting's worth of topic, and so is publishing which extensions are used by a server
# puckipedia cwebber: so AP had a mediaUpload endpoint, which allowed you to upload images/video/whatever, there were a few aspects we were unsure, like chunked uploads, if uploading a post should Create it to your outbox immediately
# puckipedia cwebber: or whether or not you should have an object you can attach to other objects
# 
Loqi [cwebber] ```
<eprodrom> RESOLVED: Resolve https://github.com/w3c/activitypub/issues/239 by
removing mediaUpload and specified behavior from ActivityPub spec
proper, move to extension via So...
# puckipedia cwebber: we had an issue in which some proposals happened
# puckipedia cwebber: still, it was not quite resolved, adn we're coming to the end point of activitypub. the mediaUpload endpoint was marked at risk, because it was the least-tested thing. I feel sad we're not getting it in, we will move it to the community group as an extension
# puckipedia cwebber: this is something we need and are going to get in anyways (mediaGoblin needs it and it's my project), but effectively mediaUpload endpoint is SocialCG now
# cwebber q?
# puckipedia cwebber: in that case, we've got 5 minutes left, I feel this was really productive, thank you melody for participating, and thank you all as usual
# cwebber puckipedia++ for scribing indeed!
# cwebber trackbot, end meeting
# RRSAgent I have made the request to generate http://www.w3.org/2017/10/11-social-minutes.html trackbot
# cwebber good luck ajordan :)
# cwebber https://www.w3.org/wiki/SocialCG/2017-10-11/minutes minutes posted
tantek joined the channel
# xmpp-social [ajordan] Hah thx cwebber :-)
KjetilK joined the channel
# Loqi Tantekelik made 1 edit to [[Socialwg/2017-10-10]] https://www.w3.org/wiki/index.php?diff=104680&oldid=104651
timbl joined the channel
cdchapman and dlehn joined the channel