Okay, hey everybody, my name's Dave, on the CTO at Spritly Institute, and I want to talk
about capability security as it applies to CRDTs, quick show of hands, but if I say capability
security, it was hurt of that.
Okay, less than half of the room, okay.
So, great, but first, I just want to say Spritly, we're a small 501C3, US based non-profit.
We're trying to work on the next generation of decentralized web technology for the social
web.
But, I gotta go quick.
So, we have three big projects.
We have a distributed programming environment called Goblins.
We have a RPC protocol called the Object capability network or a capin.
And we like lists, and so we deliver it to the web by compiling to web assembly, and
we have a project called Hoot to do that.
And I want to talk to you about something that combines all three.
So our research focus is really on capability security, so unlike pretty much everyone else
is presented, we're not experts in CRDTs, we're newbies about CRDTs.
But I wanted to explore how capabilities can be applied to applications built with CRDTs.
So I made a local first chat application because that's what everybody does.
I think it's like the ubiquitous local first thing besides a text editor.
And so it just has multiple chat rooms, multi-users, you can have emoji reacts.
I don't show it in this, but you can do some editing of previous messages and some basic
moderation features.
It's a prototype, it's a toy.
But it works.
I need to go fast, so I won't demo, but I haven't embedded here, but I'll skip it.
So I want to make a distinction about behavior versus data.
When we talk about CRDTs, we're often talking about distributed data and how to sync
operations to all the nodes and converge on a thing.
In the list world, we have this ancient proverb to call it's code as data and data is code.
They're kind of the same thing, they're Yin and Yang, or Aboro, so they're one in the same,
they're different expressions of the same thing.
So we think about operation based CRDTs, they kind of compose both things.
Their data in the sense that these operations are message data that we then sync to all the
nodes, but then we process those operations and those perform things on an internal
state.
In that way, they're behavior and the whole appendomally log they form is data.
We have two different ways to view them.
I'm a big kind of the actor model, and we generally are, it's right, we're big proponents
of it.
Actors are about encapsulating behavior, not data.
This is a diagram of reference something on Carroll's machine being passed above from
Alice.
This is called a Granavetter diagram, but like actors are cool, they're great for distributed
systems, and from the actor perspective, I can further abstract and think of CRDTs as kind
of abstract actors.
We have Alice Bob and Carroll here, they're participating in a chat room, the each have their
own replica, but as an abstract concept, we can put a dotted line around all of them and
think about all the replicas put together a form like one conceptual notion of the chat room,
but the chat room does not exist in any one location.
We got problems to solve with any system, we have access control, and I want to put the security
problems into two categories, I'll try to summarize with these questions, so there's
two questions I want to answer.
Firstly, who can push operations to someone's replica, I see Finton there, what gives
me the ability to push CRDT operations to your machine, and then application level security
concerns like who could edit a message in the chat room, like who's allowed to moderate,
and my experience with this prototype, I think each problem requires a different solution.
So firstly, I just want to make an assertion that I'm going fast here, I'm just infodumping.
ACLs, like user group-based access control, excuse me, I think they're insufficient, they're
vulnerable to things like confused deputy attacks, which I can't explain, but if you know
that term, great.
The privileges are typically very coarse-grained, you know, chat application might have
like admins, moderators, like regular, unprivileged users, but they're very coarse,
the set of, you don't really get the principle of least authority with them, and further
more, granting privileged requires admin intervention, like the moderator and the regular
users, they can't delegate any of the authority to someone else, they have to go through
the admin, they say, hey, I added this person to check, can you make them a moderator?
And so in that sense, the authority is centralized, even if the system is distributed.
So there's great paper called ACLs don't, so if you want to read more about the problems
of ACLs, great paper to look at, so capabilities do what Nintendo, I mean, what ACLs
don't.
So there's no ambient authority, and so we have an adage, if you don't have it, you can't
use it, you have to hold a reference to something in order to send a message to it,
to invoke it, to have some kind of unforgeable, unguessable token to refer to a resource
remoder otherwise.
The privileges are very fine-grained, I can talk, like maybe on a resource level, this
is a read-only capability for this particular resource, I'm not saying I'm a moderator
of an entire chat room, I can have a capability that says, I can only emoji react to
Finton's message, I don't know why I keep using you, but I just met you, so, you know,
in a certain sense, it could be very fine-grained, so we can, we can actually practically
implement the principle at least authority in practice.
And so the big thing, though, is that we get delegation of privilege without admin intervention,
so we've decentralized the authority, and that's the key, that's the key bit, this is
why I'm trying to advocate the capability security model in the local first space.
So capabilities come in many, many flavors, I want to shout out key hive, I don't know
if anyone did that talk is there, thank you there, but they're working on something
called convergent capabilities, and I don't understand what they're doing yet, and I miss
their talk, and I have much to learn, but they're working in a similar space, I'm going
to kind of go with the things that are more well-understood in the capability world right
now, so object capabilities and authorization capabilities, and so I needed to use both
to make a local first chat application.
So basically, the lowest level, we have object capabilities, these are for online uses, when
when my machine and your machine have an active connection to each other, to transmit
information, on top of which we can build the actor model, on top of which we can put
CRDTs, and finally, which are allow offline messaging, so we can eventually consistent, you
know, you know, causal order messaging, and then on the very top, we can do these things
called authorization capabilities, and they allow a form of offline access control, so
these OCAPs, they can't do the offline thing, so by composing all of these things, we
get what we want, object capabilities are behavior oriented, they're for secure RPC,
certificate capabilities, they're data oriented, there's something that we can sync across
nodes, and they're suitable for an eventually consistent context.
So real quick, OCAPs are online access control through reference passing, with those
unforgible, unguessable identifiers, and importantly, they're opaque references to local
or remote actors, you have to send a message to them to know anything about them, you
can't inherently introspect them on their own.
So in RACIC CHAP, we use OCAPs by, you know, Alice invites Bob by sharing a no-cap with
them, that capability grants, Bob, the privilege to push CRDT operations to Alice, but
that capability is for Bob, and it can be revoked by Alice, if Bob ever is abusive with
it, and furthermore, capabilities can be delegated, Bob could delegate that capability
to Carol, but ultimately, that capability was granted to Bob, and Alice has a means to
hold Bob accountable for anything done with that capability.
So it's a system of consent that can be revoked.
To do OCAPs over the network, we use the object capability network, which is the standard
working on.
We can share capabilities out of band as you arise, and I'm going to skip the rest of
this, but it's a transport medium, agnostic, but I got to keep going.
But, oh, actually, I should say, we can use this to build causal order eventually consistent
messaging.
So it's a substrate for building, say, data sync protocol for CRDT.
Certificate capabilities are just simply chains of signed certificates that originate
from some root object, and they, unlike OCAPs, they're assigned to people, which is
essentially, I take your public key, and I sign it with my public key, and I say, Bob
can use this certificate.
Bob can then make a certificate for Carol, and sign it with Bob's key, and then Carol
has a certificate that she can use.
So through this, each link in the chain can expand, or, sorry, reduce privilege, but not
expand it, and unlike OCAPs, only the people that they're assigned for can use it.
And again, they're data, so we can put them, say, and what I did with the cat prototype,
put them in a set CRDT, and I sync them.
So that's how all the authorization capabilities get synced, and I'm going to wrap up real
quick.
Anyway, it's based on a spec called ZKAPLD.
So ZKAPs, they're content addressed.
Each CRDT operation, importantly signed by its authors, key, also content addressed, and
refers to a ZKAP.
And by processing those at the client, on the client side, I know if an operation is valid
to be shown to the user or not.
If Bob tried to edit a message, but doesn't possess a ZKAP that allows editing messages,
it's an invalid operation.
It was valid in terms of being an operation that could write, be written to the CRDT, but
it's not valid in terms of the application logic, so we can say, nope, I'm going to ignore
that one.
And this paper by Martin Klutman was critical to me to do anything.
So if you want to read that, it's great.
Yep, and I explained that, and so I'll just say, in summary, I think capability security
composes very well with CRDTs.
Build your CRDT protocols on Ocaps, and then use something like certificate capabilities
or key hive to do the things on top.
And yeah, that's it, I have a blog post, but that's all, thank you, I gotta go.