Follow

Takeaways from the

1. SharedInbox is dead (look out for MultiBox and OcapsPub)

2. Strong interest to explore Object Capabilities as a way to secure social introductions, power delegation and transitivity, and to develop effective cooperation tools that prevent abuse in the

3. There should be a dedicated devroom at

@how sharedInbox isn't dead until we either netsplit and let elephantsite do their thing or convince elephantsite to kill sharedInbox
@how the big takeaway from APconf, a meeting for implementation engineers working on security is that elephantsite was a no show. Pleroma? there in full force. until we are willing to talk about the elephant in the room, all of this is just talk :)
@kaniini @how so if i were to write a short impl should I just not add it?
@314 @how I wouldn't implement sharedInbox personally, but my point is, 85% of fediverse users will still be in security hell unless elephantsite starts playing seriously
@kaniini @how oh yeah i've been tuned in all weekend i'm aware of the situation and the "literally no software was less represented than masto at apconf" jokes
@kaniini @how I don't think they will be against it too much, changing sharedInbox to multibox is like 5 lines of code, at least in pleroma
@rin @how still, gargron should have showed up. this is what frustrates me with elephantsite. we are working on fixing the security for the benefit of his users (not just ours), shouldn't he show up to the table?

@kaniini
At some point the fact that @Gargron did not participate in community events will play against Mastodon. It's not a that but a simple fact of life: if you never show up, you never bond to the community, and decisions are made without you. I really hope to meet Eugen at the upcoming FOSDEM.

@rin

@how @Gargron @rin

that doesn't work when you have 85% of the users though. what has worked is careful discussion between Pleroma and Mastodon about coordination of specific features where cross-project collaboration is desired.

mastodon can spin APconf as basically being "cwebber and half the pleroma security team got together and threw a kegger" and the story will stick with the users :)

@kaniini
In this part of the universe, decentralisation is bound to prevail
@Gargron @rin

@how @Gargron @rin

decentralization means nothing when you control a decisive majority of the nodes.

when I say Mastodon is the MSIE of the fediverse, I mean that there is really one implementation that matters: Mastodon, and thus only one person who matters: Gargron.

can we make progress? yes. but just because we had a meeting to talk about our current security posture and how to fix it doesn't mean it's time to celebrate. until we have sold big G it means nothing.

@kaniini @Gargron @rin

s/that/threat/
"It's not a threat"

Blame autocorrection.

@kaniini @how I'm not actually afraid of a netsplit. If we make more awesome things than Elephant has, people will point and ask "why can't we have that?"


We should focus on what will being the people who aren't on Mastodon, not be artificially limited because of Mastodon
@feld @how i didn't say i was afraid of a netsplit, i was saying that this is yet another tough decision to be made.
@kaniini @how yep, I'm just voicing my support for doing the right thing regardless of consequences to the network as it currently exists. You'll get no pushback from my end
@kaniini
I welcome it. Its for the good of mastodon users too because it will force them to do something about it. Or the admins will have to seriously consider migration
@feld @how
@how concerning "MultiBox" and "OcapsPub" I would like to see examples on how it is supposed to work. Friendica is always open for improvements, as long as they are documented, implemented elsewhere and don't break compatibility with systems that don't adopt them.
@heluecht @how but that's the thing, to fix the security there does have to be a transition. anything that is backwards compatible ultimately is not secure because it can be downgraded to the old protocol.
@kaniini @heluecht @how I kind of feel like this was the root of why Mike Macgirvin gave up on supporting AP in his projects.
@sean @heluecht @how

i mean, this is the point. the whole point for organizing that conference was to say, okay -- shit's fucked, we have to make some tough decisions to unfuck it.

that means we must not retain backwards compatibility with the current protocol for the next decade.

we have to actually fix these things and move the network forward. if we don't, it's for nothing.
@sean @heluecht @how

and that is what annoys me about @heluecht's response. that response is even worse than the Mastodon response to this thing -- when asked point blank in Discord, Gargron said he was open to implementing this stuff, and he understood that this meant that this meant that eventually older Mastodons might not be able to talk to new Mastodons.

