an appeal to the fediverse regarding anti-abuse 

Dear fediverse:

Fascism joining the fediverse is extremely bad, and we have to do something about it. But please, please, please: give me two weeks before you roll out any new solutions. Some of the solutions being proposed look like they will make the situation better but will make it much worse.

I am dropping nearly everything to write a demo and spec explaining how to do things right. Please give me two weeks. I've been preparing for this.

an appeal to the fediverse regarding anti-abuse 

As a hint as to why the current solutions aren't going to work, I'll point you to what happened when Mastodon rolled out direct messages with OStatus, but they *weren't really* private messages. An admirable attempt but it needed a different approach.

I believe this could be like that, but 10x worse. I've been studying what will happen under different approaches and trying hard to figure out how to map a solution onto what we have.

Show thread
Follow

an appeal to the fediverse regarding anti-abuse 

@cwebber what are their solutions that you find bad?

an appeal to the fediverse regarding anti-abuse 

@wilkie @cwebber more signatures, more metadata leakage, continuation of the authentication as authorization regime

re: an appeal to the fediverse regarding anti-abuse 

@kaniini @wilkie @cwebber sorry but I fail to see how signing fetch requests is more metadata leakage

re: an appeal to the fediverse regarding anti-abuse 

@Laurelai @Thib @kaniini *I've* been saying that this was coming two years ago :P

ActivityPub left holes in the spec because there were things we weren't ready to answer yet. People filled them in, understandably, in the ways they knew how. If you've followed me, you've seen me hand-wringing about it since, but i also think it's understandable.

But knowing how to do the right thing, and not break the ways things rolled out, required research.

re: an appeal to the fediverse regarding anti-abuse 

@Laurelai @Thib @kaniini I do know the tactics, and I have been talking to women and other groups about it, since before ActivityPub became an official standard, yes.

re: an appeal to the fediverse regarding anti-abuse 

@Laurelai @Thib @kaniini Anyway, that's all I'm saying on the matter. You can believe me or not that I've done the research; that's up to you.

I'm putting myself on a tight timeline so I think at this point it's better for me to show by actually delivering the writeup and code. You can judge for yourself, then.

re: an appeal to the fediverse regarding anti-abuse 

@cwebber @Laurelai @Thib

i know the tactics bullies use having been the recipient of them over the past basically forever of my life.

but i don't even consider bullies the threat vector. we need to have a serious conversation about commercial and nation-state surveillance, all of which are much more serious threats to activists.

re: an appeal to the fediverse regarding anti-abuse 

@Laurelai @cwebber @Thib

who says i am ignoring them?

re: an appeal to the fediverse regarding anti-abuse 

@cwebber @kaniini @Thib @Laurelai Perhaps ActivityPub shouldn't have been rushed out the door by W3C to appease gargon

re: an appeal to the fediverse regarding anti-abuse 

@tuttle @cwebber @Laurelai @Thib

i don't think that is a fully accurate representation of what happened.

the deadline for the W3C Social WG to finish up its work was looming and AP would have died entirely if Mastodon didn't adopt it.

it then got rushed out the door because the extension deadline was looming.

re: an appeal to the fediverse regarding anti-abuse 

@Laurelai @cwebber @tuttle @Thib

I didn't say it was good, did I? but we are working to fix the fallout. it will be incremental, but we will get there

an appeal to the fediverse regarding anti-abuse 

@kaniini @wilkie And it isn't obvious to people why this is bad. At first glance, it *looks* good; for some things it's fine: we can block a Gab or two, but anyone can start a new instance. Eventually we endi up at fediverse nation-states with border patrol guards, or a whitelisting of instances, which quickly results in defederation. Other problems but I'd have to refer to the literature.

A "network of consent" approach is the alternate option.

an appeal to the fediverse regarding anti-abuse 

@kaniini @wilkie On top of that, there are things the network will *no longer be able to do* that are exciting, cool futures if we go this route. Not only will the network degrade, we'll lose the opportunity to grow in ways that are very interesting, to be able to do the kind of rich interactions that aren't even possible on contemporary centralized social networks.

