diff --git a/README.org b/README.org index dea18b8..88e94ee 100644 --- a/README.org +++ b/README.org @@ -412,9 +412,160 @@ structurally insufficient to be the /foundation/ of our approach. -- Marc Stiegler, [[http://www.skyhunter.com/marcs/ewalnut.html][E in a Walnut]] #+END_QUOTE +Part of the major narrative of the federated social network at the +moment is that running an instance is an excellent opportunity to host +and support a community, maybe of people like you or people you like. +Different rules may apply differently on different instances, but +that's okay; choose an instance that matches your personal philosophy. + +So you run an instance. +On your instance, maybe some bad behavior happens from some users. +You begin to set up policies. +You perhaps even ban a user or two. +But what about bad behavior that comes from the outside? +This is a federated social network, after all. + +Blocking a user is fine. +Blocking an instance or two is fine. +But what happens when anyone can spawn a user at any time? +What happens when anyone can spawn an instance at any time? +Self-hosting, which originally seemed like something to aspire +to, becomes a threat to administrators; if anyone can easily spawn +an instance, host administrators and users are left playing +whack-a-mole against malicious accounts. +It seems like our model is not set up to be able to handle this. + +Soon enough, you are tired of spending all your free time +administrating the instance blocklist. +You begin to set up the ability to share automatic blocklists between +friends. +But the governance of these lists seems fraught at best, and prone +to in-fighting. +Worse yet, you seem to have improperly gotten on several blocklists +and you're not sure how. +The criteria for what is and isn't acceptable behavior between +instances varies widely, and it's unclear to what extent it's worth +appealing. + +It dawns on you: the easier approach isn't a deny-list, it's an +allow-list (aka a whitelist). +Why not just trust these five nodes? +It's all you have energy for anymore. + +Except... what if you aren't one of the five major nodes? +Suddenly you see that other nodes are doing the same thing, and +people are de-federating from /you/. +It's not worth running a node anymore; if you aren't on one of the top +five... hold up... top three instances anymore, nobody gets your +messages anyway. + +This is the "nation-state'ification of the fediverse", and it results +in all the xenophobia of nation-states traditionally. +Sure, border guards as a model on the fediverse aren't as bad as +in the physical world; they can't beat you up, they can't take your +things (well, maybe your messages), they can't imprison you. +And yet the problem seems similar. +And it's only going to get worse until we're back at centralization +again. + +A fundamental flaw occurred in our design; we over-valued the role +that instances should play /altogether/. +While there is nothing wrong with blocking an instance or two, the +network effect of having this be the foundation is re-centralization. + +Furthermore, it doesn't even reflect human behavior; few people +belong to only one community. +Alice may be a mathematics professor at work, a fanfiction author +in her personal time, and a tabletop game enthusiast with her friends. +The behaviors that Alice exhibits and norms of what is considered +acceptable may shift radically in each of these communities, even if +in all of these communities she is Alice. +This isn't duplicitous behavior, this is normal human behavior, +and if our systems don't allow for it, they aren't systems that +serve our users' needs. +But consider also that Alice may have one email account, and yet may +use it for all three of these different communities' email mailing +lists. +Those mailing lists may be all on different servers, and yet Alice +is able to be the right version of Alice for each of those communities +as she interacts with them. +This seems to point at a mistake in assumptions about the federated +social web: the instance is not the community level, because users +may have many varying communities on different instances, and each +of those instances may govern themselves very differently. + +So far the problems with "perimeter security" described above have +been examples restricted to the social level. +As it turns out, perimeter security has another problem when we start +thinking about authorization called the "confused deputy problem". +For example, you might run a local process and consider that it +is localhost-only. +Whew! Now only local processes can use that program. +Except now we can see how "perimeter security" is "eggshell security" +by how easy it is to trick another local program to access resources +on our behalf. +An excellent example of this where +[[https://lists.gnu.org/archive/html/guile-user/2016-10/msg00007.html][Guile's live-hackable REPL suffered a remote execution vulnerability]]. +Except... Guile didn't appear to "do anything wrong", it restricted +its access to localhost, and localhost-only. +But a browser could be tricked into sending a request with code that +executed commands against the localhost process. +Who is to blame? +Both the browser and the Guile process appeared to be following +their program specifications, and taken individually, neither seemed +incorrect. +And yet combined these two programs could open users to serious +vulnerability. + +Perimeter security is eggshell security. +And the most common perimeter check of all is an identity check, +the same paradigm used by Access Control Lists. +It turns out these problems are related. *** Access Control Lists +Up until recently, if you drove a car, the car did not determine +whether you could drive it based on who you are, as your identity. +If you had a key, you could drive it, and it didn't matter who you +were. + +Nonetheless, since Unix based its idea of authority on "who you are", +this assumption has infected all of our other systems. +This is no surprise: people tend to copy the models they have been +exposed to, and the model that most programmers are exposed to is +either Unix or something inspired by Unix. + +But Unix uses ACLs (Access Control Lists), and ACLs are +[[http://waterken.sourceforge.net/aclsdont/current.pdf][fundamentally broken]]. +In no way do Access Control Lists follow the +[[https://en.wikipedia.org/wiki/Principle_of_least_privilege][Principle of Least Authority (PoLA)]], which is necessary for users +to be able to sensibly trust their computing systems in this modern +age. + +To be sure, we need authentication when it is important to know that a +certain entity "said a particular thing", but we need to know that +this is not the same as knowing whether a particular entity "can do a +certain thing". + +Mixing up authentication with authorization is how we get ACLs, +and ACLs have serious problems. + +For instance, consider that Solitaire (Solitaire!) can steal all your +passwords, cryptolocker your hard drive, or send email to your friends +and co-workers as if it were you. +Why on earth can Solitaire do this? +All the authority it needs is to be able to get inputs from your +keyboard and mouse when it has focus, draw to its window, and maybe +read/write to a single score file. +But Solitaire, and every other one of the thousands of programs on +your computer, has the full authority to betray you, because it has +the full authority to do everything you can... it /runs as you/. + +And that's not even to mention that ACLs are subject to the same +confused deputy problems as discussed in the previous section. +In this paper we'll lay out how ocaps can accomplish some amazing +things that ACLs could never safely do... because [[http://waterken.sourceforge.net/aclsdont/current.pdf][ACLs Don't]]. + *** Content-centric filtering *** Reputation scoring