 Okay. Hi, everyone. I'm Ashish. Good morning or afternoon. I have about 20 minutes to tell you about this free software project I work on called Sandstorm. So I'll be very happy to answer questions in the Q&A and also just outside of this room afterwards since probably there will be more than five minutes of questions because Sandstorm is kind of weird. If you do ask me a question, or you just want a sticker, I'm very happy to give you a sticker, so I hope you do come ask me questions. So I said in the description that Sandstorm is a web app, a web-native package manager, I think. I can explain how it is a package manager, but let me first explain what it looks like to a user. And to a user it is a free software alternative to Google Docs. So if that's something you want or something that people you know want, then maybe you should look into Sandstorm. And I've actually stopped making new Google Docs to collaborate with people. I make them on Sandstorm. And to just show you what that's like, we'll do a demo. Hopefully this demo will work. So that's always the trick. Great. So Sandstorm runs this server. So I should say Sandstorm is the software, but it's also the name of the company that I work for. There are seven of us. So Sandstorm Development Group Incorporated runs a server called demo.sandstorm.io. In the next 60 seconds, I'm going to make a new collaborative text document using Etherpad. So if I had a normal Sandstorm server, I could log in, but since I'm just using the demo, I'll click start the demo. And I'll see I'll install an app. Will I? Okay, sure, why not? So I'll install Etherpad, although there's other things I could install. So get on the Dev Confire C channel. That'll be a surprise in a second. Now I can make a new Etherpad document, and it'll spin up an Etherpad instance for me with a collaborative document. So, you know, great. So now, since I said it's like Google Docs, I'll make a sharing link. So I'll click on the, let me just zoom out. I'll click on this hamburger thing, click share, and I'll make a shareable link, and here's the fun part, drop it on IRC. So I look forward to seeing you all on this pad over the next couple of seconds. I'll leave it, I'll leave it like this for about 30 seconds while you all deface my pad, and then after that, I will revoke your access. So, great. Yeah, so like I said, it's a free software alternative to Google Docs. Here we have a sans form package, oh, sorry, an Etherpad package. Ooh, nice snowman. Wow. Wow. Okay, well, that's about 30 seconds. So, I can also revoke that sharing link. So now you're all gone. Great. So that's what sans form is like for users. By the way, can anyone show the audience what it looks like when I revoke your sharing link? Yeah, it's just immediate emptiness. Yes. Oh, snap. Oh, snap. Sorry, DKG. So, yeah, it's really, it really is just multiplayer real-time gopher. So, yeah, that was a demo. So that's what sans form is like for users, but I want to tell you why we're working on this project. So, software as a service is the main competition to free software web applications. Software as a service is actually a competitor to software. So, I'm going to paint some bleak pictures for you about the software of the service landscape where people just run things without having any control over it. So, here's sort of how popular one service is. I'll just let this sink in for a second. And if you think this is bad, then you might want to know more about Google Docs. Here's their growth over time recently. So, there's about a quarter of a billion people using Google Docs on a monthly basis. This is actually the monthly active users, not even the people who created an account. That's probably more people that have ever heard of free software. It's almost definitely more people than have ever used Debian. So, software as a service is very popular and is basically out competing software. And it's really nice in some ways. You can go to the Google Docs website. You can click. You can start using stuff. You don't have to install something. You don't have to manage your upgrades. Somebody else manages that. Somebody else manages security. The only problem is there's no software freedom. So, users have no control. And I'm going to tell you about Sandstorm and how it works. And I hope you understand that I'm very impassioned about Sandstorm because I think it addresses the free software needs of people who are using servers controlled by other people. Of course, there's probably lots of other great approaches too, and I'm happy to hear about them either in the Q&A or after the talk. So, a brief table of content then for this presentation, you've already seen how Sandstorm is an alternative to Google Docs. I'm going to tell you a little more about how it brings software freedom to users of web apps. And I like to say Sandstorm looks like a usability project, but is secretly a security project. And I'll show you a bit about how our packaging works in Sandstorm for taking Linux server apps and making them something you can run in Sandstorm. And I'll talk to you about some similarities and differences between Debian and Sandstorm. So, let me begin with software freedom. So, software freedom is the idea that people can use, modify, and share the software they use. And in Debian, of course, we commit to this with the Debian-free software guidelines. It works great on my laptop. It works great for me on my server. But a bit of a sad story about Gatorious. So, how many of you know about Gatorious? I presume everyone in the room. So, Gatorious was a free software alternative to GitHub. This is what it looked like. It actually just shut down because they stopped running it, the main instance like gatorious.org. Of course, it's AGPLV3 software, so you can run it yourself if you want to. Anyway, four years ago, I was an active user of Gatorious, and I really wanted this feature called Webhooks, which is like Git post-receive hooks, but they send messages over HTTP to you when some event occurs. And it turns out that I read the documentation, and Webhooks were already part of Gatorious, and then I kept reading the documentation and it said, this is disabled on the main instance, but you can use this on yourself install. And so, as a user, I want to modify Gatorious.org that I'm using on a daily basis by submitting them a one-line patch to their config file. But I can't do that, or I can do it maybe, but if I will, they won't accept it. This is not software freedom. This is not the ability to modify the software I'm using. And a lot of what we do in the free software world when we see centralized web services is we build what I would call free of cost and free software, software of the service web applications. And these are things like tiny, tiny RSS, WordPress, Gatorious, and with those tools, we empower the SysAdmins to use and modify the software, but the end users of the software have no freedom to modify it. There's sort of a quick mental rule you can go to in your head. If a thing is multi-user, then probably most of the users have effectively no software freedom. They cannot modify it. So the tragedy of no software freedom isn't just this hypothetical that people don't have the experience of being able to change their software. It has a real practical application in that people modify software in order to make it do what they want. And user creativity is a lot of what drives free software forward. And so a service like Gatorious won't gather contributors in the same way as something that people could modify in their own laptops because if you make a small change to Gatorious that makes sense for you, that doesn't make sense for some other user, you have no way to use that on the Gatorious central service. So I think that free of cost or free software, SAS apps empower system-ins with the don't empower users. But they actively harm users in a lot of cases too. So here's some brief stats of security issues in a few free software web apps that I found for this talk. If you use round cube or you use WordPress or you use Etherpad, you need to update it frequently or your so-called private data running on your server can be exploited and abused by others. And the one thing that software as a service provides is this maintenance. You might think this is not a big deal, these things are packaged in Debian, they can upgrade them if they're packaged some other way, it's free software, they can maintain their own servers. But the truth is people don't maintain their own servers. So Etherpad in March wrote a blog post about how, hey, everyone, if you have an Etherpad install, you have to upgrade. Here's a list of free of cost installed of our free software that people need to upgrade. And if you look at this list, Etherpad.Mozilla.org is down in this list. The Wikimedia Etherpad is there. These are pads running free software that is remotely exploitable to defeat user privacy. And Mozilla and Wikimedia have all the resources in the world they need to get around to upgrading their pads. If they can't upgrade their free web software, realistically no one can. So that's the sad truth, I think, of free software-to-service web applications. Let me tell you a bit of a happier perspective. On my own laptop, I can do things like download tar balls and configure them to run in my home directory. And this is sort of the world that we're used to, where people can on their own computers modify the software they're using. And when you do that, you end up maybe with personal patches, maybe I patched, like literally I once patched alsoMixer to say salsaMixer. This is not something that I could do if alsoMixer were a remote web application. It's not even necessarily useful. It was a fun thing to do. The other thing is that these patches are private by default in my own machine. It's not like modifying the software affects it for everyone else. It's that that makes it so hard. And people in sort of the proprietary web app world talk a lot about data portability. In Debian, we know how to do data portability. It's called tar. You make a backup. And if you want to move from one Debian machine to another Debian machine, you tar up your home and you move. And that's sort of the whole story. But if I have to get installed WordPress, literally I've got installed WordPress from the archive. And I make a WordPress blog that, and I let noodles, let's say, have access to a new WordPress blog he creates using my server. Noodles has nothing like tar to back up the state of that WordPress and move it to his own app get installed WordPress. So the state of the art in Debian web app packaging is worse than the state of the art in command line tools. So actually, I'll take a second now and show you how Sandstorm handles that portability issue. So on this pad here, I have a mouse suite. Every Sandstorm package has this backup feature provided by Sandstorm. If I click this, it gives me a zip file of the contents of that app state. And I can restore that, oh, live demos. And I can restore that. Great. Here, oh, wrong button. See, great. And there we go. Sorry. Well, yeah, OK. So this is me having restored the state of that etherpad, having downloaded a backup. This works in Sandstorm because the promise between Sandstorm and apps is that the app owns its own little slash bar. And so the download is the download of the current state of slash bar for that app, which is kind of like turning up a home directory. Right. So Sandstorm, I like to say, looks like a usability project and is secretly a security project. So there's a few ways in which this is true. One is that access control is managed by Sandstorm. So when I gave you that etherpad link, your permission to use that pad hinged on Sandstorm granting that access. And it has the upside of giving universal Google Doc style sharing to app instances. And it also has the upside of insulating you from bugs in access control by apps. So we also emphasize granularity, the idea that one document should be security isolated from another document. So in the etherpad case, clicking a new etherpad document spins up an entire new etherpad install configured to just have one document in it. And so each thing in my Google Docs files view is a whole separate install of etherpad. If etherpad were malicious or if it were buggy, somebody might want to take the private data in my pad and export it out to the internet. That's a kind of serious problem that could occur. But in Sandstorm, we sandbox apps so they have no network access. So the goal here is to be able to run arbitrarily insecure web apps safely. So therefore we can't let now have network access by default. There's another thing that we're doing kind of differently called the power box. So it's easier to explain that with an example from GNOME. So in GNOME, if you do file open or something, you might see a file chooseer dialogue like this. The funny thing about this file chooseer dialogue is that it returns a string to the app. And then the app opens that string. But the app could have opened any of these files. It's just being nice to you by asking. It would be a better design, which the GNOME team is working on, to have this dialogue grant a single file descriptor to the app. And then the app would only have access to the resources it needs. And the user would have had a way of chance to choose what it would look at. This in the security world is called the power box approach. So we call it the power box too. And we're using that for inter-app communication as well as file system stuff. So we have a few other techniques. So I should emphasize the power box is not fully implemented yet in Sandstorm. It's like, half vaporware, we'll get there. You don't have to believe me, check back in a year. But there's a few other techniques that we're using for security hardening apps. One is that only logged in users, that the user has granted access to use this app instance, should be able to do that. So this maybe blends weirdly with WordPress, where you want the whole world to read your blog. So with WordPress, we literally WGet recursive the blog and publish it as static HTML. And Sandstorm serves that static HTML, not WordPress. So there's no attack surface to WordPress anymore for logged out users. We also do a bunch of tricks to like content security policy to try to constrain in the browser how data can flow. And we use setcomp and we don't mount slash proc and slash sys to limit how much of the kernel of the attack surface a process can interact with. And the results are that all those five etherpad issues from this year don't affect etherpad and Sandstorm. And there's actually two, at least two, Linux privilege escalation vulnerabilities that if your kernel is vulnerable to, apps in Sandstorm can't exploit it because they require access to these obscure sys calls, which most web apps don't need. So we've blocked them before. So just a sort of almost flame bait question, if you have a sandbox as aggressive as this, do you really need to upgrade very often? Do we really need to worry that much about embedded code copies if the code can't do that much damage? I think the answer is no. We don't need to worry about it as much. So that's how Sandstorm is secretly a security project. And you need this kind of hardening if you're going to build something like Google Docs by packaging the whole world of free web app software with all of its constant change and possible vulnerabilities. But so let me tell you more about how to make a Sandstorm package. I have only a few minutes, so I might breeze through this. Feel free to ask me more questions afterwards. So for packaging, there's three steps. You first create a file that's basically Debian Control that we call sandstormpackagedef.cappenp. You do that by running this command spk init along with the name of the program that argues you need to actually start your web app process. That'll create this sandstormpackagedef.cappenp file. The next thing that Sandstorm has that needs to know what files on your system to slurp up into a package file. And that list of files is called the Sandstorm files list. To generate that, the way that we do this right now is you interact with the app in dev mode. You type spkdev and it launches in a Sandstorm install on your laptop. And you click around. And when you control C that, Sandstorm makes a list of all the files that the process touched, read from, that is. And makes that your Sandstorm files out list. And then whatever files those were, they get slurped into a Sandstorm package called the spk file. So that's pretty ad hoc and non declarative, and I'd like to improve that, but that's the way it works right now. You do that with this tool called spkpack. The nice thing is that your dependent, the quote unquote nice thing is that your dependencies don't have to be packaged then. So interactions between Debian and Sandstorm. There's a few, I think, interesting crossover points. Technically, it's worth knowing that every Sandstorm package is a Debian-derived distro, so maybe I should go to the planning buff for derivatives. But each app developer actually in Sandstorm would have to go to the planning buff, so that's kind of odd. At the moment, we only support one CPU architecture, which is AMD64. That's sort of because the app packages are binary packages at the moment. There's another thing that Sandstorm Development Group, the company does for the Sandstorm user base, which is we're running services for Sandstorm users. The most clear one is we run this dynamic DNS service called sandcats.io. I'm working on other features, other than dynamic DNS there. I'm negotiating with some certificate authorities to see if I can give out free SGPF certificates. Running services to help the community run their servers is not something that the Debian world does, but it might be something worth looking into. So in Debian, and we're also using the official Debian Vagrant box, so is Antonio Tercero in the room? OK, well anyway, there's a couple of Debian developers who make the Debian Vagrant box. So thank you for doing that work. One of the great things about Debian is that when I wanted to make the Alpine package on my laptop so that I could upgrade to the next version of Alpine easily, the obvious way to do that was for me to make, sorry, when I wanted to install Alpine when it was new, when its first beta release came out 0.80, and then I wanted to be able to upgrade to 0.81 when it came out, my thinking was the easiest way to do that would be to upgrade using a deb file. So I made a deb, and then it wasn't a huge delta to share that deb with the world. And that's the sense in which Debian has been really good about aligning the incentives for people to share the software they're packaging for themselves or for other people. Similarly, in Sandstorm, in order to run an app at all on your Sandstorm server, you need to make a package. So we hope that many people will share those packages as they make them. One debianish thing that we found community-wise is that we were hoping that upstream web app authors would care a lot about Sandstorm and make Sandstorm packages. But in truth, it's the Sandstorm community, kind of like in Debian, that does the packaging work, because the upstreams can already run their software. They don't need us. There's this other difference, maybe, in the way that Debian structures community versus Sandstorm, which is that we really emphasize getting more users as the main purpose of our community building. So I want to actually show you our Get Involved page because it's sort of just strange for a free software project. It says, hi there, it says nice thing. That part is not the strange thing. It says, first of all, join our mailing list, join the chat room, ask questions, give a talk about Sandstorm, package a new Sandstorm app. Oh, yeah, and I guess if you want to contribute to the code, here's the GitHub link. And the reason it has that structure is that the thing that we need the most from the community is more people using Sandstorm and more people talking about it. And maybe this is true for Debian, too. Our Get Involved pages maybe should de-emphasize how to make a package for Debian or contribute to Debian, the core of Debian, and rather get people understanding how to tell other people to use Debian. And then we'd have more users. Right. How many of these do I have? OK, great. Cool. So I have only about 30 seconds left in this presentation, and I want to just leave you with a few next steps. One is that I'm setting up storm.debian.net. I think you can go there right now, but you'll get a splash page that says I haven't set up the server yet. I'm hoping to have this service be a Google Docs alternative that Debian people can use. And if you want to come maintain this with me, I would love to talk with possible co-maintainers of that service. The other thing to say that is to close with, if you're building every software web app and the users of your app do not control the code they're running, what exactly is the freedom that you're providing to your users? So thanks. I'm happy to have Q&A here, and we can do more Q&A out in the hallway too. So thanks. Anyone have any questions? Or is that just like perfect? You'll all use it now. I'll ask a question. What of the sandboxing type stuff that you've built, which sounds pretty cool, do you think is possible to put back into Debian? So here's a few of them. Debian web app packages should follow the inspiration of this, which is they should install IP tables rules by default that prevent the user ID of that web app from having network access. We have a blacklist of syscalls in our setcomp filter list that it would be pretty straightforward to make a tiny sandboxing tool to use that blacklist. There's some content security policy type stuff that's harder to get web apps to do if you don't have a proxy in the middle. So that's sort of the shape of it. OK, thanks.