diff --git a/README.org b/README.org index 7e1b420..1df173b 100644 --- a/README.org +++ b/README.org @@ -382,43 +382,43 @@ This does not mean that there aren't other layers where we can't prohibit such activity, but we shouldn't pretend we can prevent it at the protocol layer. -For example, Alice may converse with her therapist over the +For example, Alyssa may converse with her therapist over the protocol of sound wave vibrations (ie, simple human speech). -Alice may be expressing information that is meant to be private, +Alyssa may be expressing information that is meant to be private, but there is nothing about speech traveling through the air that prevents the therapist from breaking confidence and gossiping about it to outside sources. -But Alice could take her therapist to court, and her therapist could +But Alyssa could take her therapist to court, and her therapist could lose her license. But this is not on the protocol layer of ordinary human speech itself. Similarly, we could add a "please keep this private" flag to -ActivityPub messages so that Alice could tell Bob to please not +ActivityPub messages so that Alyssa could tell Ben to please not share her secrets. -Bob, being a good friend, will probably comply, and maybe his client +Ben, being a good friend, will probably comply, and maybe his client will help him cooperate by default. But "please" or "request" is really key to our interface, since from -a protocol perspective, there is no guarantee that Bob will comply. -However this does not mean there are no consequences for Bob if he -betrays Alice's trust: Alice may stop being his friend, or at least +a protocol perspective, there is no guarantee that Ben will comply. +However this does not mean there are no consequences for Ben if he +betrays Alyssa's trust: Alyssa may stop being his friend, or at least unfollow him. Likewise, it is not possible to attach a protocol-enforceable "do not delegate" flag onto any form of authority, whether it be an ocap or an ACL. -If Alice tells Bob that Bob, and Bob alone, has been granted access to -this tool, we should realize that as long as Bob wants to cooperate +If Alyssa tells Ben that Ben, and Ben alone, has been granted access to +this tool, we should realize that as long as Ben wants to cooperate with Mallet and has communication access to him, he can always set up -a proxy that can forward requests to Alice's tool as if they were -Bob's. +a proxy that can forward requests to Alyssa's tool as if they were +Ben's. We are not endorsing this, but we are acknowledging it. -Still, there is something we can do: we could wrap Bob's access to -Alice's tool in such a way that it logs that this is the capability -Alice handed to Bob being invoked every time it is invoked, and -disable access if it is misused... whether due to Bob's actions, +Still, there is something we can do: we could wrap Ben's access to +Alyssa's tool in such a way that it logs that this is the capability +Alyssa handed to Ben being invoked every time it is invoked, and +disable access if it is misused... whether due to Ben's actions, or Mallet's. -In this way, even though Alice cannot prevent Bob from delegating -authority, Alice can hold Bob accountable for the authority granted +In this way, even though Alyssa cannot prevent Ben from delegating +authority, Alyssa can hold Ben accountable for the authority granted to him. If we do not take this approach, we expose our users to harm. @@ -527,19 +527,19 @@ 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 +Alyssa 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 +The behaviors that Alyssa 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. +in all of these communities she is Alyssa. 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 +But consider also that Alyssa 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 +Those mailing lists may be all on different servers, and yet Alyssa +is able to be the right version of Alyssa 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 @@ -692,45 +692,45 @@ We will get into the technicality of how to implement ocaps in The foundation of our system will rely on establishing trust between two parties. -If Alice trusts Carol to be able to perform an action, she might +If Alyssa trusts Carol to be able to perform an action, she might "give consent" to Carol. -However, giving consent to Carol is not necessarily permanent; Alice +However, giving consent to Carol is not necessarily permanent; Alyssa has the tools to track abuse of her resources, and if she sees that Carol is irresponsible, she can revoke her consent to Carol. -(While Carol could have handed this authority to someone else, Alice +(While Carol could have handed this authority to someone else, Alyssa would still see the abuse coming from the access she handed Carol, and could still hold Carol responsible.) What about users that do not yet trust each other? -If Alice does not yet know or trust Bob, it is up to Alice's default -settings as to whether or not Bob has any opportunity to message Alice. -Maybe Alice only gets messages from entities she has existing +If Alyssa does not yet know or trust Ben, it is up to Alyssa's default +settings as to whether or not Ben has any opportunity to message Alyssa. +Maybe Alyssa only gets messages from entities she has existing relationships with. -However, it is possible that Alice could have a "default profile" +However, it is possible that Alyssa could have a "default profile" that anyone can see, but which bears a cost to send a message through. -Perhaps Bob can try to send a message, but it ends up in a moderator +Perhaps Ben can try to send a message, but it ends up in a moderator queue. -Or, perhaps Bob can send Alice a message, but he must attach "two +Or, perhaps Ben can send Alyssa a message, but he must attach "two postage stamps" to the message. -In this case, if the message was nice, Alice might refund Bob one +In this case, if the message was nice, Alyssa might refund Ben one or both stamps. She might even decide to hand him the authority to send messages to her in the future, for free. -But say Bob is a spammer and is sending a Viagra ad; Alice can keep +But say Ben is a spammer and is sending a Viagra ad; Alyssa can keep the stamps. -Now Bob has to "pay" Alice to be spammed (and depending on how we -decide to implement it, Alice might be able to keep this payment). +Now Ben has to "pay" Alyssa to be spammed (and depending on how we +decide to implement it, Alyssa might be able to keep this payment). There is always a cost to unwanted messages, but in our current systems the costs lie on the side of the receiver, not the sender. We can shift that dynamic for unestablished relationships. -And critically, it is up to Alice to decide her threshold: if she is +And critically, it is up to Alyssa to decide her threshold: if she is receiving abusive messages, she can up the number of stamps required, disable her public inbox entirely, or hand over moderation to a trusted party during a particularly difficult period. But even if she disables her inbox, the parties which have existing -trust relationships with Alice can still message her at no cost. +trust relationships with Alyssa can still message her at no cost. While we do not claim that we can fully model a system of consent in this system, we can provide the @@ -800,28 +800,28 @@ some interesting things we could do: construct and hand the valet a "valet key" that only permits driving five miles and won't open the glove box or trunk. Sorry kid, you're not getting a joy ride this time. - - *revocation*: Let's say that Alice wants to allow her roommate - Bob to drive her car, but she also wants to be able to take away - that right if Bob misuses it or if they stop being roommates. - Alice can make a new car key that has a wire inside of it; - Alice holds onto a device where if she presses the button, the + - *revocation*: Let's say that Alyssa wants to allow her roommate + Ben to drive her car, but she also wants to be able to take away + that right if Ben misuses it or if they stop being roommates. + Alyssa can make a new car key that has a wire inside of it; + Alyssa holds onto a device where if she presses the button, the key "self destructs" (ie the wire melts). - Now Alice can stop Bob from being able to drive the car if she + Now Alyssa can stop Ben from being able to drive the car if she wants to (and if she does, it'll also disable access to anyone - else Bob has delegated a key to). - - *accountability*: Alice has multiple roommates, and while she would + else Ben has delegated a key to). + - *accountability*: Alyssa has multiple roommates, and while she would like to allow them all to drive her car, the next time someone spills a drink in the car and doesn't clean it up, she wants to know who to blame by seeing who drove the car last. - Alice can achieve this via *composition*: she installs a separate + Alyssa can achieve this via *composition*: she installs a separate "logging" panel into the dashboard of her car, to which she has the capability to view the logs. Next, for the keys that she hands her roommates, she composes together access to drive the car with the logging service and associates each key with her roommate's name. Now each time one of her roommates uses one of these keys, the logging - console (which only Alice has access to) takes note of the associated - name, so Alice can check who left a mess last. + console (which only Alyssa has access to) takes note of the associated + name, so Alyssa can check who left a mess last. You may have noticed that as we went further in the examples, the ability to construct such rich capabilities on the fly seemed less @@ -912,8 +912,8 @@ whenever we need them... authority can be handed over "just in time". This is less surprising if we consider the way passing around ocap references resembles the way people develop social relationships. -If Alice knows Bob and Alice knows Carol, Alice might decide it is -useful to introduce Bob to Carol. +If Alyssa knows Ben and Alyssa knows Carol, Alyssa might decide it is +useful to introduce Ben to Carol. We see this all the time with the way people exchange phone numbers today. "Oh, you really ought to meet Carol! Hold on, let me give you her @@ -935,8 +935,8 @@ transaction infrastructure, can be modeled on ocaps). In this paper "Granovetter Diagrams" such as the above are introduced, showing how ocaps flow through a system by social introductions. In fact the above diagram is pretty much exactly the same as our phone -number exchange... "Alice is sending Bob the message =foo=, which -contains a reference to Carol, and now Bob has been introduced to / +number exchange... "Alyssa is sending Ben the message =foo=, which +contains a reference to Carol, and now Ben has been introduced to / has access to Carol." It turns out that Granovetter Diagrams have their origin in sociology, @@ -1209,7 +1209,7 @@ How about the rest? It turns out that one abstraction gives us all the power we need: simple, humble, everyday proxies. -Let's say Alice has a file on a file storage server corresponding to a +Let's say Alyssa has a file on a file storage server corresponding to a list of people she would like to invite to a party. It is going to be an enormous birthday bash, so she decides she needs to keep track of the participants: @@ -1227,12 +1227,12 @@ This file object can accept any of the following two methods: - *=READ=*: Allows you to see who is currently on the list. - *=WRITE=*: Allows you to completely replace the file. -Alyssa would like to give Bob, Carol, and Lem access to see who is +Alyssa would like to give Ben, Carol, and Lem access to see who is on the list, but not to modify the list. "If you want someone added to the list, you can call me up and ask me to add them, but for now I'll just give you read access." -She makes separate read-only capabilities to give to Bob and Carol. +She makes separate read-only capabilities to give to Ben and Carol. These have the following addresses: : # aka @@ -1240,11 +1240,11 @@ These have the following addresses: : # aka : https://filestore.example/obj/DV9E9-jJaX7wFXtQuRMl1m_91d502cv-_5LX8F-GTn8 -She hands these out to Bob and Carol respectively. +She hands these out to Ben and Carol respectively. -Now Bob tries making a =READ= request against ==. +Now Ben tries making a =READ= request against ==. It works! -Bob sees that one of his friends isn't on the list yet, so he tries +Ben sees that one of his friends isn't on the list yet, so he tries to =WRITE= a new copy of the file that has them listed. Except that this time it throws an error. How? @@ -1258,15 +1258,15 @@ Due to the nature of object capabilities, this works! Proxies turned out to be all that was necessary to add this restriction on use. -Bob calls up Alice and tells her that he appreciates that she wants to +Ben calls up Alyssa and tells her that he appreciates that she wants to maintain the list, but he has a lot of ideas for people to add, couldn't he please write to the file? -Alice decides that she completely trusts Bob to add new people to the list +Alyssa decides that she completely trusts Ben to add new people to the list but he has a bad habit of highlighting text while reading it and accidentally deleting information. But adding lines? That seems ok. -Alice makes a new proxy to give to Bob: +Alyssa makes a new proxy to give to Ben: : # aka : https://filestore.example/obj/VhCCn5LjHKhDny50BIwCU8joyUgKyFIursNhfSgl1SY @@ -1274,15 +1274,15 @@ Alice makes a new proxy to give to Bob: This new proxy has a =READ= method along with a brand new method that didn't even exist on the original object called =APPEND= which accepts as an argument a single line to add to the file. -It was easy for Alice to build this: =APPEND= first does a =READ= against +It was easy for Alyssa to build this: =APPEND= first does a =READ= against ==, adds the line to those contents, and does a =WRITE= of the new version. -Now Bob can =APPEND= as many guests as he wants, but there's no risk of +Now Ben can =APPEND= as many guests as he wants, but there's no risk of him deleting the current attendees. -Carol hears of Bob's ability to append guests and is jealous. -She calls up Alice and says, can't I get access to =APPEND= also? -Alice trusts Bob to keep the number of guests he added within reason +Carol hears of Ben's ability to append guests and is jealous. +She calls up Alyssa and says, can't I get access to =APPEND= also? +Alyssa trusts Ben to keep the number of guests he added within reason but she's not so sure about Carol. She decides to make a new capability to give to Carol: @@ -1290,7 +1290,7 @@ She decides to make a new capability to give to Carol: : https://filestore.example/obj/NSgn-DCUlbpe7DWTWipF92K09WFdfknYCpJnal0SgoQ This supports the same kind of =APPEND= method interface as the -== that Alice gave Bob, but it has a new +== that Alyssa gave Ben, but it has a new restriction: this version of =APPEND= keeps track of an integer, the number of guests added through that capability. Once three guests have been added, it will refuse to allow any more @@ -1303,9 +1303,9 @@ proxies just yet! **** Revocation -Alice is up working late assembling the list when she gets a call from +Alyssa is up working late assembling the list when she gets a call from Lem offering to help add people to the list. -Alice is very tired and says you know what, sure. +Alyssa is very tired and says you know what, sure. She gives Lem the capability == and goes off to bed. @@ -1313,20 +1313,20 @@ She wakes up the next morning and the file is filled with all sorts of nonsense attendees... most of them don't even have plausible sounding names! -It's so many additions that Alice knows at least that it couldn't have +It's so many additions that Alyssa knows at least that it couldn't have been Carol; there were far more than 3 additions to this file. -It must have been Bob or Lem. +It must have been Ben or Lem. She calls both up in frustration. Both swear they didn't do it! -Alice decides she doesn't have patience or time for this nonsense and +Alyssa decides she doesn't have patience or time for this nonsense and decides to cut off access before things get any worse. Luckily she's well equipped to do so. We left out a detail when we mentioned the previous capabilities that -Alice handed out... each one of them has an internal switch that can +Alyssa handed out... each one of them has an internal switch that can be flipped (or, set a flag), at which point they will refuse to forward messages anymore. -And the power to flip this switch is held by Alice and Alice alone: +And the power to flip this switch is held by Alyssa and Alyssa alone: : # aka , : # has the power to set revocation flag of @@ -1335,7 +1335,7 @@ And the power to flip this switch is held by Alice and Alice alone: : # has the power to set revocation flag of : https://filestore.example/obj/trOC_8Ozfe1KxR8ZC32WcF_edk6dx3826uKslKdxvNI -Alice invokes both of them and poof! +Alyssa invokes both of them and poof! The corresponding revocation flags are set. == and == now both refuse to forward messages.