This is a draft of what I'll hopefully be submitting to Rebooting Web of Trust. If anyone would like to take a look, constructive feedback welcome:
Typo - DKIM
"In Email, verification is largely achieved... such as SPF14 or DMIM15."
Enjoying it so far. Good luck. 👍
@emacsen there's a typo in the alternativeInbox example (`"alternativeInbox::` instead of `"alternativeInbox":`)
@emacsen Hey, thanks for putting this all down on paper! some thoughts:
- I don't understand what ocap inboxes achieves over the current ability of moderators and users to block individual actors. how does this meaningfully improve spam-fighting abilities?
- You mention two methods for "Closing the Relay Hole", which both seem very similar to the discussion on https://github.com/w3c/activitypub/issues/319. You seem to gloss over the backwards-compatibility issues though—have you put thought into how you would implement this?
@nightpool Thanks for reading and feedback. It may take me a few replies to answer your question.
OCAP Inboxes offer two distinct advantages. The first is that they're transferable. Let's imagine that instead of inboxes, we were talking about phone numbers. If you call my "default number" you'd get my secretary who screens my calls. If I like you, I'll hand you a card with three phone numbers. Each of these get to me directyl (bypassing my secretary). One of those you use yourself.
@emacsen what value does transferability have in an anti-spam system? isn't that just strictly worse then blocking individual actors? (if each actor can get its own inbox, which ties into my comments on the "pet names" proposal)
@nightpool Blocking individual actors and OCAP Inboxes are both useful, but could happen at different places.
"Default Postage" may be a good default policy, maybe a second policy might be do to content filtering, Pet Names might bypass Postage (maybe!) and OCAP Inboxes might bypass all of them (ala a whitelist).
I want to avoid being too perscriptive right now and focus on techniques.
@nightpool One of those you put on your mobile phone. You now have one left. And let's say you meet someone that you think should talk to me- you can give them that last number. You know they'll be able to get through to me directly this way.
That capability is transferrable.
I still retain the ability to revoke any phone number, eg if your friend keeps calling me and calling me, or gives that number to scammers.
Now they'll have to go through my secretary again.
@nightpool The code advantages are also very powerful. Without OCAP, I need to do a ton of checks. "Is this account who it claims to be? Are they on a whitelist? Do they meet these checks..."
With OCAP Inbox, I can avoid many of those checks and where I do, they're more simple/contained.
As to replies... I hadn't seen that issue. Thank you.
Yes, AP would need to be modified since the potocol demands that there MUST be a forwarding. Exactly how- I'm not sure yet. Need to think more. about it.
@emacsen A couple of your proposals seem like they would limit too much—the pet names proposal seems to boil down to "don't allow replies from people who don't follow or aren't followed by people you follow or are followed by", which seems like it would basically get rid of the local and federated timelines and any interaction on those timelines.
@nightpool I don't specify any actions in my proposals. I never specify that anything be blocked, for example, so nothing I propose is about restriction.
The Pet Names proposal is not associated directly with Followers/Following, but putting that aside to the core question, which is about replies, this is a hard question but my answer is:
The problem isn't replies in my mind, it's that when you reply, the protocol dictates that I send your reply to my followers. The problem with that is that this bypasses checks the recipient might do (content checks, postage, etc.). Because of that, I think replies need to be more scrutinized. That means some form of additional checks on them for actors you've never interacted with and have no (even indirect) connection to.
Moderation is essentially OK IMHO to address this.
@emacsen ah, i don't think any current implementations work the way you're describing. (where forwarding the reply bypasses checks the recipient might do). The AP spec explicitly says "The server MAY filter its delivery targets according to implementation-specific rules (for example, spam filtering)." (which means it may choose not to forward replies that it considers spam)
@emacsen i agree that this is kind of confusing language when combined with the MUST above, but i believe it's still consistent when both requirements are read together.
@nightpool You're right about that MAY- it's a good point.
@emacsen one note about the "Bounce Messages" thing is that nearly many activitypub implementations process activities asynchronously in some sort of job queue, so it's impractical to expect them to be able to provide a synchronous error message (which is why mastodon uses 202 Accepted as our status code when processing activities)
@emacsen I think there's a small modification of this that recommends a "postback" Reject activity to the actor's inbox when an activity is rejected, but that also has downsides, such as DDOS amplification.
@nightpool Concerns about callbacks and DDOS is exactly why I didn't suggest it.
@emacsen ah, that's interesting, I hadn't gotten to that section. That seems like a big deviation from "standard" activitypub and i'm not sure that it's going to be effective in practice (it creates a lot of busywork for both delivering and receiving servers in exchange for a very marginal benefit in the case where a message is rejected). but it's a really interesting idea!
@nightpool You're right that it's a big deviaition, but my concern is that at least in email, some of the time I know why my message was rejected.
"My DNS is broken" "I'm on a blacklist" "My HELO is reporting something wrong." etc.
That doesn't address everything, eg if a message happens to be caught up in some spam filter, but works sometimes.
What happens when we start tightening up our AP delivery? Will messages be silently dropped? I'd love if we could avoid that.
@nightpool Because of the ascynonous nature of delivery, I suggested a Promise type for later looking up a message's delivery status.
Do you feel that the suggestion about Bounce Messages should be eliminated in favor of always just handing out Promises?
It seems like anyone can request a new preferred inbox from me at any time, and then if they do so and abuse it, I can stop looking at messages sent to that inbox (like a burner phone number). But then the attacker can just request another inbox from me, right? I don't know ahead of time which stranger to grant/deny an inbox to; if I did, spam and harassment wouldn't be an issue.
burner phone numbers are useful because phones often have shitty blocking/filtering features and because we can't identify who is calling us because spoofing is so easy, and so handing out a unique burner number is a way to handle identification. But it seems like ActivityPub (and to some extent, email, through DKIM/SPF) *can* identify the sender of a message, and so I can block someone who sends me an unwanted message. But why use burner inboxes if I can client-side filter?
Two reasons. Firstly, because ACLs are hard to maintain. They're complex to use, complex to set up, complex to maintain computationally. You can get further with OCAP with less complexity.
Second reason is that OCAP allows for transferability. If I trust you to get ahold of me, I might also trust you to be responsible enough to give someone else my direct line. That's simply not possible with ACLs.
@emacsen I do like the transferability that capability URLs have, like Flickr's guest passes. Even if you don't have an account, or I didn't list you specifically but my friend trusts you, they can hand along a special URL which lets you read/see something. There's some extra UI for tracking/revoking those URLs, but it's not terribly burdensome. I haven't seen capability URLs used for write access as often.
Maybe it just doesn't seem to me that most of the problems with spam/harassment are people I know or friends-of-a-friend getting blocked. Is whitelisting of people I already follow/interact with a difficult challenge that I just haven't experienced?
You can look me up in the phone book and get my public number. That's the one that rings my secretary who screens my calls. He is a prickly fellow who doesn't like to bother me with crap.
But if I talk to someone, I can offer them a direct line to me- but those direct lines are (in your parlance) burner phones.
@emacsen @nightpool yeah, it's a different usage/analogy than burner phone numbers, as those are specifically given to people you *don't* trust, whereas you're talking about giving out capability URLs to people you do already trust.
At first glance, that seems less usable to me. Rather than recording in my client "I trust Person X" (whitelist), I give Person X a special URL, tell them to use it rather than my well-known name and make them promise not to accidentally make it public.
A checkbox next to someone that says "trust them" or something is what I imagine would happen to send them preferredInboxes. The rest would happen under the hood.
And your client could have a button "Introduce" that would do the other part too.
A regular user wouldn't need to know the OCAP theory and all that jazz.
emacsen.net is one server in the network