this isn't "lets make things more efficient", if there is a downgrade possibility anywhere in the system, the whole thing falls apart.
@kaniini @sean @how I see it from a users' perspective. Users won't understand why they cannot talk anymore with contacts they had been able to talk to before. You cannot make a hard cut without annoying the persons who really are the important part: The users.

And since @Aerdan spoke about SSL downgrade attacks: The old SSL protocols hadn't been replaced just in a blink of an eye. There had been grace periods. And to avoid downgrade attacks you easily can implement something comparable to HSTS.
@heluecht @how @sean @Aerdan that's not what you were saying though. you imply that you want permanent backwards compatibility. we simply can't do that and fix these problems. at some point broken antipatterns have to be removed.
@kaniini @Aerdan @sean @how well, I tend to listen to arguments and to constantly reconsider my own opinion. But the main point stays the same: I won't make a hard cut when this would exclude a significant amount of contacts.
@heluecht @Aerdan @how @sean

nobody asks for a hard cut, but there has to be a soft cut to move forward. i propose a transitional period of a year.
@deadsuperhero @Michael Vogel @:bunny: @hellekin

Mike and I talk all the time and we're sharing ActivityPub fixes. You may be surprised to learn that Zap has a full ActivityPub stack, except it is turned off. We made a deal that if/when I can federate permissions, privacy, access, and nomadic identity into Osada, he'll support AP. He's doubtful that it can be done. Seeing that AP is two years old and we're no closer to supporting any of these, my confidence in pulling this off is precarious but I'm willing to give it a whirl.

It's worth considering that he's had all these abilities for the better part of a decade and sees AP as a giant step backward. His biggest issue incidentally is spam. There is no obvious way to stop it in AP except setting rate limits or blocking it after it happens. This is the first thing I'll tackle as soon as there is a spec to work from.
@indio @kaniini @sean @how well, I like to see things from the user's perspective. If you make things too complex then you won't attract users. Most users prefer easy to use systems without the need to dig through a dozen different setting pages to be able to finally post stuff. This is a problem that both Hubzilla (and less, but still existing) Friendica do share. Diaspora and Mastodon/Pleroma are more limited, thus easier to understand and use.

I totally understand and support any improvement that does make the content transmission more secure and that prohibits identity theft and so on. But I don't really see the sense of very complex permission and access models. I think that either you do post public - then everyone can read and comment. Or you do it non public - then only a limited amount of people can interact. This is easily understandable for the majority of users.
@Michael Vogel @:bunny: @deadsuperhero @hellekin @Indio

If you are convinced that Mike can only create mind-numbingly complex applications you might be in for a surprise. In any case ease of use is no excuse to permit spam or instantly lose your online identity because the site owner didn't like something you posted. Mike and I disagree on a lot of things but we agree on this.
@indio @kaniini @sean @how It's complicated. The ability to interact with any public post could lead to spam problems, but on the other hand it enables people to start interacting into an ongoing discussion at any time. And this is something important, especially when you are new in the network. It is complicated.
@Michael Vogel @:bunny: @deadsuperhero @hellekin

I agree that it's complicated. My girlfriend signed up on Pleroma and spent her entire first day on the fediverse blocking "sausages" as there was no other way to stop them from interacting. She cancelled on the second.

I think Mike did the right thing by making comment policy a personal choice and letting the site owner choose the best default for their family or community.  Changing this as a user is a terrifying experience in Hubzilla, however in Zap it's obvious and effortless. That's the kind of change I hope to bring to Osada once ActivityPub supports it.
@indio @sean @heluecht

in the fediverse (including Zot land) you can't *stop* a third party from commenting on your content.

what you *can* stop is third parties from invading your notifications with their shit. and, in Pleroma, you can do this by default, if you go into the settings.

you can also restrict your posts to followers-only (this needs to be improved in a diaspora aspects way, which we have in the works with address-to-lists, but it needs to be modelled in the FEs).

