ActivityPub

Social websites first got us talking and sharing with our friends online, then turned into echo-chamber content silos, and finally emerged in their mature state as surveillance capitalist juggernauts, powered by the effluent of our daily lives online. The tail isn’t just wagging the dog, it’s strangling it. However, there just might be a way forward that puts users back in the driver seat: A new set of specifications for decentralizing social activity on the web.

Dietrich Ayala
https://hacks.mozilla.org/2018/11/decentralizing-social-interactions-with-activitypub/

ActivityPub is a W3C standard that sets a standard for how various social networks can communicate with each other. Unlike the Surveillance Capitalist sites like Twitter and Facebook, it is open, and because it is used on federated networks like Mastodon, it is more secure. The Twitter hack of July, 2020 (when accounts of famous people appeared to offer links to bitcoin scams) could not happen on Mastodon precisely because no one server can give you access to all of the major accounts. Without getting into all of the technical details, federated social networks operate similarly to e-mail. As an example, I have my own domain for which I have e-mail (zwilnik.com, you are here right now). But I am not limited to sending or receiving e-mail only within my domain, which is good because I am the only one here. I can send anyone a message as long as I know their username and their e-mail provider. Put those together and you have an e-mail address: username@provider.com.

Federated media enabled by ActivityPub operates the same way. On Mastodon I have a username and I am on a server, and if you know my username and which server I am on, you can send me a message. So there is nothing radically strange about federated social networks. But with ActivityPub, you can actually send messages between different networks. That would be like posting in Twitter and having it go to Facebook automatically. This is something most users of social media want, but which the owners of surveillance capitalist media frustrate because it does not fit their business model. Twitter and Facebook are looking to make money at every opportunity, which federated media is not. (There are costs though, which is why I added the admin of my Mastodon server to my Patreon monthly donation list.)

ActivityPub follows what is called the actor model, which says that everything is an actor. It is thus analogous to some degree with the idea from object-oriented programming that everything is an object. According to Wikipedia:

An actor is a computational entity that, in response to a message it receives, can concurrently:

• send a finite number of messages to other actors;
• create a finite number of new actors;
• designate the behavior to be used for the next message it receives.

https://en.wikipedia.org/wiki/Actor_model#Fundamental_concepts

One thing you can get from this is that e-mail also follows the actor model. Again nothing terribly radical about this. And the result has been nice. My Mastodon feed is, to quote Sarah Jeong, like “Twitter without all the Nazis”. I am connected to people I like and the conversation is civil.

So, ActivityPub and federated media are awesome in many ways, but everything can be improved. This is where OcapPub comes in.

Where Things Go Wrong

If Mastodon is “Twitter without all of the Nazis”, why is that? There are mechanisms in place to help with that. You can block someone from your feed, or even ask your Sysadmin to block them or even block the entire server they come from. But these are not ideal, and the main reason it hasn’t been such a problem is that Mastodon doesn’t have as many users as Twitter. I have noted something on another federated platform, Diaspora, that is a sign of things to come. I’m seeing the trolls show up, and people are posting names of users they recommend be added to your block list. The problem with this approach is that it privileges the sender over the receiver. We are saying that bad actors have the right to send us messages we don’t want and that it is our problem to figure out how to stop them. Every day I have to go through my SPAM folder to make sure nothing important got sent there by mistake before I delete the messages. Just how many times did something important get flagged by mistake? And while SPAM is merely an annoyance, harassment can cause trauma. Do we really want to enable more GamerGates? The Internet lynch mobs are already too powerful, and people have died because of it. Block lists in the end do not work because trolls and Nazis just create new accounts “for the lulz”, and you end up spending ever increasing amounts of time maintaining the block list. It is a game of “whack-a-mole” that you cannot win.

So, maybe you want to go from a “blocklist” to an “allow list”. That’s the ticket. Except: who gets to be allowed? The virtue of federation is that it encourages “a thousand flowers to bloom.” We want more people to set up their own servers, we want people to join with like-minded people, but who will put all of those severs on an “allow list”? Just maintaining that is daunting. So, we’ll just put the few top servers on the allow list! Great, we have now replicated the centralized system we were trying to get away from.

