instances and ACLs

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