an appeal to the fediverse regarding anti-abuse 

@cwebber @kaniini for me, I often think "is federation the actual goal or is it a consequence of a technology" and for the technical folks it seems to be one thing and for users another

an appeal to the fediverse regarding anti-abuse 

@wilkie That's probably a really hard question for @cwebber to answer, since it'd involve talking about his plan that, as he said, isn't ready.

So I'll try and answer: One issue is they would like to cryptographically-ensure that a communication is proper, which means that the more targeted your server is by harassment, the more costly it will be to continue operating. Another is that it doesn't allow a similar autonomy of moderation as is current.

an appeal to the fediverse regarding anti-abuse 

@emsenn @wilkie @cwebber yeah, i'm really worried about the message encryption proposals incurring O(n^2) costs that are easily DoSable

an appeal to the fediverse regarding anti-abuse 

@emsenn @wilkie @cwebber if you give me a sec, i can show you an example of a proposal someone on here put forward in response to gab that seems reasonable at first glance but actually has some glaring holes

glad you're thinking about this carefully, chris

@emsenn @wilkie @cwebber Please elaborate on the autonomy of moderation point. What do you mean by that?

@Gargron If I understand it right - which I very well might not:

Current discussions of OCAP provide the tools to instance moderators, but don't provide similar tooling for users.

Right now, as I understand it, users can do most of the moderation action moderators can, relative to their own profile: they can autonomously moderate their profile even if their instance doesn't do moderation.

(Again, I could be wrong in understanding how things are or could be.)
@wilkie @cwebber

@emsenn @wilkie @cwebber I don't think that's quite right. Now, I don't know which "some of the solutions" Chris is talking about, because I'm aware of what I'm proposing (authorized fetch, same mechanism as already used for inbox deliveries) and what kaniini is proposing (OCAP), and I am under the impression that Chris's solution is OCAP too. But neither of those would affect any existing self-moderation mechanisms.

@Gargron I didn't think current moderation tools would be changed. As I understand it, kaninii's OCAP is focused on interinstance moderation, not a user moderating their own profile with it. That's my concern: that I will be reliant on my instance admin to handle any abuse that needs to be addressed with OCAP. As I understand it, Chris' solution is OCAP as well, but more generalized so can be an inter-user tool just as easily. (Again, I could be wrong about all this.) @wilkie @cwebber

@emsenn @gargron @wilkie The ways @kaniini and I have currently proposed using ocap stuff are a bit different, though they have overlap. I think it'll be clearer how they can converge once I put it out though.

Poor @cwebber announces he's dropping everything to work on a thing and by nature of doing so gets a bunch of folk beeping to ask about the thing he hasn't finished working on. Bless instant global communication. @Gargron @wilkie @kaniini

@cwebber @emsenn @Gargron @wilkie
The pattern @kaniini published as "Lice" some time back addresses instance moderation only. They've hinted that subsequent work is vastly better and that code, if enabled, would break federation with Mastodon

There's a broad range of philosophies on the fedi largely centered on personal autonomy, especially wrt labor. This is a good time to be mindful of that common bond

@cwebber @emsenn @Gargron @wilkie @kaniini Yeah I will be really interested to see where y'all land. I'll get it integrated into go-fed. The last time kaniini and I were able to have a solid chat was exactly about this OCAP kind of stuff and the differences between proposals.

@cj @cwebber @emsenn @Gargron @wilkie @kaniini

Maybe somebody or two could get a proof of concept or two deployed where other people can test them?

@bhaugen
Thanks. In a few months I'll have a good base for testing, but I do have to finish the damn thing. If my day wasn't already shot by a virus, I wouldn't be near this conversation

The lack of communication has been frustrating, but I understand enough for now and I'm behind on my own work
@cj @cwebber @emsenn @Gargron @wilkie @kaniini

@yaaps @wilkie @Gargron @emsenn @cwebber @cj @bhaugen