we must not claim to prevent what we cannot. a direct comment becomes a comment on a screenshot of the offending content. instead, we must build real mitigations against dogpiling and harassment.

setting people up for failure by saying that "these privacy controls are foolproof" is not acceptable.
@indio @heluecht @sean

and this is historically my criticism of Mastodon -- when I say that Mastodon sells people rotten fruit in an opaque bag, it is this "oh, we have this [trivially circumvented] setting that will keep you safe"

but that criticism applies to anyone who wants to sell snake oil.

this is the key thing. there are things that can and cannot be done in an open world system. we can change the scope of how the open world system works, but there are some fundamental things that are dubious promises at best.

systems allegedly free of harassment and "sausages" are one of these things that simply cannot be promised. similarly, systems free of nazis or other fascists cannot be promised either.

the user is a princess with a thousand enemies. if she has the right knowledge, she can be free. if she is told a line of bullshit, then she will never truly be free.

and, people still don't understand -- they blame non-Mastodon software for Mastodon security flaws to this day.

and bluntly, I think Zot is the same way in a lot of ways. when I have asked Mike how Zot can protect users in the way you describe, he doesn't reply with specifics.

and that's the dirty secret with Zot -- it's just as fundamentally flawed as ActivityPub. the only key difference is that it has the concept of endorsed actions, which slightly changes the trust model (but only amongst peers who agree to accept only the endorsed actions!)
@heluecht @indio @sean

lets consider the typical threat vector that Mastodon folks discuss: KiwiFarms.

what does Zot do differently than ActivityPub to prevent KiwiFarms users from installing their own nodes, which they have either modified or configured in some way to collude together?

and, this is the key thing people seem to always forget -- that other node in the network may or may not actually be following the same rules. the spec can say whatever it wants to say, that doesn't matter.

and unless you have a foolproof mitigation for this scenario, you should not claim Zot to be foolproof. Zot lacks harassment because nobody cares about Zot, not because Zot has fundamentally better security.
@:bunny: @Indio @Michael Vogel @deadsuperhero

I do not speak for Zot, nor do I know all the internals. I do know that comment permissions affect the ability for a hostile comment or a hundred thousand hostile comments to land on your profile wall in your space on your server in a conversation you control and then distributed by your server to all your friends. I agree there is no way to prevent people talking behind your back, nor can there be.

I would like to know how you intend to prevent dogpiling and harassment because I have seen no specifics from anybody. I am not working on Zot. I'm trying to find a way to federate that network's spam and abuse resistance to ActivityPub. If there is no way to do this because it cannot be done, my job is finished and I'll go back to living my life. As I understand it Zot does not care if any other node plays by its rules or not.  The rules apply to your node and exposure of any sensitive information to other nodes is minimized. Not eliminated but minimized. Your friends and their servers can always leak your private posts, and you can't change this in Zot or in ActivityPub.
@indio @sean @heluecht

Pleroma already has the ability to prevent hostile comments or 100k hostile comments from landing on your instance (with MRF). most likely, some form of user-level MRF can be done to provide the same capabilities a Zot implementation would have.
@:bunny: @Indio @Michael Vogel @deadsuperhero

Sorry but I don't speak that language.  A user-level MRF sounds like it will be as easy to setup as Hubzilla permissions, which is to say humans should not attempt it.
@indio @sean @heluecht can you make Osada use microformats2 markup for mention tagging at least

@kaniini @heluecht @how

Security is not a spectrum, where you can move from less secure to more secure. You’re either secure or you’re not. You need to achieve critical mass rapidly for new security features, and you cannot do that when people can go “well we’ll be able to interoperate with them without having to do anything…”

…Because they’ll do nothing, and do nothing, and do nothing, and then there goes any hope you had of making it stick.

@how I'm not keen on multibox. It adds implementation and UX complexity. I expect I'd only ever actually use one inbox.

Sign in to participate in the conversation
Une fois pour TOOT! A Mastodon in Brussels

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!