Add attenuation and revocation to proxying section

This commit is contained in:
Christopher Lemmer Webber 2019-07-26 17:18:05 -04:00
parent 2db8321793
commit 4e7adae88f
No known key found for this signature in database
GPG Key ID: 4BC025925FF8F4D3

View File

@ -1182,7 +1182,7 @@ Here's the interesting aspects of this:
just revoke the capability. just revoke the capability.
- As said before, the capability Alyssa has here only allows her to - As said before, the capability Alyssa has here only allows her to
post messages, not do moderation. post messages, not do moderation.
- Each subscriber on the group has given the group a specific - !Each subscriber on the group has given the group a specific
capability for their subscription. That means that the messages capability for their subscription. That means that the messages
should go through to them "for free" unless the user explicitly should go through to them "for free" unless the user explicitly
chose to revoke the capability (but they probably would have chose to revoke the capability (but they probably would have
@ -1206,6 +1206,147 @@ How about the rest?
*** The power of proxying *** The power of proxying
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
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:
: # aka <PARTY-FILE>
: https://filestore.example/obj/30SVLFRf1cTPNnjgaJfN8r85joIMVDSgWSKXKoYiFuY
Now she wants to collaborate with her friends about who can come to
the party.
**** Attenuation
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
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.
These have the following addresses:
: # aka <PARTY-FILE-READ-ONLY-1>
: https://filestore.example/obj/lRDWPHOvcbCrRsHc36ZeRcsIpDsunVFtwK3yxD1kH0c
: # aka <PARTY-FILE-READ-ONLY-2>
: https://filestore.example/obj/DV9E9-jJaX7wFXtQuRMl1m_91d502cv-_5LX8F-GTn8
She hands these out to Bob and Carol respectively.
Now Bob tries making a =READ= request against =<PARTY-FILE-READ-ONLY-1>=.
It works!
Bob 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?
As you may have guessed, =<PARTY-FILE-READ-ONLY-1>= is a proxy.
It knows where =<PARTY-FILE>= is, but does not share that information.
Instead, it forwards requests.
However, it only forwards requests for =READ=; any call to any other
method throws an error.
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
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
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:
: # aka <PARTY-FILE-READ-AND-APPEND-1>
: https://filestore.example/obj/VhCCn5LjHKhDny50BIwCU8joyUgKyFIursNhfSgl1SY
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
=<PARTY-FILE>=, 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
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
but she's not so sure about Carol.
She decides to make a new capability to give to Carol:
: # aka <PARTY-FILE-READ-AND-APPEND-A-FEW-1>
: https://filestore.example/obj/NSgn-DCUlbpe7DWTWipF92K09WFdfknYCpJnal0SgoQ
This supports the same kind of =APPEND= method interface as the
=<PARTY-FILE-READ-AND-APPEND-1>= that Alice gave Bob, 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
guests; any further calls to =APPEND= will throw an error.
It is amazing to consider that these powerful restrictions were able to
be added through proxying alone.
But we're not done exploring the interesting things we can do through
proxies just yet!
**** Revocation
Alice 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.
She gives Lem the capability =<PARTY-FILE-READ-AND-APPEND-2>= and goes
off to bed.
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
been Carol; there were far more than 3 additions to this file.
It must have been Bob 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
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
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:
: # aka <REVOKE-PARTY-FILE-READ-AND-APPEND-1>,
: # has the power to set revocation flag of <PARTY-FILE-READ-AND-APPEND-1>
: https://filestore.example/obj/m2nRsjIPdUAl7puFR2tf6GnpGBhEF3KB3QXEWvRNVQQ
: # aka <REVOKE-PARTY-FILE-READ-AND-APPEND-2>
: # has the power to set revocation flag of <PARTY-FILE-READ-AND-APPEND-2>
: https://filestore.example/obj/trOC_8Ozfe1KxR8ZC32WcF_edk6dx3826uKslKdxvNI
Alice invokes both of them and poof!
The corresponding revocation flags are set.
=<PARTY-FILE-READ-AND-APPEND-1>= and =<PARTY-FILE-READ-AND-APPEND-2>=
now both refuse to forward messages.
**** Accountability
**** Composition
decides that she would like to let all of the
co-organizers
*** True names, public profiles, private profiles *** True names, public profiles, private profiles