 Okay. Hi, everyone. How's the audio on the video thing? Great. Wow. Hi, everyone. I'm surrounded by my slides. This is great. So, thanks for coming to this talk, and thanks hugely to Zego for letting me borrow his laptop while mine crashes on two monitors because it uses the cool new Intel chip set that isn't fully supported. So, I'm here to talk about Sandstorm, and so I'm building Sandstorm with a team of other people, and it's intended to be a viable alternative to software as a service as a whole. And that's a pretty big goal to compete with software as a service as a category. And so our first goal is to make something about as easy to use as Google Docs but much more private. So this talk is both about what Sandstorm is and how packaging works inside Sandstorm. I think that we'll have a bunch of spare time at the end, and then I'll really ask people what they want me to dig into in more depth. So, when Kenton, Varda, and Jade Wang were initially working on building Sandstorm, they had a few principles they were working from. They noticed that many people are very comfortable using apps that run in web browsers, where Sandstorm is really targeting people who will probably never see a terminal in their lives, and if they will, maybe it'll be for a minute when a friend shows them something. So, Sandstorm is targeting people who are using web apps inside web browsers. Another principle is that people really like choosing the software they use. And this is something that really struck me as almost great about Debian, which is that on one hand there's a huge amount of software available in the Debian archive, and on the other hand, you need to be root to install any of it. And this is a real conflict with the fact that I run a shell server for some friends, and so whenever they want any software, sure, all of our software in Debian is free, but they have to ask me permission to install it. So, we'd like to build something where people can install whatever software they want to use safely. And the other thing that principle that Sandstorm is based on is the idea that security sandboxing is an achievable goal. So, I'm going to start this talk with a quick tour of Sandstorm and then talk about a few more things in depth, and I'll conclude with a few comparisons. Yeah, so we'll start with this tour, and I'll show you what Sandstorm looks like to use it. I'll show you what happened in that demo, and then I'll demo how to package some software which will evolve as a station from this machine to that one. I hope that works okay. And then I'll talk more about the security hardening that Sandstorm does and how the Sandstorm community works, which I think will have some lessons for Debian also. So, I said let's start with a guided tour. There's this service that I, and arguably Clint, and I think arguably someone else, I think Laura Arjona, maintain called storm.debian.net. And storm.debian.net is a Sandstorm install that is for the Debian community to use, and I'm going to demo to you what it's like to create a new document there using Etherpad. Actually, how many of you have used Etherpad ever? Okay, cool, quite a few. So, those of you who have will notice some differences when I do it on Storm. So, let me show you that. So, this is the dashboard on Sandstorm. It's showing me a list of things I've already made, but I said I would make something new. So, I'll click over here and click over to Etherpad. And then I'll click Create New Pad. And if all goes well, there will be an Etherpad document waiting for us. So, other than the speed, this is like reasonably easy to use. As a side note, Storm is hosted in the US, so I guess it takes extra long to get all the data back and forth. But anyway, oh, and other than Zego's script block, other than Zego's no script, this worked great. Actually, maybe I'll, well, maybe I can communicate with the script blocker. Okay, I'll be careful. Sure, great. Great, so now I'll reload and hope it'll work okay. So, there you go, super easy. Okay, so supposedly that was pretty easy. I made an Etherpad document. I did have to do it by, oh, so giant, by clicking this Create New Pad button here. And so I want to talk a little bit about what that did, technically. So, when I click that plus button, in Sandstorm it creates a new grain of the app. And everything you create in Sandstorm, a document or an email box or a chat system is a grain. And now I've used this term without defining it. So, I'll be really concrete. When you have a, when you, I clicked that plus button on the server, it launched a new process for Etherpad. Etherpad is written in Node.js, so there's now a new Node.js process running on the server side. That process runs in a context where it can only see the code in the Sandstorm package for Etherpad. And that's mounted read only. And then, unique to every grain is a writable slash var directory. And also a disposable slash temp that gets cleared whenever stuff exits. And so, the Etherpad code wakes up in this world where the only place it can write to is slash var. And it notices it's empty, so it goes and makes a new database in slash var, and it makes a single document there, and then it starts responding to HTTP requests. And so, each time I click plus, it's in effect a new Etherpad install that happens to support that new document. And I mentioned HTTP requests. All the HTTP requests between the, between this browser window and this grain here are mediated by Sandstorm. They don't actually go straight to the app. So, by putting Sandstorm in the middle, it means that Sandstorm can do access control for the app. And just to demonstrate that, I'm going to go back to this Etherpad tab here, because you can't see the URL, so maybe I'll change that. So the URL is like stormdebian.net slash grain slash something or other. And if I open that in a private browsing window, which I'll move over to your screen now, if I open that in a private browsing window, Sandstorm will tell me, you did not have permission to access this grain, please sign in to request access. So this is really highlighting the fact that Sandstorm sits in the middle of all the HTTP conversations between the user and the app. And so this allows us to do something interesting in Sandstorm. It means that when the app receives any HTTP request at all, it can know that HTTP request has already been accessed checked. So Sandstorm can add a couple of headers to that request indicating what permissions the user has. And so this is a couple of those headers. Sandstorm sends my name over and it sends over the list of permissions that I have. And then any other headers that the browser sends to the server. So that's sort of the very broad overview of how HTTP requests work and what it means to make a grain. I talked about access control, so let me zoom in a little bit on that. And to do that, I'll do another demo. I'm going to use my other laptop. Is anyone here willing to participate in a demo using your own laptop and on the Menzies-12 IRC channel? Okay, great. Somebody in the back. So I'm going to share that pad with you. It's not important that I'm using my other machine, it's just that I'm more comfortable with it. Actually, it's probably better if I demo it here. Yeah, sure. Okay, so if I click Share Access here, I can make a shareable link that has edit permissions, which for my convenience I'll do for my laptop here. And it's devcomp16-menzies-12. Is that right? Great. Thanks, Jared. Okay, so there's at least two people who volunteered in IRC to watch that. Pardon me while all my demo stuff breaks. Okay, so I'm going to reload this document. You all should write things to make my demo be more interesting. Yay, hello. Great. So actually, do me a favor and just hold down a key like A or Enter or something. I'm going to revoke your access now, thanks. Okay, so now you can't write anything more. And do you agree? Are you able to write anything more? Yeah, so the point here is that Sansform on the outside gives me the ability to set permissions on the sharing links and the people I've shared with, which are now all revoked, via this consistent interface outside the app. And so the two concepts that we really saw there are, the two concepts we really saw are sharing links and the idea that permission headers can change. So his ability to access that app really is mediated by Sansform. So that's what it's like to use Sansform. I'm going to talk now about packaging. Maybe before I do the end of the question so far about what you've seen. Okay, great. So in Sansform, we have Sansform as a concept of the SPK file, which is a binary package. It's a list of files and some metadata. It's pretty similar to a .dev binary package in that it is a list of files and their contents and some metadata. So in our case, the metadata lives in a configuration thing called Sansform package.dev.capnp. There is one distinction between binary SPKs and binary devs, which is that binary SPKs are always signed and they're signed using an app key that is the app ID. So whoever holds the app key can issue updates for that package and if you don't have, if you lose that app key, you're kind of screwed. Although we have actually like whitelisted a couple of key transitions in the Sansform core for people who've already lost their keys and trusted us to replace them. So this is different from a dev, of course, where the signatures are done at the archive level, not at the dev level. So to make a Sansform package file, the most raw way to do it is to take this Sansform package.dev.capnp and pass it to the SPK pack command and that will generate you one of these SPK files based on the list of files referred to by Sansform package.dev.capnp and the metadata inside the package. If you do it that way, it'll definitely work but it'll slip up whatever files that file name exists on your system which may or may not be what you want, maybe if you're collaborating with somebody else on a package the path to something is different on theirs than on yours. So also to do it this way involves no concept of source packages at all. This is how things were until a year and a half ago when I started at Sansform and Drew Fisher and I worked together to make a concept of source packages using the tool Vagrant SPK which I will now, should I risk a demo? Let's see. You don't? You said or you do? That's fine, I'll attach it into my machine. Great. So before I do the demo I guess let me just talk about the concepts of what it is to make a Sansform package with Vagrant SPK you first declare what sort of platform stack a web app uses be that a PHP-based thing like Lemp, Linux, Nginx, MySQL PHP or Python stuff or Meteor or Node.js. I know there's a few other ones. Some of these are contributed by the community. Some of these are maintained by us the Sansform core team. So you define you declare what platform stack the package uses. You make a new entire Linux virtual machine that you will run the web app inside. And the configuration files for the virtual machine are set up in the set up VM phase. So VM up will start that virtual machine. Vagrant SPK in it will make the Sansform package def file that contains the name of the package and I guess it will also assign the app a unique key that will be the update key forever. And then you can run the app in a development view of Sansform where you can modify the app code and it's not fixed yet. And click around and during this process we actually trace the app to find out what file it uses because we have this problem where on one hand we want the app to bundle all the dependencies but on the other hand we don't want every app package to be two gigabytes. So when the app is running in this dev mode we've mounted a few file system overlays on top of the file system and any file access that the app makes we leave a note to ourselves to add that file to the Sansform files out list which has this upside of small packages and this downside of if you didn't click on the right part of the UI to import the right pipeline module you might never get it. And then when your users do it will break. So there is a provision for whitelisting directories to include certain whole directories at the packages request. And then you run pack and that makes a Sansform package file. So maybe I'll risk the demo gods after I'm done with the slides. And I'll maybe I'll just ask you if you have any questions about this process. If there's any steps I should zoom in on. Yeah. Oh and if the question is how do you handle GPL. I'll let me get to that later. No it's just about the platform stack. You mentioned our list of samples. Do you have Ruby on the rails support among the list? No but we almost do. We have like a wiki page that says how you would do it but there isn't a pre-made one. And there's one more in the back. So you know one thing I forgot to mention is that the setup VM in the VM up step. So the setup VM step will and I'll get to your question in just a second. The setup VM step will write a bunch of shell scripts out that are the platform stack. And those shell scripts do things like see the app get installed. The things that your app will probably need based on what we think based on the platform stack name. So anyway that's Davini. Ben yeah. So I was kind of concerned about the way you discover what files need to be bundled. Why would it possibly be concerning? What could possibly go wrong? I mean does that list get saved so that you can then reproduce this build using the next time? Yeah. Can you script that stage so that you have some sort of scripts to exercise whatever parts of the app. Hopefully all parts of the app and then to generate that list. So the first question is the list does get saved. There's an output to file sans-dorm-files.list which you're supposed to get add into your package. Conceptually I consider a part of the source package. And as for scripting it there's no especially sans-dormy way to script it but you could if you tried hard. How's that for a no? There are a few platform stacks where the exercising stuff doesn't matter at all. I think there's just one actually which is Meteor. Meteor is this Node.js based web framework. It has this feature that it can output a list of all the files the app needs because it controls the entire environment of the app. So that one we won't break it. As for every other app we probably won't. There's certainly been like app point releases people have issued that are then forgetting to include certain files because they didn't exercise them. And in addition to the auto-generated sans-dorm-files list you can add things to an always included line in the sans-dorm package def which will make sure it's always included whether or not it's in the files list. And there was a final technical question about bundling which was I was surprised that you would use fuse as a layer there. And I thought FA Nodeify might be more efficient but if it works it works. Yeah I think there was some race condition problem that I notified and I'm forgetting. My question relates to updates. Great you've got your sans-dorm platform and you've chosen some apps. How when the packages release an updated version of Etherpad or how does that come down to my sans-dorm server? How do I get that? Great. I'll just answer that now. So short answer is there's this service that sans-dorm the company runs called apps.sans-dorm.io and there's a big SPK called upload which uploads the more recent version of your SPK file to that. And every sans-dorm server checks a JSON dump from that apps.sans-dorm.io daily and if there is a new update to any app you have installed then it shows you a notification in a bell icon that when you click that it shows you which apps have updates. Then you click the install updates button and then you have the update. And code wise this is technically easy because the app runs in a fast system namespace where the only files it can perceive are the app code itself. So there's no dependency problem to work out there. On that note what happens to running grains that are when an update is installed? Do you have to reinitialize them or what happens to those? I mean in general if the grain already exists I mean there's two different answers maybe depending on what you mean. If you have like this thing that I made over here if I were to install an etherpad update then the processes for this etherpad grain would get stopped. The code for the new version of etherpad would start it would read the data out of slash bar and so it would continue to provide the same interface but there would be a quick flip. And as for if that would apply to grains that I literally have open right now I actually don't know off the top of my head. But certainly when the grain shuts down it would wake up with the new code. So I'll avoid risking harming the demogods again right now and I'll just continue past this. One thing I want to point out is that every sandstorm package is a Debian derived distro. Etherpad on sandstorm is a Debian derived distro. All the other 57 apps are I think except for the ones that chose to base their bundle files from not Debian in which case they bundled it from some other Linux distro. So exactly what relationship they should have to Debian isn't quite clear. Also these packages are kind of enjoyably small. The etherpad package is 18 megabytes so that might be the smallest useful Debian I don't know are there smaller useful Debian derived distros people know of. So I think I think I think that's kind of cool. What is that? Yes, in a rather fast. And I'm cheating with the 18 megabyte number because it's compressed. I think with LZMA so it's like mega compressed. So you probably have like 60 megs of headroom. But another fascinating thing is that people really do use this vagrant SPK tool on macOS and Windows not just on Linux systems. Which if I'm to speak about Debian for a second there's this program called FPM. I think it's called Effing package management and it exists to take like directories of files and jam them into whatever packaging format you wish. And as far as I can tell it exists because it exists because people aren't very familiar with the Debian packaging tools. And in part they're not very familiar with the Debian packaging tools because they don't run Debian. They run macOS or Windows. So it and we it's I think it's pretty cool that we can have all these people on different platforms making sensor maps. Another thing though is that some porting of the app can be required. So apps need their login pages removed because when the user shows up to us a grain of sandstorm they're already logged in. And an etherpad something needed to be done so that it would only ever create one pad per grain. So it's not it's not the case that you can take any random off the shelf bit of web app and do this weird tracing thing and put it into a bundle and run it successfully. You might need to make some changes relevant to sandstorm. Oh yeah and you might need to look at those headers like I mentioned the ex sandstorm username. So I guess is Antonio Tercero at DevCon this year by the way. Anyway I want to say thanks to him for packaging vagrant in Debian. I use it all the time from his packages. So with those packaging steps talked about briefly I want to talk about the sandstorm back end and security. We have this very strange seeming goal that users can run arbitrary code safely. And like nowadays the phrase arbitrary code sounds like a security issue like oh no arbitrary code execution. But when I run a shell server for my friend that it runs Debian the whole point is arbitrary code execution. So the idea that we have this crazy size seeming goal shouldn't be that crazy I think by comparison. Here's the translation of that idea into a web app space. And to do that though we do need to make sure this arbitrary code can be run safely. So we do a bunch of server sized sandboxing things in the grain. To start with I mentioned this file system sandbox sorry the file system namespaces where only the code inside the app package is available plus var in temp. We use PID namespaces in Linux so that if somebody in the grain runs like PS they would only see stuff inside the grain. We use this UTS namespaces thing so that the grain always runs in an environment where its hostname is like. I think sandbox hostname. And then there's a system 5 RPC thing which I actually don't think matters for us but we do it. Anyway we do some more extreme things first of all there's no slash dev and no slash proc inside the grain. Which is kind of cruel but it has the upside that kernel vulnerability is that leverage proc or dev can't be exploited. Well there's nothing exciting in dev you can make no better if you want. Actually you might not be able to call make node unless you're UID zero so I guess you can't make no whatever you want. Okay great so it's good to be don't allow access to slash dev. If we have a slide of slash dev with dev null and dev random which is a sim link to dev u random and dev u random which is the real thing. Yeah we have a proxy pu info which is hard coded from the app packager's machine which is not perfect. Yeah I need to. Oh yeah if we can get better microphones that'd be great. And let me just double check that actually. Oh no I take it back we do map in the real proxy pu. I just read the source yeah. Yeah otherwise you'd have illegal instructions all over the place if you were unlucky. Yeah we also don't have any real network devices we just have one boot back device inside the name inside the network namespace for the app and we use user namespaces so there's only UID 1000 inside the green sandbox. Also we use a kernel feature called no new pribs so that even if there were somehow set UID process inside the sandbox executing it would not result in UID zero running program. And we use set comp bpf to limit what cys calls what kernel cys calls that the app can do so. There's things like access to 32 bit instruction 32 bit cys calls for 32 bit binaries running on an x86 64 machine which we block. We also block a whole bunch of irrelevant network types and so on. I have these under the extreme section just because until I heard a sense from I never heard of anybody doing all these things. And the other one which I know that no one else does is that with all this said it seems like there's no way to actually get HTTP in and out of the grain there's just a low. So to solve that problem we have. Single Unix socket that is passed in by file descriptor into the grain over which all communication occurs using a library that we maintain call cap and proto which is also in deviant. It's just yet another binary RPC system I can say things are cool about it but that's all that's important for now. So the only way in and out of the grain is over this one file descriptor of the Unix socket. And so that's the sandboxing. Skill ability wise I think mad duck asked me earlier today if you make a new either pad process and install for each of the either pad document how can this possibly work. And answer that you should first think about Android. So on Android when there's memory pressure on my phone the operating system the platform is willing to kill processes belonging to apps are using up a lot of memory. It hopes that those processes saved all their state to wherever they're allowed to save state so that when you go visit that app again. It loads up just the same way with just the same screen of them. And so we do the same thing after 15 minutes of non use we we kill the processes inside the grain. And then if I go visit that grain again it'll spin for a second and then come back. Other scalability thing is that sandstorm is single server only to make all this work. So. We do have this crazy goal that I said which is to let users run arbitrary code safely. And that gets really interesting in a context where people do share things with other people. The attackers like on the web it could easily be the case that external attackers could successfully break into one of these grains. And so where we sort of drawn that line is that attackers should only should only be able to exploit vulnerabilities in grains to which they already have access. So you know now that I revoked the sharing link I made before there's no way for anyone except me to make any HTTP requests into that etherpad grain. So even if that etherpad grain had an old version of that flow SSL if it had or more could execution bug if it had this or that you can't reach it so you can't exploit it. Unless you've already been granted access. And so I want to talk a bit about the security issues we've defanged this way. We did a bit of a study last year to see which which documented vulnerabilities in web apps that are packaged for sandstorm were still an issue inside sandstorm. So we had the guests that we would defang a lot of them and we found that over 95% of them we had mitigated usually entirely. And to eliminate this let me let me give you two brief summaries. First of all a single document service is much easier to secure. So to go over these on etherpad there's a variety of issues that say that if you have access to etherpad server you can list all the documents on that server. Etherpad has no built-in access control the document ID of the access control so once you have the document ID you can go read it. Well that doesn't help if each etherpad grain is just one document inside. So none of those apply. In shelletech there's a bug where an attacker could read an arbitrary file on the server. But in shelletech on sandstorm the only files on the server are the shelletech package which is public knowledge and the files in slash bar if you have access to this grain. So that doesn't elevate your privileges if you could view the grain you can view the grain. Also you can run arbitrary shell commands on some versions of shelletech but you can only exploit that if you've been given access to the grain so that doesn't help you as an attacker. And then this tiny tiny RSS bug where you can do SQL injections and nobody even got a CVE for it. Anyway in tiny tiny RSS each user's install of tiny tiny RSS is sandboxed from each other's users so if you can access your own tiny tiny RSS it's not interesting but you can also SQL inject it. Because you can go click around the UI and modify stuff yourself without that. So those are the app vulnerabilities some of them that we've managed to defend against and all of these we defended against before they were disclosed of course because it's just a design based on the sandstorm design the security just falls out as a result. And similarly a limited kernel is easier to defend so I think that we blocked at least 75% and it might be more than that of the Linux kernel CVE's in the past year and a half that we looked at this. We don't allow unprivileged user namespaces inside the grain so nobody can exploit those bugs. You can't use the binary on sandstorms you can exploit those bugs and there's a whole bunch of kernel bugs in all these obscure features of the kernel in this calls that we block so you can't exploit those either. I think yeah there are two that did apply on sandstorm and you can look at our docs or I can show it to you afterwards or in a second if you want to see what those were. But this stuff is important to me not just because I love putting CVE numbers on slides it's important to me because. In 2004 I was running a wiki for myself and some friends and I neglected to update it because I didn't pay attention to the Twiki security announcements mailing list in I think it was March 2004. And then in May 2004 I noticed there were a whole bunch of weird processes on my system and it turned out that somebody had exploited a bug where the search functionality inside Twiki. If you added a back tick and a semicolon in the right place you could run whatever code you want on the server because it just execs grep. And I didn't audit that code and no one could realistically expect me to audit that code when I was running it on my server. So things like this prevent people from self hosting their own apps and if the competition is software the service then the competition is teams that have a dedicated security team. So if sandstorm or something like it can protect users in a way comparable to what a multimillion dollar security team does on their side through a lot of effort on our side through bizarre sandboxing. Then you can get something comparable where self hosting is actually a good idea. Otherwise running your own web apps is a giant slog that everyone in the long run will stop doing. Or alternatively only people who have well funded maintenance teams will do and that's not really a future that's exciting to me either. So with that said I want to talk more about the community. One of the things that is fascinating to me about sandstorm is that we do really want upstreams to maintain their packages in sandstorm. And there's I think about five or so out of the fifty eight sandstorm packages that exist that are sandstorm only or at least sandstorm first. So those are apps that if you ran them without sandstorm they wouldn't work and or at least they would show a UI but some functionality wouldn't work. And people seem to like the idea of making sandstorm first apps because they don't need to build a login button the user is already logged in. They don't need to build a multi document UI the sandstorm new grains button handles that. And there's also this clear separation of concerns in the platform where if you bundle whatever you want if you bundle manga if you bundle Redis if you bundle a version of node that's not in the Debian archive just have a lot of fun. Whatever you're doing is not negatively impacting any other apps. So there's no platform reason to stop you. So so we just say yeah whatever go ahead do whatever you want inside the sandbox and web app upstreams as you've likely can guess find that pretty exciting. There's also no deployment process really for installing a sandstorm app there's just that like plus button there's an install process that I can show you but it's really just like click click. Similarly doesn't require any thinking all of the effort in the deployment process is done once in the packaging time. So yeah so the result is that we actually have a lot of packages maintained by upstreams and a handful of them are. So in terms of lessons for Debian there's a few things to think about at Sandstorm we have this goal that we think that that web app authors will want to publicize Sandstorm as a good way to run their own software. And that actually leads me to this general question about Debian like how what is our model for how people discover Debian and choose to run it. I think our model is basically tech press plus their friends some some some union of those and it would be interesting and if if app authors were also part of that equation really. Can anyone is there an app that people are like I guess maybe a patchy maybe the patchy docs are like you should install Debian so you can have a patchy but nearly nothing else I can think of really recommends Debian from the upstreams perspective. Certainly web app packages don't I have to say. And then there's this other question so for us we we don't really have anything resembling Debian policy we just have the technical facts of how the sandbox works and we tell app authors to do and do whatever they want. And on the other hand Debian has policy and it's actually really powerful I think though that Debian policies main contribution is preventing Debian developers like us from stepping on each other's toes. And then if that's the case I wonder to what extent you know we can evolve out hypothetically make sure that policy is as minimal as possible to make sure that is we have to step on each other toes as little as possible. Also Debian policy doesn't help my friend Chris who has an account on my Debian shell server who wants to get install something but still needs my permission to. So there's still something I think we can do to make Debian policy help end users more than it does now it certainly helps us a lot though. And then along those lines right now there's an effort in GNOME to make a new app packaging thing XDG app. There's I can see some reactions there's the canonical snappy thing and each of these are at least slightly interesting because they have some some story about sandboxing. Because to the extent that app packages when you install them now in Debian system need to work together to avoid trampling the whole system. If they didn't need to work together because they were sandboxed somewhere unique to the app then maybe we could have less policy or maybe we could recommend people install apps by a different way than Debs. And the other thing is that Sansform has this sort of different software freedom focus which is we are we do really care about software freedom. It's just that our priority is making sure that people can run the software they want without having to ask permission from anyone which is a different we're kind of software freedom than DFSG although we do care about DFSG also. And I know we have just a minute left before two forty five so I'll just leave this line here and say one sentence. We run the centralized services like I do mentors Debbie and that for package review and because I'm one of maybe three maintainers of mentors that Demi not that along with all of DNPabs. Anyone who wants any changes in that service has to go through me and I think that that is not a great vision of software freedom and is why the things stagnated over the past five years I think. So just after this there's a boss and there's maybe some time for Q&A here and I have some stickers that I'll grab from my backpack now thanks so much for listening. Oh and I have one other line to say actually which is if anyone ever asks you what Sandstorm is because I've just told you so many things that are true about it. It's taking me about a year and a half to come up with this summary. So I've saved you the work you can tell them Sandstorm with a more private Google Docs. Yeah well we don't have the whole global CDN thing going for it. We do have some plans to integrate with CDNs eventually optionally. Yeah. Oh and thanks Ego again for your laptop goodness. Yeah sure. Yeah I guess it's your power. I was I was actually a little skeptical when I heard your this is a Google Doxing but I actually think it's awesome. It's really great for anyone who wants to run a web app without lying and lying awake at night worrying about whether that's great. I really like it. Thanks great. Yeah I mean one of the other things about the scalability thing is that web apps usually have scaling problems because a lot of people are accessing them. And if a lot of people not very many people are going to be accessing a thing that is access controlled so that only you and your friends can view it. So the scaling problems actually aren't a huge deal we find. Well we have one more question here if we can. Yeah yeah yeah. The possible solution or similar at least. And I wonder if you have plans to go further than just what you do because Flatpak is clearly desktop oriented and but with good integration with free desktop menu. So the application show but well a web application is an application like another just using another technology. I would want to see it on my menu as well. So is there some integration here that could be done. I don't know if it's a domain level or the sandbox level but it's clearly something that it needed. Yeah that would be interesting. That's a really good idea and I haven't thought enough about it to think about what I should say. Okay then another question for you if you want. Is there ways to plug more holes in the sandbox so for example you can run the database outside of the grain and store it on the machine. Yeah so yes and no. I should say no and yes. The database one well the way that we want sandbox holes to get to show up is where you know so I showed you the sharing menu where you can share access to other people. There will be a way for the app to request access to either another different grain or some external service entirely like your Twitter account or something. And that would also be mediated by the same sense from why you get a top drop down that would say do you want the taxes. Do you want the thing to be able to access your Twitter or something like that. And we're still working on the details of that. So that's how we expect holes being put in the sandbox to work. It's kind of sad to me if in order to start an app at all you need to put a hole in the sandbox first because then the user has no concept of why it's worth doing. I wouldn't want it to be true that an app depends on some external service to work for a database. But on the other hand you can imagine some like like PHP might admit the whole point of PHP might usually the point of PHP might admit it can be anyway to connect to a remote database. And so in that case it would make sense for it to show a chooser to let you choose a remote database. Maybe other question. It's also worth saying there is there's a buff after this here. So if you have more questions and I will just stick around but I'm happy to answer them here too. So you mentioned that basically your system package is built by running this process by installing the entire thing in a VM and extracting all the files, which means that unlike a source package you don't really know how to reproduce the build. And like what happens for instance if there is a DBN security update and how do I know that my package need to be updated or rebuilt and or do yeah basically or do we or can we help that happen more or less automatically. Well the. So of course I'm going to tell you something that won't really you which is solving that problem is not a real focus for the central core team in the next year or two. Because we want the sandboxing to be good enough that even if the app is vulnerable it's not a big deal. Now having said that if you have a WordPress blog and you only give other people like edit access but they can exploit an image magic bug to an arbitrary code, elevate their privileges that might be bad so it might still be worth fixing. It is not as big of a deal. So what I would the thing that comes to mind is to use the file contents the file hashes so what I would like to see is something that analyzes transform packages to see if they contain files whose hashes are known to be superseded by the security update version. And from our end we are the the packaging tooling that I co-maintain with Drew Fisher that thing targets Debbie and Jesse stable for the reason that we want it to be easy to let these point releases just happen. Okay great thanks bye I'll be right here.