WEBVTT 00:00.000 --> 00:15.600 So the web and society are under attack, rather than being a tool for empowering people, improving 00:15.600 --> 00:21.720 lives and protecting democracy, it's evolved into a system for surveillance, control, and 00:21.720 --> 00:24.720 coercion. 00:24.720 --> 00:28.520 I believe that we can fix some of these problems with a better foundation. 00:28.520 --> 00:33.360 So surveillance, you can get most of the way there with end-to-end encryption. 00:33.360 --> 00:35.120 Control tends to come in two kinds. 00:35.120 --> 00:40.480 You've got holding a data hostage and holding your identity hostage. 00:40.480 --> 00:46.120 You can solve those with host-independent data and use a controlled identity. 00:46.120 --> 00:50.800 And then the rest of surveillance, there's a long tale of metadata, including things 00:50.800 --> 00:53.200 like the social graph. 00:53.200 --> 00:59.520 So these were the design goals we had building the pigus protocol. 00:59.520 --> 01:04.680 So what it is, it's a global, end-to-end encrypted social file system. 01:04.680 --> 01:10.360 There's fine-grained access, control to individual files or entire directories, everything 01:10.360 --> 01:13.160 signed and content addressed. 01:13.160 --> 01:19.440 You can automatically move hosts and preserve all your links that everything just works. 01:19.440 --> 01:26.440 And there's a sandbox for running applications or websites in a fun way and, of course, 01:26.440 --> 01:28.800 use a controlled identity. 01:28.800 --> 01:33.440 The model we have is the server, is an adversary, a current adversary. 01:33.440 --> 01:41.080 So everyone has a home server and all data is content addressed, all updates are signed, 01:41.080 --> 01:43.160 and we layer on top of that into end-to-end encryption. 01:43.160 --> 01:51.240 So that gives you your location independent addressing and so your host's mobility. 01:51.240 --> 01:56.440 As far as the user's data actually goes, they have a tree of key pairs. 01:56.440 --> 02:00.000 Each key pair can own any number of other key pairs. 02:00.000 --> 02:05.840 And that ownership relationship is proved with a mutual signature, and that comes from 02:05.840 --> 02:10.480 a single root key which is your identity key pair. 02:10.480 --> 02:17.080 If we lay these out each key pair controls a writing subspace, we call it a mutual 02:17.080 --> 02:18.080 space. 02:18.080 --> 02:23.080 And each of those has a single circle tree associated with it. 02:23.080 --> 02:27.600 Now what is the structure of these circle trees? 02:27.600 --> 02:34.440 It's basically a thing called a champ, so this is a compressed hasharray mapped prefix 02:34.440 --> 02:35.440 try. 02:35.760 --> 02:38.280 You can think of it as a key value store. 02:38.280 --> 02:40.560 It has some nice properties. 02:40.560 --> 02:45.760 So it's independent of insertion order and like a beetry and it's balanced. 02:45.760 --> 02:50.000 If you've had anything to do with AT Prodo, you might have heard of MST's. 02:50.000 --> 02:56.240 MST is the sorted sister data structure of a champ, and it's used in a lot of places 02:56.240 --> 03:02.120 in functional languages like Scarler for collections and maps. 03:02.120 --> 03:09.880 The way we use it, the keys are all 32 random bytes, and the values are cryptary nodes 03:09.880 --> 03:13.320 or encrypted metadata, which we'll see more about. 03:13.320 --> 03:19.040 Each of those, each cryptary node can link to up to five encrypted blocks. 03:19.040 --> 03:21.240 Each of those is up to one megabyte. 03:21.240 --> 03:26.680 So you end up with this kind of granularity for every champ mapping corresponds to up to 03:26.680 --> 03:29.760 five megabytes of data. 03:29.840 --> 03:36.080 The idea is different mappings in the champ can't be linked by your server or anyone who 03:36.080 --> 03:43.760 has access to all the data, so that's how we can hide the file size, at least the absolute 03:43.760 --> 03:50.360 size, and then within a chunk we also pad to a multiple of 4k to further obscure the file 03:50.360 --> 03:51.360 size. 03:51.360 --> 03:57.520 In terms of other metadata, whether something is whether a particular chunk is a file or a 03:57.520 --> 04:03.440 directory, the server can't tell, because the format is the same, and things like the 04:03.440 --> 04:09.880 obviously things like the files and folder names or other metadata, like mind types, creation 04:09.880 --> 04:18.720 date, the folder topology, is not visible, and also the social graph, so who or even how 04:18.720 --> 04:26.520 many people have access to a particular file or blob, which brings us to access control. 04:26.520 --> 04:37.120 So to access a particular cryptary node or chunk, you need a capability, so what's a capability? 04:37.120 --> 04:43.760 It's pure information, people from Sparkly will say you either have it or you don't, 04:43.760 --> 04:49.320 that's a good description, it's not identity based, and because it's pure information, it 04:49.320 --> 04:53.680 can work in things like secret links, if you want, and you can revoke them by essentially 04:53.680 --> 04:55.520 rotating the keys. 04:55.520 --> 05:00.160 So in our setup, there are three different kinds of capabilities, there's a mirror cap, 05:00.160 --> 05:02.560 a read cap, and a right cap. 05:02.560 --> 05:08.480 So the mirror capabilities just can I retrieve the ciphertext for this thing at all, and that 05:08.480 --> 05:13.040 has four components, there's first two of public keys, there's the owner public key and 05:13.040 --> 05:20.000 the writer public key, the owner is basically used for routing to your server, and the 05:20.000 --> 05:23.280 writer is the thing that controls the writing space that you're actually trying to get 05:23.280 --> 05:24.800 the data from. 05:24.800 --> 05:31.080 The map keys is just to look up key into the, into the champ, and the bat stands for block 05:31.080 --> 05:33.960 access token, it's basically 32 bytes. 05:33.960 --> 05:41.680 You can think of it as a baratoken for that particular chunk or block, and so with a, with 05:41.680 --> 05:47.640 a mirror cap, you can then ask the server, give me this crypt, encrypted cryptary node, and 05:47.640 --> 05:53.000 it'll give it to you if the bats write, and then if you have a symmetric read key in 05:53.000 --> 05:57.480 addition, then you can decrypt it, and you can read it. 05:57.480 --> 06:03.520 If you have an addition to that, a symmetric write key, then you can then modify that, 06:03.520 --> 06:08.240 that file or folder as well. 06:08.240 --> 06:13.080 The read keys are controlled with a structure called cryptary, so basically every file 06:13.080 --> 06:20.520 or directory has two symmetric keys associated to it, but this diagram, the idea is if 06:20.600 --> 06:27.240 you have one of these keys, you can follow the links in this picture by decrypting things 06:27.240 --> 06:29.400 in the cryptary nodes. 06:29.400 --> 06:33.080 So if you have the base key for a directory, then you can decrypt all the capabilities 06:33.080 --> 06:36.920 in that directory and seal the children, and so on. 06:36.920 --> 06:41.200 You might notice these, these back links from the parent keys. 06:41.200 --> 06:45.240 That's essentially to give everything a well-defined path, so if I can give you a read 06:45.240 --> 06:54.800 cap to a file, and that file still has a well-defined path in the system. 06:54.800 --> 07:01.440 The write cryptary is a lot simpler, it's just one symmetric key for everything, and if 07:01.440 --> 07:08.640 you have that, then you can decrypt the signing key pair for that appropriate thing, and 07:08.640 --> 07:11.600 modify some stuff. 07:11.600 --> 07:18.600 So we've talked about capabilities for individual chunks, but what about we said they're 07:18.600 --> 07:24.400 the different chunks, so how do we get to read the rest of a file, say, if we're trying 07:24.400 --> 07:26.280 to watch a movie or something? 07:26.280 --> 07:32.640 So the owner and the writer are the same, for a given file, and the read key and the 07:32.640 --> 07:37.200 right key are also the same, so things that change are obviously the keys in the champ, 07:37.240 --> 07:41.680 the map keys, and the baratocans, the best. 07:41.680 --> 07:47.880 So if you have the capability to the start of a file, to get to the next one, you just 07:47.880 --> 07:54.560 hash the current map key with a think called the stream secret, which is that stored in 07:54.560 --> 07:58.680 the encrypted metadata in the first chunks, so you decrypt it, get the stream secret, and 07:58.680 --> 08:02.680 then hash it, and the same thing for the back, and then you've got the code related to 08:02.760 --> 08:09.760 the next chunk, and you can continue doing on, going on like that, and so to seek forward, 08:09.760 --> 08:14.560 you don't actually have to do any IO at all, you just do this hashing locally, get 08:14.560 --> 08:20.800 the final capability, and then just ask for the data, so it's O of 1 in IO to seek 08:20.800 --> 08:29.800 in an arbitrarily large file, so that brings us to the first demo, let's pray to the demo 08:30.040 --> 08:42.760 and see if that will work on the internet here, and see that? Yeah, alright, where are we? 08:42.760 --> 08:51.760 Over here, so this is just a bunch of videos, so this movie is about 120 megs, not enormous, 08:51.760 --> 09:00.720 but it's not tiny either, yeah, so you can see, it's already buffed quite a lot, but 09:00.720 --> 09:06.360 I'll skip ahead of that, there's no sound because there sounds off, but that doesn't matter, 09:06.360 --> 09:12.720 and you can see you can see you can see you head pretty quickly, you can also seek backwards, 09:12.720 --> 09:18.720 and that's relatively fast, if you're wondering how we do that, we don't do anything 09:18.720 --> 09:22.480 clever there, we just keep the pointer to the start of the file, so you're always hashing 09:22.480 --> 09:36.400 forward, because you can't invert a hash, cool, last time I did that demo, didn't work, so I'm 09:36.400 --> 09:44.520 pleased about that, right, so yeah, so this gives us a file system, cool, but that's not 09:44.560 --> 09:54.440 a web, a web has websites and web apps, so we need a way to do that, so a way for that is we 09:54.440 --> 10:03.480 have a sandbox to run anything, run an application or view a website, and the idea is it's 10:03.480 --> 10:08.080 locked down so that it can't communicate to the external world, and so you could then run 10:08.160 --> 10:15.200 an app over private data, such that it can't steal it or infiltrate it in any way, and 10:15.200 --> 10:20.400 it also can't read anything, it's not been granted access to, and it works in existing 10:20.400 --> 10:28.480 browsers without any add-ons or extensions, and from the from the apps perspective, it's 10:28.480 --> 10:32.320 got, it thinks it's got a simple rest there, it doesn't know anything about encryption 10:32.320 --> 10:37.680 or any of that stuff, it thinks it's talking to a server, and that's happening locally with 10:37.760 --> 10:43.520 the service worker, which we'll see more in a second, so what is an application, it's just 10:43.520 --> 10:51.120 a folder of HTML, in PIGOS, because it's just a folder you can use the built-in access control, 10:52.000 --> 10:57.840 you could keep it private, or you could share it with friends, or make it public, there are 10:57.840 --> 11:02.560 some basic permissions for apps, so you can register for certain mind types, you can say I'm an 11:02.560 --> 11:08.960 image editor, or I can play music, or whatever, and you can have there's a permission for 11:09.680 --> 11:15.280 persisting data in kind of like an app-specific private folder in your space, so it's the 11:15.280 --> 11:19.920 base of the same as Android, where apps can store stuff on your phone, makes up to the ends up in PIGOS, 11:21.920 --> 11:28.880 and an app without any permissions is just a private website, this is how it works, technically, 11:28.880 --> 11:34.800 so you have the outer context on the left, which is PIGOS.net, or it could be local host, 11:34.800 --> 11:41.120 this all works on local host as well, and that's where you log in, that's where your keys are, 11:41.120 --> 11:47.840 that's the kind of trusted context, and when you run an app, it loads a random sub-domain, 11:50.000 --> 11:53.840 whether it's PIGOS.net or local host doesn't matter, and that sub-domain all it does, 11:53.840 --> 11:59.120 the service serves up the same code for all sub-domains, and that code just immediately loads 11:59.120 --> 12:06.560 a little service worker, and then tries to load itself in another sub-domain, in this or in 12:06.560 --> 12:13.200 another I-frame, and that I-frame is where the app itself ends up, so all the requests the app 12:13.200 --> 12:19.760 makes get intercepted by the service worker, and the service worker translates them to post messages, 12:19.760 --> 12:25.120 which are sent back to the outer context, where they can be interpreted, and have whatever 12:25.120 --> 12:32.560 permissions applied, and then the responses are sent back, and yes, so it's done with this CSP, 12:32.560 --> 12:38.160 to lock it down, but also co-op and co-ep to try and make sure that it's a different operating 12:38.160 --> 12:46.320 system process than the outer PIGOS context to protect against side channels. So what kind of things 12:46.320 --> 12:55.360 can an app do? There's a word processor, spreadsheets, image editors, all kind of obvious things, 12:55.360 --> 12:59.600 and we haven't written all these, it's like existing web apps that we've just previously ported. 13:02.800 --> 13:08.720 Tilly wicking notebooks, marked on editor, and you don't have to rely on us to write apps, 13:08.720 --> 13:12.240 anyone can write an app, you can launch an app from a folder or show you that later. 13:12.800 --> 13:23.200 You can have a media player, one of the APIs we expose to apps is the ability to send a message 13:23.200 --> 13:29.200 to your friends or to particular friends, so using that you can build stuff like multiplayer games 13:29.200 --> 13:37.200 or chat, and you can do things like doom. So, second demo. 13:42.880 --> 13:49.120 All right, so let's see, so I'm just going to show you, so this is a word doc at DocX. 13:52.480 --> 13:56.800 There you go, so that's, this thing at the top is kind of like a trusted, this little bit like the 13:56.800 --> 14:02.320 URL bar, so that's not controlled by the app, but below that's the app rendering itself. 14:02.320 --> 14:20.320 There's an ebook reader, if you want to do some linear algebra, so there's a block-based 14:20.800 --> 14:28.480 no editor or viewer, so this is standard block-based things, you can have in-line images or 14:28.480 --> 14:36.880 late-tech or diagrams or stuff, and that was, so that was just a viewer for it, if I go edit, 14:38.480 --> 14:42.640 then you can see I get these things for adding and editing new things. 14:42.960 --> 14:50.400 So, yeah, you can give, when you open an app, you can give it read-only access to stuff, 14:51.280 --> 14:59.040 let's try and change something, halfway through that, and then it seems to work, 14:59.680 --> 15:03.920 if you open it again, there we go. All right, so that's saved. 15:04.880 --> 15:13.360 There's a PDF viewer, lots of PDFs, probably the most sandboxed PDF viewer in the world. 15:18.800 --> 15:26.080 Whoops, I didn't want to go back in there, some spreadsheets, so this is an Excel spreadsheet, 15:26.160 --> 15:38.640 there we go, there's some stuff, well that's what we've got. So this is a text editor, 15:38.640 --> 15:46.000 this is basically code mirror, so if you like your text code into an encrypted, 15:46.880 --> 15:55.600 there we go, there's a go file, can do markdown as well, so that's the markdown renderer, 15:56.960 --> 15:59.280 or if you go to edit, then that's code mirror. 15:59.280 --> 16:18.000 And so even just just raw HTML, so this is just a trivial little website, 16:18.000 --> 16:23.680 so you can see here, it just has an image referencing that in the same directory, 16:24.320 --> 16:32.800 and if I view that, then I get, this is sandboxed off, this little website thing, 16:34.320 --> 16:38.720 and yeah, in this case we do actually show the path up here in the sort of trusted URL bar. 16:38.720 --> 16:54.000 Oh, and you can have a full-fetched wiki, so, yeah, so that's marked down, but it can link to 16:54.960 --> 17:02.080 sub-documents, in line images, you can link to any file, and so this is a note, 17:02.800 --> 17:06.400 and it will open that in the appropriate app that you would have you have registered. 17:08.720 --> 17:21.200 And there's a calendar, basically calendar, the model there is that every event is a standard 17:21.200 --> 17:26.160 ikel file, in Pigos, each calendar is a folder, so you get the native access control that way, 17:27.200 --> 17:35.200 and you can share it with people that that way, and one last thing, 17:35.200 --> 17:48.240 so there's a search, so this is searching in a file name, so this is just searching metadata, 17:48.240 --> 17:54.320 but this is not pre-index, this is just doing it live, and you can see it's relatively quick, 17:54.400 --> 18:08.960 I can try and do a full-text search, so this is searching my space at the moment, which is 10 giga 18:08.960 --> 18:15.040 think, but you can see it's fast, and we thought we're going to have to add an index to that, 18:15.040 --> 18:19.200 but it's so far been fast enough to not have one, we might still do one one day, 18:19.200 --> 18:27.680 and yes, so you can see all the apps are personally installed in this account here, 18:29.360 --> 18:39.200 oh it's one more, so here are some example apps, the actual source code in the apps, 18:39.840 --> 18:45.520 so this is, this is doom, basically it just has an assets folder that that will just have an index 18:45.520 --> 18:52.320 HTML, and there's a manifest, it's just JSON file, and from that we can just directly run it 18:53.040 --> 19:04.960 this way in the sandbox, and then yeah, that runs, not multiplayer yet, unfortunately not doom, 19:07.120 --> 19:13.280 one day, awesome, all right, so back to the slides, 19:15.680 --> 19:25.360 right, yeah, so one thing I haven't talked about yet is the more the social side of it, 19:25.360 --> 19:32.240 so I talked about sharing, but we also have kind of a social media protocol, I guess, more of a format, 19:34.320 --> 19:40.320 but our belief is that most social media is actually bad for society, for two main reasons, 19:40.640 --> 19:47.680 because it allows micro-targeted political profiling, which can be used to swing elections and 19:47.680 --> 19:53.520 subvert democracy, and because they're designed to be addictive, but if you compare it to something 19:53.520 --> 19:59.120 like normal in-person conversations, I think these are good for society, these are how we reach 19:59.120 --> 20:05.920 consensus, they're mostly mutually consentful, and so that's how we we've tried to model 20:06.000 --> 20:13.920 those social media on in-person conversations, or meetings, and so it's like over the housing 20:13.920 --> 20:23.920 papers that's entering encrypted, a social post is just a file, and you choose the audience, 20:23.920 --> 20:31.760 so you can trip your friends or your followers or have some subsets, and if the original post 20:31.760 --> 20:37.360 wants to allow sort of increasing the audience, then that can be allowed like resharing, 20:38.240 --> 20:46.320 or you can just restrict the audience to the original audience, but yeah, so without privacy, 20:46.320 --> 20:54.160 there can be no democracy, thank you everyone, go try it out, self-host, sign up, write some apps, 20:54.160 --> 21:03.920 how do you expect questions? All right, we do have a few minutes for questions, we'll go ahead 21:03.920 --> 21:12.000 in the past room, really impressive demo, well in presentation and everything, one of the things 21:12.960 --> 21:18.560 you're very focused on kind of the, and then a new cryptid file case, if you wanted to do some sort 21:18.560 --> 21:24.800 of published subscribe or otherwise messaging system, what type of mechanism, or is it basically 21:24.800 --> 21:31.440 appalling mechanism on the encrypted data? It's basically polling, yeah, so the way the sharing and 21:31.440 --> 21:36.000 the social stuff will work is when you, when you're friends, someone, it's okay, so I haven't 21:36.000 --> 21:42.160 really talked to the details of a friending, you can send someone an encrypted follow requests, 21:43.120 --> 21:49.280 and that gives, that basically you share with them a capability to a particular file in your space, 21:49.280 --> 21:54.640 and that is your broadcast mechanism to that person, so you can just append stuff to that in your space, 21:54.640 --> 21:57.840 and then they can come and read it whenever they like, and then follow the caps elsewhere, 21:58.560 --> 22:06.960 so yeah, that's basically how about that? Over here, hi, thank you very much for your presentation 22:06.960 --> 22:12.560 and for the efforts that you put into something that feels very right. I wanted to ask you, 22:12.560 --> 22:19.920 what do you think that the audience here can do for peer-guys, like what do you think it's necessary 22:19.920 --> 22:26.160 next to step, especially regarding the targets that you have here, what can we do? 22:26.160 --> 22:33.280 I mean, try it out, use it, give us feedback, we're also, we're a non-profit, so if you want to support 22:33.280 --> 22:38.320 us, you can donate or get a paid account on our server, if you don't want to self-host, 22:42.320 --> 22:47.440 yeah, all of the above. Yeah, but also specifically targeting developers, 22:47.440 --> 22:52.000 are there works that are left, as you think, that can be like lifted up some, 22:53.840 --> 22:59.840 so you're targeting developers? Like, let's say like, would it be like, would you recommend 22:59.840 --> 23:04.080 like the developers to look at like new apps to integrate in your platform? Oh, yeah, yeah, 23:04.080 --> 23:09.280 so yeah, we'd love to have more apps, and if you want it to, we have there's a 23:10.000 --> 23:13.360 centralized install thing to make it easier for people to find me, you don't have to do that, 23:14.480 --> 23:21.600 but yeah, there's a web, is it on there? No, it's not. Well, there's a link on peer-guys that 23:21.600 --> 23:30.560 are, which goes to a book, book.pigas.org, that has the app API, so the developers to figure out 23:30.560 --> 23:35.840 what's going on. Most of it's pretty simple, there isn't any SDK, it's that simple, it's just 23:35.840 --> 23:45.360 posting or getting HTTP to a couple of inputs. Thank you, Alien. In your opinion, which is the best way 23:45.360 --> 23:55.600 a user can manage his private keys and also how the revocation method works. So, what's the 23:55.600 --> 24:04.000 second part? How the revocation of permission works? Oh, the revocation. Yeah, so the private keys 24:04.000 --> 24:15.040 are, I've got to slide somewhere about log in, let me see. Yeah, so basically when you log in, 24:17.040 --> 24:24.480 you've got your username and your password, and we put those through with a salt, through scripts, 24:25.040 --> 24:31.680 and that gives you two things, you get a log in key pair and a symmetric key. The log in key pair is 24:31.680 --> 24:36.880 then used to auth with the home server, so the home server is stores you're encrypted, you're 24:36.880 --> 24:43.360 encrypted identity there, and you can back it up if you want, and that is then decrypted with the 24:43.360 --> 24:48.560 symmetric key to get your three things, so you're identity key pair, the social key pair, which is 24:48.560 --> 24:55.760 what's used for follow requests, and the capability to your route directory. And yeah, so in terms 24:55.840 --> 25:03.360 of revocations, so it's handled automatically, but if we go back to crypt-tree, 25:13.920 --> 25:19.520 right, so if someone has access to one of these keys, then you have to rotate the entire 25:19.520 --> 25:26.800 subgraph that's reachable from that. So revocation, read revocation is not too expensive, 25:27.520 --> 25:33.040 right revocation is a bit more expensive, but yes, if you have a big directory, I need 25:33.040 --> 25:41.120 trying to revoke access, that can be expensive. If you don't, if your thread model doesn't necessarily 25:41.120 --> 25:48.080 need like a full key rotation, then there's sort of an intermediary we have, which is secret links, 25:48.720 --> 25:53.760 and you can just basically delete the secret link, and then that link will not resolve any 25:53.760 --> 25:58.400 more, even though the keys underlying are the same, depends on your thread model, but yeah. 26:00.800 --> 26:04.160 All right, thank you everywhere, it's going to give them another hour of pause. 26:05.520 --> 26:09.760 Thank you, Ian, appreciate it. Where are you going to start changing over fiscal?