WEBVTT 00:00.000 --> 00:10.600 Okay, hey everybody, my name's Dave, on the CTO at Spritly Institute, and I want to talk 00:10.600 --> 00:15.680 about capability security as it applies to CRDTs, quick show of hands, but if I say capability 00:15.680 --> 00:18.000 security, it was hurt of that. 00:18.000 --> 00:20.200 Okay, less than half of the room, okay. 00:20.200 --> 00:25.960 So, great, but first, I just want to say Spritly, we're a small 501C3, US based non-profit. 00:25.960 --> 00:31.920 We're trying to work on the next generation of decentralized web technology for the social 00:31.920 --> 00:32.920 web. 00:32.920 --> 00:35.120 But, I gotta go quick. 00:35.120 --> 00:36.920 So, we have three big projects. 00:36.920 --> 00:39.080 We have a distributed programming environment called Goblins. 00:39.080 --> 00:43.600 We have a RPC protocol called the Object capability network or a capin. 00:43.600 --> 00:48.120 And we like lists, and so we deliver it to the web by compiling to web assembly, and 00:48.120 --> 00:50.560 we have a project called Hoot to do that. 00:50.560 --> 00:53.440 And I want to talk to you about something that combines all three. 00:53.440 --> 00:58.000 So our research focus is really on capability security, so unlike pretty much everyone else 00:58.000 --> 01:03.280 is presented, we're not experts in CRDTs, we're newbies about CRDTs. 01:03.280 --> 01:10.160 But I wanted to explore how capabilities can be applied to applications built with CRDTs. 01:10.160 --> 01:15.160 So I made a local first chat application because that's what everybody does. 01:15.160 --> 01:19.480 I think it's like the ubiquitous local first thing besides a text editor. 01:19.480 --> 01:24.560 And so it just has multiple chat rooms, multi-users, you can have emoji reacts. 01:24.560 --> 01:29.720 I don't show it in this, but you can do some editing of previous messages and some basic 01:29.720 --> 01:30.720 moderation features. 01:30.720 --> 01:32.720 It's a prototype, it's a toy. 01:32.720 --> 01:33.720 But it works. 01:33.720 --> 01:38.800 I need to go fast, so I won't demo, but I haven't embedded here, but I'll skip it. 01:38.800 --> 01:42.680 So I want to make a distinction about behavior versus data. 01:42.680 --> 01:47.200 When we talk about CRDTs, we're often talking about distributed data and how to sync 01:47.200 --> 01:52.080 operations to all the nodes and converge on a thing. 01:52.080 --> 01:56.440 In the list world, we have this ancient proverb to call it's code as data and data is code. 01:56.440 --> 02:01.640 They're kind of the same thing, they're Yin and Yang, or Aboro, so they're one in the same, 02:01.640 --> 02:04.120 they're different expressions of the same thing. 02:04.120 --> 02:08.560 So we think about operation based CRDTs, they kind of compose both things. 02:08.560 --> 02:13.640 Their data in the sense that these operations are message data that we then sync to all the 02:13.640 --> 02:20.280 nodes, but then we process those operations and those perform things on an internal 02:20.280 --> 02:21.280 state. 02:21.280 --> 02:26.200 In that way, they're behavior and the whole appendomally log they form is data. 02:26.200 --> 02:29.480 We have two different ways to view them. 02:29.480 --> 02:33.360 I'm a big kind of the actor model, and we generally are, it's right, we're big proponents 02:33.360 --> 02:34.360 of it. 02:34.360 --> 02:37.280 Actors are about encapsulating behavior, not data. 02:37.280 --> 02:42.400 This is a diagram of reference something on Carroll's machine being passed above from 02:42.400 --> 02:43.400 Alice. 02:43.400 --> 02:47.600 This is called a Granavetter diagram, but like actors are cool, they're great for distributed 02:47.600 --> 02:55.360 systems, and from the actor perspective, I can further abstract and think of CRDTs as kind 02:55.360 --> 02:56.360 of abstract actors. 02:56.360 --> 03:00.160 We have Alice Bob and Carroll here, they're participating in a chat room, the each have their 03:00.160 --> 03:05.880 own replica, but as an abstract concept, we can put a dotted line around all of them and 03:05.880 --> 03:11.960 think about all the replicas put together a form like one conceptual notion of the chat room, 03:11.960 --> 03:18.280 but the chat room does not exist in any one location. 03:18.280 --> 03:23.040 We got problems to solve with any system, we have access control, and I want to put the security 03:23.040 --> 03:27.040 problems into two categories, I'll try to summarize with these questions, so there's 03:27.040 --> 03:28.840 two questions I want to answer. 03:28.840 --> 03:34.920 Firstly, who can push operations to someone's replica, I see Finton there, what gives 03:34.920 --> 03:39.800 me the ability to push CRDT operations to your machine, and then application level security 03:39.800 --> 03:44.360 concerns like who could edit a message in the chat room, like who's allowed to moderate, 03:44.360 --> 03:49.960 and my experience with this prototype, I think each problem requires a different solution. 03:49.960 --> 03:54.600 So firstly, I just want to make an assertion that I'm going fast here, I'm just infodumping. 03:54.600 --> 04:00.740 ACLs, like user group-based access control, excuse me, I think they're insufficient, they're 04:00.740 --> 04:04.240 vulnerable to things like confused deputy attacks, which I can't explain, but if you know 04:04.240 --> 04:06.080 that term, great. 04:06.080 --> 04:09.560 The privileges are typically very coarse-grained, you know, chat application might have 04:09.560 --> 04:15.800 like admins, moderators, like regular, unprivileged users, but they're very coarse, 04:15.800 --> 04:21.760 the set of, you don't really get the principle of least authority with them, and further 04:21.760 --> 04:25.740 more, granting privileged requires admin intervention, like the moderator and the regular 04:25.740 --> 04:28.920 users, they can't delegate any of the authority to someone else, they have to go through 04:28.920 --> 04:32.240 the admin, they say, hey, I added this person to check, can you make them a moderator? 04:32.720 --> 04:39.000 And so in that sense, the authority is centralized, even if the system is distributed. 04:39.000 --> 04:42.800 So there's great paper called ACLs don't, so if you want to read more about the problems 04:42.800 --> 04:49.540 of ACLs, great paper to look at, so capabilities do what Nintendo, I mean, what ACLs 04:49.540 --> 04:50.840 don't. 04:50.840 --> 04:54.280 So there's no ambient authority, and so we have an adage, if you don't have it, you can't 04:54.280 --> 04:59.080 use it, you have to hold a reference to something in order to send a message to it, 04:59.080 --> 05:05.280 to invoke it, to have some kind of unforgeable, unguessable token to refer to a resource 05:05.280 --> 05:06.600 remoder otherwise. 05:06.600 --> 05:11.280 The privileges are very fine-grained, I can talk, like maybe on a resource level, this 05:11.280 --> 05:15.480 is a read-only capability for this particular resource, I'm not saying I'm a moderator 05:15.480 --> 05:20.400 of an entire chat room, I can have a capability that says, I can only emoji react to 05:20.400 --> 05:24.800 Finton's message, I don't know why I keep using you, but I just met you, so, you know, 05:24.800 --> 05:27.600 in a certain sense, it could be very fine-grained, so we can, we can actually practically 05:27.600 --> 05:31.320 implement the principle at least authority in practice. 05:31.320 --> 05:35.680 And so the big thing, though, is that we get delegation of privilege without admin intervention, 05:35.680 --> 05:40.680 so we've decentralized the authority, and that's the key, that's the key bit, this is 05:40.680 --> 05:45.000 why I'm trying to advocate the capability security model in the local first space. 05:45.000 --> 05:49.800 So capabilities come in many, many flavors, I want to shout out key hive, I don't know 05:49.800 --> 05:54.280 if anyone did that talk is there, thank you there, but they're working on something 05:54.280 --> 05:57.600 called convergent capabilities, and I don't understand what they're doing yet, and I miss 05:57.600 --> 06:01.280 their talk, and I have much to learn, but they're working in a similar space, I'm going 06:01.280 --> 06:05.920 to kind of go with the things that are more well-understood in the capability world right 06:05.920 --> 06:10.800 now, so object capabilities and authorization capabilities, and so I needed to use both 06:10.800 --> 06:12.800 to make a local first chat application. 06:12.800 --> 06:18.240 So basically, the lowest level, we have object capabilities, these are for online uses, when 06:18.240 --> 06:23.880 when my machine and your machine have an active connection to each other, to transmit 06:23.880 --> 06:29.240 information, on top of which we can build the actor model, on top of which we can put 06:29.240 --> 06:34.520 CRDTs, and finally, which are allow offline messaging, so we can eventually consistent, you 06:34.520 --> 06:38.320 know, you know, causal order messaging, and then on the very top, we can do these things 06:38.320 --> 06:42.720 called authorization capabilities, and they allow a form of offline access control, so 06:42.720 --> 06:48.240 these OCAPs, they can't do the offline thing, so by composing all of these things, we 06:48.240 --> 06:52.600 get what we want, object capabilities are behavior oriented, they're for secure RPC, 06:52.600 --> 06:55.960 certificate capabilities, they're data oriented, there's something that we can sync across 06:55.960 --> 07:01.160 nodes, and they're suitable for an eventually consistent context. 07:01.160 --> 07:06.560 So real quick, OCAPs are online access control through reference passing, with those 07:06.560 --> 07:11.800 unforgible, unguessable identifiers, and importantly, they're opaque references to local 07:11.800 --> 07:15.920 or remote actors, you have to send a message to them to know anything about them, you 07:15.920 --> 07:19.400 can't inherently introspect them on their own. 07:19.400 --> 07:25.160 So in RACIC CHAP, we use OCAPs by, you know, Alice invites Bob by sharing a no-cap with 07:25.160 --> 07:31.280 them, that capability grants, Bob, the privilege to push CRDT operations to Alice, but 07:31.280 --> 07:37.800 that capability is for Bob, and it can be revoked by Alice, if Bob ever is abusive with 07:37.800 --> 07:42.400 it, and furthermore, capabilities can be delegated, Bob could delegate that capability 07:42.400 --> 07:46.880 to Carol, but ultimately, that capability was granted to Bob, and Alice has a means to 07:46.880 --> 07:49.760 hold Bob accountable for anything done with that capability. 07:49.760 --> 07:55.000 So it's a system of consent that can be revoked. 07:55.000 --> 07:58.880 To do OCAPs over the network, we use the object capability network, which is the standard 07:58.880 --> 08:00.280 working on. 08:00.280 --> 08:04.240 We can share capabilities out of band as you arise, and I'm going to skip the rest of 08:04.240 --> 08:07.560 this, but it's a transport medium, agnostic, but I got to keep going. 08:07.560 --> 08:13.160 But, oh, actually, I should say, we can use this to build causal order eventually consistent 08:13.160 --> 08:14.160 messaging. 08:14.160 --> 08:18.840 So it's a substrate for building, say, data sync protocol for CRDT. 08:18.840 --> 08:24.360 Certificate capabilities are just simply chains of signed certificates that originate 08:24.360 --> 08:30.200 from some root object, and they, unlike OCAPs, they're assigned to people, which is 08:30.200 --> 08:36.440 essentially, I take your public key, and I sign it with my public key, and I say, Bob 08:36.440 --> 08:38.160 can use this certificate. 08:38.200 --> 08:43.320 Bob can then make a certificate for Carol, and sign it with Bob's key, and then Carol 08:43.320 --> 08:46.000 has a certificate that she can use. 08:46.000 --> 08:52.120 So through this, each link in the chain can expand, or, sorry, reduce privilege, but not 08:52.120 --> 08:57.400 expand it, and unlike OCAPs, only the people that they're assigned for can use it. 08:57.400 --> 09:02.600 And again, they're data, so we can put them, say, and what I did with the cat prototype, 09:02.600 --> 09:04.400 put them in a set CRDT, and I sync them. 09:04.400 --> 09:08.680 So that's how all the authorization capabilities get synced, and I'm going to wrap up real 09:08.680 --> 09:09.680 quick. 09:09.680 --> 09:12.680 Anyway, it's based on a spec called ZKAPLD. 09:12.680 --> 09:15.000 So ZKAPs, they're content addressed. 09:15.000 --> 09:19.640 Each CRDT operation, importantly signed by its authors, key, also content addressed, and 09:19.640 --> 09:21.120 refers to a ZKAP. 09:21.120 --> 09:26.880 And by processing those at the client, on the client side, I know if an operation is valid 09:26.880 --> 09:28.160 to be shown to the user or not. 09:28.160 --> 09:33.320 If Bob tried to edit a message, but doesn't possess a ZKAP that allows editing messages, 09:33.320 --> 09:34.320 it's an invalid operation. 09:34.320 --> 09:38.800 It was valid in terms of being an operation that could write, be written to the CRDT, but 09:38.800 --> 09:42.080 it's not valid in terms of the application logic, so we can say, nope, I'm going to ignore 09:42.080 --> 09:44.440 that one. 09:44.440 --> 09:47.880 And this paper by Martin Klutman was critical to me to do anything. 09:47.880 --> 09:50.720 So if you want to read that, it's great. 09:50.720 --> 09:55.560 Yep, and I explained that, and so I'll just say, in summary, I think capability security 09:55.560 --> 09:58.400 composes very well with CRDTs. 09:58.400 --> 10:04.640 Build your CRDT protocols on Ocaps, and then use something like certificate capabilities 10:04.640 --> 10:09.520 or key hive to do the things on top. 10:09.520 --> 10:13.760 And yeah, that's it, I have a blog post, but that's all, thank you, I gotta go.