hehe I'm mostly in a holding pattern right now waiting on cwebber to bring it all together. but we are close!

@emsenn @wilkie @cwebber OCAP as well as authorized fetch are primarily about how to allow/disallow another server to retrieve public data from yours, specifically in the case of domain blocks.

Personal blocks, mutes, filters and the rest operate on a logically higher level than that.

@Gargron Ahh so OCAP is not used to forbid/permit an individual but a domain? I had thought that was dependent on implementation, not an intrinsic quality of the feature.

I think it's clear the one thing I was right on is that I don't know what I'm talking about. :D
@wilkie @cwebber

@emsenn @gargron @wilkie ocap on its own has nothing to do with domain-level authority decisions, that's a specific suggestion of how to do something semi-ocap'y for that purpose

@Gargron
The issue isn't the UI for individual tools, but the effectiveness of such tools in an environment where the server administers keys and shares data without regard for scopes on the remote. Discovering scopes on the remote is a vector for targeted abuse. Individually authenticated access is a DoS risk. OCaps provide the benefits of authenticated fetch with a profile less conducive to DoS
@emsenn @wilkie @cwebber

@yaaps @emsenn @wilkie @cwebber DoS wise, if OCAP generates unique URLs (say, with a token query param), then it's just as uncacheable as authorized fetch, the difference being that a token needs to only be looked up against a local database, and authorized fetch sometimes needing to resolve a remote account through a synchronous HTTP request. However, in most cases only a database look up would be used, and we could also cheat and not do look-ups if the account isn't already known.

@yaaps @emsenn @wilkie @cwebber Regarding what the remote server does internally, I don't think OCAP is going to change anything significantly about that.

@yaaps @emsenn @wilkie @cwebber Let me correct myself: I think OCAP would help some behaviour rules be enforced when otherwise the state between servers is for some reason out of sync, as long as it's a good-willed server. But the point of attack that authorized fetch addresses aren't good-willed servers, but rouge actors.

@Gargron
Thanks

I'm making an argument from lesser to greater first. Even with only instance level effectiveness, the difference means being 2 hops instead of 3 from certain instances

The next step is whether you accept @cwebber's claim to provide a migration path from the current shared inbox to one where these scopes are possible. Worst case, abuses become an enforceable part of the social contact
@emsenn @wilkie l

@emsenn @Gargron ah, you are right about the current implementation in Mastodon. That can be fixed though (but it would be more expensive)

@emsenn @Gargron say hello to github.com/tootsuite/mastodon/

Also, your claim about “the more targeted your server is by harassment, the more costly it will be to continue operating” is partially true: cryptography as well as the most expensive db queries are avoided when the instance is known to be blocked instance-wide (not the user-defined blocks honored by this PR)

@Thib Gonna untag Gargron since I'm just asking questions: My main concern is with short-lived instances spun up to DDoS more than a known server trying to spam me. There are tools at nearly every part of the network stack for dealing with the latter.

@emsenn that concern is already very much present without authenticated fetches, unfortunately

@Thib Well, the concern of DDoSing at a network level is, sure. But the encryption stuff adds other resources to the pile of what can be made scarce.

@emsenn that can be done by pushing things to the inbox, this will trigger exactly the same kind of workload as fetching a toot with a signed request.

And I'm not sure something OCAPS-based will help a lot, since you'd still have at least the endpoint(s) dedicated to requesting caps vulnerable to the same kind of things

@emsenn that being said, I'm still curious what cwebber comes up with

@Thib Thanks for that first sentence - it's a crucial part in what I was missing to understand.

re: an appeal to the fediverse regarding anti-abuse 

@emsenn @wilkie @cwebber

Another is that it doesn't allow a similar autonomy of moderation as is current.

I don't understand what you mean by that.

re: an appeal to the fediverse regarding anti-abuse 

@Thib If you click that message again you should see me trying to explain it in another response - I hit send on that the same time you did on this, lol. @wilkie @cwebber

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!