#social 2020-02-08
2020-02-08 UTC
nedjo, jacky, sl007 and BitBot joined the channel
# 
nightpool[m] cwebber2 (IRC): ah, sorry, didn't see your response and forgot to drop a link here. let me make a new post right now, but so far no-one has responded to the agenda thread: https://socialhub.activitypub.rocks/t/2-8-socialcg-telecon/507
# nightpool[m] and, well, you know. if the meeting doesn't happen, more time for me to work on my own stuff :D
pukkamustard and sl007 joined the channel
# nightpool[m] *~*/~/*~*/~/ ~*/~
# melody are we expecting participants?
lanodan joined the channel
# nightpool[m] At least a couple.
nedjo, Zakim and RRSAgent joined the channel
# 
RRSAgent logging to https://www.w3.org/2020/02/08-social-irc
# nightpool Zakim, this is mumble on dustycloud.org / port 64738 / password “goblincamp”
# nightpool RRSAgent, make logs public
# nightpool Meeting: Social CG Telecon
# nightpool cwebber2, are you chairing or should I?
emacsen joined the channel
# nightpool sounds good
# nightpool Chair: nightpool
# nightpool Agenda: https://socialhub.activitypub.rocks/t/2-8-socialcg-telecon/507
# nightpool ScribeNick: cwebber2
# nightpool[m] Cool, let me jump on mumble and we'll get started
# lanodan Hi, I'm lanodan, pleroma full-time developer and admin of my own instance at queer.hacktivis.me (got no mic)
# lanodan Yeah
tsyesika joined the channel
# nightpool[m] pokes emacsen (IRC)
# emacsen sorry, my mumble is acting up
# emacsen I had to poke it
# sl007 Hi I am Sebastian and doing redaktor.me (inherently-social website-building software capable of serving website-building needs of institutions, journalist organisations, citizen journalism and photo/film documentary.
# sl007 ;)
# emacsen present+
# melody present+
# nightpool[m] present+
# lanodan present+
# sl007 present+
# nedjo present+
# nightpool[m] ScribeNick: nightpool
# nightpool[m] cwebber: Alright, i'll give an update on OCAPub and pass it over to Serge to do datashards.
# nightpool[m] cwebber2 (IRC): so, the status of OCAP stuff is that there was an OCAPub spec a while ago, and that stuff is near completion
# 
cwebber2 cwebber2: ocap social network discussion https://groups.google.com/forum/#!topic/cap-talk/icey8aO5ABo
# cwebber2 cwebber2: confused deputy testing https://groups.google.com/d/msg/cap-talk/5Q8BM3aW0Gw/lHzTgXaQAgAJ
# nightpool[m] cwebber2 (IRC): i've been trying to get security review, especially from the broader ocap community, through the cap-talk mailing list
# sl007 q+
# nightpool[m] cwebber2: There's some good discussion on non-ocappub specific social networking capability secuity there on the first link and then also some specific security review in the second link
setthemfree joined the channel
# nightpool[m] ScribeNick: cwebber2
# lanodan LitePub is more like a profile of ActivityPub not really some restriction, our IR is more liberal
# lanodan And yeah I'm involved in LitePub
# lanodan Yeah
# nightpool[m] ack cwebber2 (IRC)
# nightpool[m] ack cwebber
# lanodan btw kaniini left the pleroma project so might need some kind of people taking over?
# lanodan And I can volunteer on this
# nedjo More info on datashards: https://datashards.net
# nightpool[m] ack cwebber
# nightpool[m] cwebber: One thing to add is that mutable datashards might help with account migration, where if your node goes down, you can repoint it to a new node
# sl007 q+
# nightpool[m] ack sl
# nightpool[m] s/world/url
# sl007 q+
# nightpool[m] s/a meetup place/a meetup.com replacement/
# nightpool[m] s/???/gath.io/
# lanodan Quite weird to pick markdown instead of like something a bit like swagger so it can be more or less parseable (could be useful to hint that like Honk doesn't support Like to an user).
# nedjo q+
# sl007 q+
# sl007 q-
# nightpool[m] ack sl
# nightpool[m] ack cwebber
# nightpool[m] cwebber: I think it's good to identify this as the abstract problem that it is, which is interface descriptions
# nightpool[m] cwebber: that is, the interface between clients and servers and between servers themselves
# nedjo q-
# nightpool[m] cwebber: The thing I find interesting about FEDERATION.md is that it is human readable, and it's not interested in being machine readable.
# melody q+
# nightpool[m] cwebber: designing a machine readable form of this could take a very long time, and there are a couple of projects like Hydra that have attempted to do so
# nightpool[m] cwebber: we thought about a similar JSON document when we were writing activitypub, defining the types you'd allow
# sl007 cwebber2 FYI, found the machine readable thing https://github.com/jhass/nodeinfo
# nightpool[m] cwebber: this was something discussed very earlier in the SocialCG's existence, right after the social web working group ended.
# nightpool[m] cwebber: there were two proposals, one for a .well-known kind of thing, and one where an actor's profile pointed at this kind of information
# melody q+
# sl007 q+
# nightpool[m] cwebber: the broader context of this was discussions around server-level information, and how much information should be provided on the software and where that informatino should live
# nightpool[m] s/informatino/information/
# cwebber2 melody: I just wanted to say I think one of the things I like about FEDERATION.md is that in a lot of ways just knowing the types isn't enough, there's a certain point you need the human intervention to understand the semantics of what the types are and how they're used... especially in some of the ways people stretch the meaning of types of what they expect of very different things. I think it makes sense to have something a human can
# lanodan Yeah, this is why I think it should be more like a description on how each activity is understood (like how Mastodon used to except 500 characters for as:Note). So if it's a JSON it's more like a list of description per activity name.
# nightpool[m] ack melody
# nightpool[m] ack sl
# nightpool[m] ack cwebber
# nightpool cwebber2: first off, I'm very glad to hear how widely supported nodeinfo is, and secondly I think both of these approaches are valuable
# nightpool ... I think it would be very sad if FEDERATION.md was the only way of approaching this, and I think nodeinfo is valuable as a very broad "survey" of what is currently implemented on the fediverse
# nightpool ... but notably, and this is why we originally suggested a simple JSON list of types, is that getting this kind of rich granularity is very, very hard.
# nightpool ... it's hard to build this kind of contract language that can describe these features well
# melody q+
# nightpool ... and in the meanwhile, I'm very excited about FEDERATION.md, even if it isn't machine readable, because it gives insight into what kind of things implementors are doing and care about
# nightpool ack melody
# nightpool q+
# cwebber2 melody: I agree, and I think it's good that we also have something that's machine readable, especially for simple negotiation between C2S & S2S. I also love that FEDERATION.md does not try to be that thing, because there's so much unspecified side effect behavior and etc, and I'm not sure how to represent in a machine-parasable way, and it's great to explain to a human what you're doing with all that. I think both approaches are
# cwebber2 nightpool: yes I think the things people have said, there's value to two approaches, one that's machine readable coarse thing, and then we can iteratively make it more fine grained where that granularity is useful, and a very fine-grained but human readable FEDERATION.md and we can aggregate some of that information
# cwebber2 nightpool: one issue I have with nodeinfo is you can't do two on the same server... one issue with mastodon is our dependency on fediverse has made it hard to deploy on the same domain (eg deploying alongside nextcloud). I think going forward, especially with the way AP was designed, would love to see things happen on the actor level. That can be then collected in the same way we collect nodeinfo. I think that makes more sense
# nightpool ack nightpool
# nightpool ack cwebber2
# nightpool ack cwebber
# sl007 full ack
# cwebber2 nedjo: sure! so I'm relatively new to AP, I've gone through a process similar to most of you... I looked around and started to collect what I needed to get going, found some notes, and saw conversations about that. I saw the drafts about activitypub.rocks site, started working on that dividing it into three parts: general intro to AP, one generally short guide for users who want to get using, and the third is a guide for AP
# nightpool[m] ack cwebber
# nedjo q+
# nightpool[m] ack nedjo
# emacsen +1
# lanodan +1
# nedjo +1
# lanodan Bye o/
# nightpool[m] Zakim, bye
Zakim left the channel
# nightpool[m] RRSAgent, make logs public
# nightpool[m] RRSAgent, create minutes
# RRSAgent I have made the request to generate https://www.w3.org/2020/02/08-social-minutes.html nightpool[m]
# nightpool[m] RRSAgent, bye
RRSAgent left the channel
# melody cwebber2: i've been reading the threads you linked & while i'm not sure i can see the vulnerability described, it occurs to me to ask a separate question -- how critical is the ability to publish edge names for a petnames system to work? like in your example (publishing Alice Smith vs. Little Brat) -- one is de-anonymizing and the other is potentially abusive, it's not hard to imagine attacks based on publishing abusive edge names or doxxing via them
# lanodan Wouldn't the abuse part be avoided if the petname be only local?
# lanodan (And well we can already do @<slur> in mentions)
# melody yes, but edge names become part of the automated system - they are displayed in the interfaces of other people and used for attestation, so it becomes integrated into the system
# nightpool[m] the de-anonymizing concern is I think less of an issue, because de-anoynmization doesn't get the same "benefit" from being integrated into the system that abuse does
# melody there's also issues of updating self-ascribed names, which in a petname system is a vulnerability but can be necessary when the old name is no longer accurate -- i think there's ways to maybe solve this (like publishing an update request that other users can accept) but this is a downgrade from say, twitter, where your self-ascribed name will just populate
# lanodan And maybe some kind of moderation on it?
# melody i think we'll also see like, channers use mass publication of edge names to propogate abusive information about a target
# lanodan ^
# lanodan I specially see this one because on the fediverse an abuser can create basically as much actors as they want.
# melody hmmm
# lanodan So it needs to be resistant to this kind of abuse
# melody i might have been thinking of it more like attestations on keyservers than i should have been, need to think through the implications of follow networks
# nightpool[m] in some senses this is a very similar problem to "allowed replies"
# lanodan I guess if it's followers-only that could be okay
# nightpool[m] i.e. "how do you block people from replying to you and then passing that information around to their followers"
# melody yeah, i might have been thinking of publishing these as being more global than local scope
# melody assuming people don't circumvent the system by creating like, a global followable actor that aggregates edge names so that people can be aware of more nodes or see more content
# melody yeah i mean people will 100% do that thing i just said
# lanodan Only thing is that we shouldn't make it too easy, if it's only kiwifarms that's fine but if it can be done by all edgy kids… meh
# melody maybe not technically, i think pragmatically there's a risk of one becoming a de-facto standard and then being used abusively but i guess welcome to the internet
# cwebber2 https://github.com/cwebber/rebooting-the-web-of-trust-spring2018/blob/petnames/draft-documents/petnames.md more on petnames for those new to this conversation
# melody yeah, i worry about like, a popular platform privileging a naming hub because they don't understand the risks, or understand and want to take advantage of them, like say, if gab were to add its million users or w/e to a popular naming hub or if some future social networking tool that most instances ran built one in to make things more user-friendly
# melody its really easy to compromise a system via network effects with good intentions and easier with bad ones
# melody nods
# melody 100% for sure, I'm just accustomed to thinking through like "Okay, we've designed this system, how are people going to screw up implementing it or break it to work around its flaws"
# melody yeah i got that it was a confused deputy from the hints but the second link is too steep in jargon for me to identify which part introduces the confused deputy
# melody rights amplification meaning like, giving somebody a proxy capability that they can't inspect so that another person can act through them?
# melody in which case a middleman could be a confused deputy if they use the wrong uninspectable box to let somebody act through them?
# melody or am i off base
# melody i can also just wait for you to sort it out and read about ocappub later, this doesn't have immediate implications for me beyond my curiosity in this moment
# melody i don't wanna ask you to do a bunch of work explaining it or trying to figure out how
# cwebber2 melody: the example that lead me to understand rights amplification comes from this paper https://www.uni-weimar.de/fileadmin/user/fak/medien/professuren/Virtual_Reality/documents/publications/capsec_vr2008_preprint.pdf
# melody i'll poke at that if i get a chance, thanks
# melody will look at it
# melody yep
# melody yes
# melody do the teachers have sealers or unsealers or both? just want to be 100% clear that wasn't a typo up there
# melody you said "lets give the sealers to each teacher"
# melody so i wanted to be clear
# melody i thought you meant unsealers and it's good i was able to catch that, means i'm probably following :P
# melody yeah, because the mute method was a sealed capability that required an unsealer that only the teacher held
# melody i assumed the sealer would just wrap a proxy reply-to for that reason
# melody is it better the other way around?
# melody anyway i'm still following so far
# cwebber2 for those unfamiliar with confused deputies, this is a good intro: https://www.youtube.com/watch?v=Yfsmc0b8o78&vl=en
# cwebber2 capabilites don't have confused deputies "on their own", because there's no separation of designation and authority. Once you have the designation of something, that gives you the authority to act. confused deputies rely on tricking something that has more power than you do into giving you privilege you shouldn't have
# cwebber2 my concern in raising that thread was, "well, once we have rights amplification or identity whereby we associate things, now we have similar asymmetry... we can do a lot of code without rights amplification and identity, but social networks definitely at least involve identity, and things like the reply-to control are desirable, so did we accidentally introduce attacks?"
# cwebber2 so that was the setup for seeing if people spotted things in https://groups.google.com/forum/#!topic/cap-talk/icey8aO5ABo
# cwebber2 and then the analysis from there happens in https://groups.google.com/d/msg/cap-talk/5Q8BM3aW0Gw/lHzTgXaQAgAJ
# melody identity because that means you have shared designations for a user and necessarily different authority
# melody and rights amplification because it's specifically for having shared designations with different authority
# melody they're the same thing in a lot of social tech systems, where the capability of reading data is an authority
# melody like the whole thing is about controlling access to information
# melody so the question becomes, does a capability system with identity and rights amplification reduce to an ACL because it reintroduces the same asymmetries, the way that adding mutability to immutable systems reintroduces all the conflict possibilities immutability was meant to prevent
nedjo joined the channel
# melody & there can be reasons it can still be worth going the roundabout way and introducing mutability on top of an immutable system, likewise i imagine there's reasons to still use ocaps here
# melody i think the piece i'm missing is the mechanism by which searching for an unsealer in a bucket introduces this
# melody like i think i pre-assumed only one unsealer would work for any given thing anyway
# melody so i got really unclear how having to search for it introduces this problem
# melody ahhhhh
# melody by the time we were dealing with so many proxy objects and everything i just assumed we were well past "sign everything with the same key"
# melody can i take a shot at a guess before you explain?
# melody we've got the blogpost
# melody alice gives an unsealer to bob
# melody nah wait i lost it
# melody go ahead and explain haha
^Connor_ joined the channel
# melody meanie
# melody yep thats bad
sl007 joined the channel
# melody that sounds tough, because it feels like you essentially will need to double-sign everything and rely on systems to be implemented correctly to check this, since you'll need to sign the context so that it can't be forged when mallet stuffs the essentially-public-key representing the sealed cap
# melody into the wrong thing
# melody best of luck
# melody I'm trying to think of a way to re-analogize the attack now that i think I understand it
# melody but especially a version of this that requires like, cloning the sealed capability and then hiding it does not lend itself to meatspace examples, it's a lot harder to trick somebody into sending a message to the wrong person when you can't create a wormhole labeled "Mallet's Mailbox" that sends things to Alice's Mailbox instead
# melody lol
# melody i was typing up a whole thing but the implications get pretty rough performance-wise and usability-wise the more i try to dig myself out of this hole, looking forward to seeing what you've come up with there
# nightpool[m] i haven't been following too much of this ocap situation, but I had a different conceptual approach to the replies problem bouncing around in my head that I wanted to get someone's thought on
# nightpool[m] it feels like it overlaps with ocap but i'm not sure how because i only have the most cursory understanding of ocap technology
# nightpool[m] so the fundamental problem that replies seems to get at is the idea of "who is allowed to link to my object"
# nightpool[m] and so the proposed solution I had bouncing around in my head is just a version of an "authorized" link, i.e. some method for third party verification of a specific URL and the context its used in.
# melody i would maybe reframe it as "how should software behave when somebody links to my object" - linking to the object is not preventable, but software can choose not to amplify people's attempts to do so without my permission, or attach their messages to my feed and a space i control
# nightpool[m] so like in the simplest case this would be a query param that says something like `https://nightpool.club/post/1?link_source=https://dustycloud.org/post/2`
# nightpool[m] and if the `link_source` is allowed, the URL resolves, and if it isn't, it returns a 401 or something.
# melody the problem with that is that somebody could just forge the link source, you'd need cryptography or similar to actually identify the source of the request
# nightpool[m] i don't think cryptography is helpful?
# nightpool[m] you just need to make sure the person resolving the link puts the link source in
# nightpool[m] instead of the person authoring the content.
# melody the person resolving the link could just put a link source in that they know you'll accept
# melody whether they actually got it there or not
# melody and people will pass around accepted sources as full urls
# nightpool[m] right, but that's not useful because the person resolving the link is the person who's interesting in whether the link is authorized or not
# melody are they?
# nightpool[m] that's like saying "you can just return `true` from your verify_signature function"
# nightpool[m] it's true, but it's not useful.
# nightpool[m] this doesn't prevent people from replying to your content, but it allows a third party to determine whether or not the reply was allowed.
# melody I think I would want a better option than this
# nightpool[m] better in what sense
# nightpool[m] * better in what sense?
# melody I think it should be my responsibility to redistribute replies to my posts, so 3rd party software should not need to be independently verifying that I allowed them
# nightpool[m] i guess i'm not following
# nightpool[m] if mastodon needs to make the decision "is this post a reply to this other post?"
# nightpool[m] it needs to have some logic for determining that
# nightpool[m] that could be "was this sent to me by the actor that the post is replying to"
# nightpool[m] or it could be something based on cryptography or resolving the post with a `link_source` parameter
# nightpool[m] but I think those are both types of independent verification?
# nightpool[m] when I say "independent" I just mean "someone who is not the replier or the person being replied to"
# melody I dunno, the link source thing feels wrong to me, it seems like well-behaving software should stop me from trying to reply at all, and ill-behaving or malicious software shouldn't be able to forge a reply that's convincing enough to require another request for verification, but maybe there isn't an obvious cryptographic solution here and I'm missing something
# melody it's been a while since i've thought deeply about this
# nightpool[m] well i guess my thought is that the cryptographic solution can be pretty easily put on top of this one, as an enhancement
# nightpool[m] in the same way, e.g., linked data signatures are an enhancement on "just looking up the post"
# nightpool[m] but it gets hard to, say, delete a reply after it was made if you sign them.
# melody i think i'm concerned about all the ways that trying to find a way to allow list domains or actors could be complicated or bypassed -- like what happens if there's an implementation that allows setting up instances on wildcard subdomains/what does that do to the logic for checking whether the activity in a link source should be allowed, or changing URI schemes
# melody if returning a valid answer to a link source requests requires another three requests to validate the link source is an activity owned by an allowed actor
# melody this suddenly gets very weird
# nightpool[m] hmm.
# nightpool[m] that's only the case if you haven't seen the activity/actor already though?
# melody changing uri schemes are a concern for populating historical replies otherwise it'd be easy enough to just check against replies you've already published
# melody but you also have to resolve the activity to find out of if it has moved
# melody ideally activities are permanent identifiers but we know they aren't
# nightpool[m] sure but again that's just the slow path of "i haven't seen the activity before"
# nightpool[m] which requires 1 lookup ever per domain change or whatever
# melody for that activity -- a new instance backfilling a post history with its replies could be requesting whether hundreds or thousands of activities from that domain are authorized
# melody and each one will detect as new
# melody + then multiply for every user it's doing that for on your instance
# melody there's always throttling, etc. but it seems like there must be a better option
# melody i'm open to there not being a better option, using URIs for this just feels fragile & complicated
# nightpool[m] activity URI updates are already a problem with 1) maintaining historical content and 2) mutable identifiers though
# melody fair enough
# nightpool[m] sorry my computer crashed before I could type up the rest of my reply but just generally i'm wary of trying to solve unrelated problems when working on something specific like disabling replies.
# cwebber2 This would be well described as "incompossibilities", similar to this talk about tradeoffs in Tor protocol design https://media.libreplanet.org/u/libreplanet/m/incompossibilities-ubiquitous-engineering-tradeoffs/
connormagnusson_ joined the channel
# melody there are definitely mutually incompatible goals, i think i tend to try to make the local more friendly to changing history and less friendly to tracking it, but i see the merits, if you can't prevent tracking it, to making it very visible so that everyone is at least aware that they should think about that when they post -- but my preference is still to discourage + mitigate as much as possible, to narrow windows of opportunity for harm
# melody like, i can imagine a system where leaving an audit trail on your posts is optional, but it's visible whether or not you have that feature enabled, and that could be used to encourage public figures & institutions to do it, without requiring ordinary people to be held to that standard
# melody there's room for less technologically bound trust signals to encourage better outcomes here
# melody i meant social signals there, not technological ones
# melody re: signatures, i'm definitely concerned about the options there, there are certain parts of decentralized systems that feel like bad tradeoffs the whole way down, and that's an area where it feels like there's no winning
# melody "trivial impersonation/forgery or no privacy" is a painful tradeoff
# melody idk if there's options w/r/t ephemeral keys and republishing like OTR that can still work in a less synchronous system to reintroduce deniability
# melody but if i'm honest, people are a lot easier to fool than computers are even with extremely obviously faked things with zero proof provided so maybe i should be less concerned about technological deniability since deniability doesn't even work when the claims are baseless
# melody it's a lot, regardless
# melody as a general rule though, i prefer the problems caused by mutability to the problems caused by immutability, it's reasonable to have a different preference, especially in different contexts, but i definitely lean distrustful of immutable systems, the stakes are just too high
# melody the ability to delete things and have them be really gone is important