OcapPub

OcapPub is a proposed way (this is still a work in progress) to let the receiver set the rules for what is wanted. It gets the balance right, in my view, when it comes to free speech, since it assumes that free speech also means the freedom to filter. In England, they have a wonderful institution in Hyde Park called the Speaker’s Corner, which permits pretty wide-open speaking by almost anyone, but no one is ever forced to go there and listen. And often people stop and listen just to be entertained by the craziness.

OcapPub does this by building networks of consent using object capabilities. First, what do we mean by networks of consent? It is a way establishing trust between parties. This is something we do all of the time in our personal lives. As an example, we have a good friend who has a key to our house, and we have a key to her house. This worked out great she was out-of-town and my wife was able to get a plumber in to fix a leaky pipe, and of course that is the exact reason we exchanged keys. We each trust that the other won’t do anything we don’t approve of with those keys. And of course you don’t give a key to your house to just anyone. You have to build a relationship of trust first, and this is an example of a very high level of trust. There is a somewhat lower level of trust in something like joining a Neighborhood Watch program, and so on down the line. I have the absolute highest level of trust for my wife, only slightly less for other family, then close friends, and so on. As Ringo sang, “I don’t ask for much, I only want trust”, and that is essential to living in a society. Access Control Lists, in contrast, is a fundamentally broken system that allows for such problems as click-jacking and Cross-Site Request Forgery attacks that afflict so many web sites. One aspect of the fundamental problem with Access Control Lists is that they conflate two different things: Authentication of Identity, and Authorization to perform a task.

Object Capabilities come into it when we consider those house keys we exchanged. Put simply, the key is an object which has the capability of opening a door. A door lock opens for anyone who has the appropriate key, that is inherent in the concept of lock-and-key. And we don’t use an access control list or ask for login credentials for anyone using a key. Obviously, the fact that a key can do this makes it powerful, and it means we need to be careful about who we give them to, but we have all managed to do this pretty well. Or in my home life, I don’t ask my wife to use a login and password, let alone 2 factor authentication, before she grabs the key to my car and uses it to drive. I gave her a key when I bought the car, and trust her to use it wisely. The other day I realized my car was not in the driveway and knew she had taken it (my car has the bike rack), and if I needed to go anywhere I would use my copy of the key to her car (and I did so to go meet her for walk in the park.)

Now this example illustrates the point that there are different levels of trust, and we should take that into account in handing out capabilities to people. And this brings us to the Principle of Least Privilege, which says that any user, object, etc. should only have access only to the information and resources that are necessary to its legitimate purpose. Access Control Lists (ACLs) do not follow this principle without a lot of work-arounds (at best). OcapPub proposes to fix this by using the added capabilities of code to do several useful things that are more difficult in the real world:

• Delegation – My wife could lend the key to my car to someone else. I’m trusting her to only do that in way that makes sense to both of us. With ACLs, you would have give someone else your login, so in a sense they are pretending to be you, in fact they *are* you as far as the system knows.
• Attenuation – We have a system for teenagers who are learning to drive called a “Learner’s Permit” which let’s them operate a motor vehicle legally but only under strict limits. Imagine if you could give them a key that only works until 9pm and won’t let them drive too fast! We can design objects to have only the capabilities they need to have (Principle of Least Privilege).
• Revocation – Since these objects are code, we can build in switches to allow revocation. So if Junior comes home late, or gets into an accident, or whatever, you take the key away, or perhaps more accurately you flip a switch that makes it no longer operable.
• Accountability – Through logging, we can see who does what with the capabilities we have handed out. If you find the scratch on the car door, Junior can’t say “I didn’t do it” because logging will have determined when it happened and who was driving.

With all of these tools, we can begin to fix the problems which still exist in Federated Social Media. We could probably do much of the above using sufficiently complicated sets of rules and ACLs, but that is just layering fragile cruft onto a fundamentally broken system. What is broken is the idea that capabilities should be tied to a person, because then identity theft means you are one hack away from losing everything. Devising objects with capabilities and respecting the Principle of Least Privilege is a much better way to go.

Listen to the audio version of this post on Hacker Public Radio!