Sandstorm News

Sandstorm community raises $10,644 for Roundcube Next

By Jade Wang - 01 Jul 2015

Last week we asked the Sandstorm.io community to come together to support the Indiegogo campaign of Roundcube Next using their Sandstorm app store credit. Today we’re happy to announce that we’ve raised:

$10,644

We’ve contributed the total to Roundcube Next as a lump sum, making the Sandstorm community the single largest contributor!

Roundcube is an open source email app that you can run on Sandstorm today (demo). They are running a crowdfunding campaign on Indiegogo to modernize their user interface and bring Roundcube to mobile. Although the campaign has reached its funding goal, they’ve got some great stretch goals and you can still contribute until it ends tomorrow.

Almost a year ago, Sandstorm raised approximately $60K on Indiegogo to fundamentally change the way we use and host web applications. When we raised our $1.3M seed round last January, we made a promise to the community to pay-it-forward – to forward the crowdfunds to support other open source projects (such as Roundcube) in the ecosystem through the App Market. Since the Roundcube Next crowdfunding campaign launched before the App Market launched, we rallied the original Sandstorm contributors to dedicate a portion of their App Market credit to forward to Roundcube Next as a bloc.

Roundcube has promised that they will directly support Sandstorm as a target platform for Roundcube Next, meaning the app will get timely updates and integrate with Sandstorm-specific features. For example, we want to make it easy to attach Sandstorm documents to email for sharing.

Let’s take a moment to thank all the Sandstorm contributors who have chosen to forward part or all of their App Market credit to Roundcube:

Erik Swanson, Tommy Hodgins, Mark Bradley, Ondřej Böhm, August Lilleaas, Paul Gaspardo, Oluf Lorenzen, Eddie Jesinsky, Charles Lehner, Francois O Baldassari, Florin Godard, Lachlan Musicman, Patrick Ohly, Praveen Moorthy, Corey Ford, Toby Matejovsky, Giorgos Logiotatidis, Maxime Quandalle, Alexander Kulbartsch, Colin Maudry, Francesco ‘makevoid’ Canessa, Ben Cordero, Sebastian Kippe, Shawn Becker, shazow, Michael Manley, Pascal Gellert, Dan Bornstein, Wong Ho Wang, Petr Viktorin, Christopher Toledo, Thomas Hansen, Noah O’Donoghue, Matthew Steffen, Baruch Even, Pascal de Vink, Tim Davies, Alex Dempsey, Fred Schättgen, Bruno ARLIGUY, Maria, David Turner, David Meyer, Noel Yap, Hugo Artur Weber Schmitt, Joel Roller, Keith Hall, C. Moreno, Abdullah Khalid, Vincent Malley, James Graves, JollyOrc, Shane Gould, Matt Johnston, Alec, Alan Karp, JT Olds, Daniel Ring, Wes Felter, Sage Ross, Joseph Lee, Asheesh Laroia, Jason Hsu, Yuriy @html5cat Dybskiy, Amir Chaudhry, Pedro Ângelo, nFec, getify, Dan Morrill, Daniel DeSousa, Collin Jackson, Daniel Yokomizo, Aaron Vaneps, Glen Skinner, Tobias Ammann, Dinyar Rabady, Will Norris, Tim Butram, Nathan Henderson, Colin Dean, Jeff Cressman, Vincent Lim, Adam Berkan, Audrey Tang, Justin Fox, Jan Jambor, Fahrstuhl, Greg Perkins, Zellyn Hunter, Tim Lossen, David Alfonso, Michael Bright, Jamiel Almeida, Ali Gunduz, Jonathan Wheaton, Nathan Greene, Mitchell Barry, Matt Campbell, the paul, Svemir Brkic, Paul-Robert Archibald, Tiago Freitas, Eli Willaert, Daniel Schulze Hagen, Tobias, Jeremy Coté, Matthew Baggott, Jason Glass, Thomas Myers, Scott Pritchett, Mike Linksvayer, Fred Eisele, @noahsilas, Fred Smith, Jochen Bartl, Suvi-Tuuli Allan, Mark S. Miller, Rick Richardson, Rebecca Wise, George Ellenburg, Andrew Thibeault, Andrew Jennings, Rahim Nathwani, Aren Olson, Richard Bairwell, Heri Sim, Erik Andersson, Matt Siegel, Phil Dutson, Siegfried Kettlitz, William Zajac, Nick Richards, Kamil Páral, Garance A Drosehn, Guido Hoermann, Robert Konigsberg, Jasvir Nagra <img src=x onerror=alert()>, Joshua Warner, Ana Ulin, Walter Ebert, Brooke Schreier Ganz, Kevin Wallace, Ingo Blechschmidt, Beni Paskin-Cherniavsky, Cole Mickens, Andy Gayton, Scott Nesbitt, Strick Yak, Andrew Chilton, Matthias Dallmeier, Geoffrey Thomas, Matthias Liertzer, Brit Butler, Dan Nuffer, Ry4an Brase, Dawn Luoma, Chhi’mèd Künzang, Duncan J, Vivek Gani, Gaelen Hadlett, TJ Rothwell, Lucas Dohmen, Derek Waters, Igor Cananea, Colin Barrow, Kevin Baker, Richard Thompson, whitequark, Michael Fitzpatrick-Ruth, Jonathan Castello, Michael Powell, Ryan Kelly, J. Ryan Stinnett, William Kilmer, Kenny Rachuonyo, Lionel Debroux, Bastian Allgeier, John M Cooper, Tako Marks, Børge A. Roum, Alex Morega, Bruno Orcha García, mike nonemacher, Andy Burnett, Phil Kates, Lucian Carata, Gregg Cooke, Kevin C., Séamus O’Connor, Tim Kiekhafer, Derrick Southerland, Simon Clausen, queria, Simeon Farwell-Miller, Shyam Paryani, Sascha Zelzer, Jared Sohn, Daniel Dornhardt, Maftoc, Jake Rayson, Brandon Peters, Joshua Wise, Randall Leeds, Kit Stubbs, Ph.D., James Warner, Ben Rog-Wilhelm, Andreas Rohlfs, Konrad Scorciapino, Arne Neumann, Ben Cohen, James Synge, Johannes Krampf, Bryan Luoma, Martin Krafft, Jim Garrison, Kingdon Barrett

Upcoming events in San Francisco & Portland

By Asheesh Laroia - 17 Jun 2015

David, Jade, and Asheesh will be speaking at events in Portland, OR, and San Francisco.

San Francisco meetup, June 18

At our second SF meetup, we’ll have a brief intro by core dev David Renshaw about the new sharing features of Sandstorm. We’re lucky to have David in town, as he’s normally in Pittsburgh.

Co-founder Jade Wang will showcase how to package a Meteor app for Sandstorm, which is a preview of her jQuerySF talk.

That’ll be at ThoughtWorks (thanks to them for hosting!) in San Francisco, 6 PM Thu 6/18. RSVP here!

jQuerySF, June 22-23

At the upcoming jQuerySF conference, Jade will give a talk entitled “Sandstorm.io: one-click, deploy anywhere.” It’s at 11:10am on Monday, June 22.

If you haven’t bought a ticket yet, use our Friends & Family of Sandstorm discount code to register for just $20, saving a a huge amount off the ticket price. Register at the registration page and use the code sandstorm-ftw!

Open Source Bridge, Portland, OR, week of June 22

I’m giving two talks at Open Source Bridge, and would love to see Sandstorm-minded people there.

• Economics of Volunteer Labor: Three stories from Debian, Tue Jun 23, 10am
• Five years, 1000 students: The story of Open Source Comes to Campus, Thu Jun 25, 10am

I hope to see you in SF or Portland! Feel free to drop me a line; I’m asheesh at sandstorm.io.

Should apps get network access by default? Android vs. Sandstorm

By Kenton Varda - 10 Jun 2015

Google’s Android team has announced that in Android M, users will be prompted to grant permissions to apps at the time the permission is used, rather than an the time the app is installed. That’s great! This will make it much easier for users to understand how permissions are being used and allows them to perform a “line-item veto” without uninstalling the whole app. This puts much more power in the hands of users, as it should be.

Unfortunately, permission to access the network is now going to be granted totally automatically. Is this the right thing to do? Android Police argues that it’s “probably okay”. But some of the arguments feel unconvincing.

At Sandstorm, we have some strong opinions on this. Sandstorm, like Android, seeks to run apps in an environment that enforces a strong permissions model (but Sandstorm targets servers rather than phones). Part of Sandstorm’s security promise to the user is that apps are “confined”: they have no communication with the outside world unless and until the user grants them permissions. This promise is probably the most controversial part of our security model, but we continue to believe it is the right thing to do. (Note: Sandstorm’s confinement guarantee is not fully enforced at this time, as we have intentionally poked holes in the sandbox during alpha testing in order to work around missing features. But, these will be closed over the next few months.)

So, let’s take a look at the arguments the Android team is making for abandoning confinement.

Bogus Argument 1: Controlling internet access is redundant on top of other permissions.

The Android team apparently argues that being able to disable an app’s network access is not very important as long as all of your sensitive data (say, contacts) is guarded behind other permissions checks. If you don’t want the app to upload your contacts to the developer’s server, they say, don’t give it permission to see your contacts.

This argument, to be frank, makes no sense. What if I want the app to organize my contacts (e.g. because it is a contact manager app), but still do not want it to upload my contacts to the developer’s server? The Android model seems to say that I must treat the app and the developer as one entity, which is unfortunate, but perhaps consistent with the SaaS model that Google is used to. We’d like to do better.

In fact, proper confinement allows us to do something rather magical which the Android team seems to be overlooking: If I can confine an app, then I can safely load sensitive data into the app even if the app is malicious! This in turn makes it much easier to feel comfortable using apps from random developers I don’t know. It also means I don’t need to worry too much about bugs in the app.

Moreover, even if I don’t plan to give the app any other permissions, I may still worry about whether the app might consume my resources in order to participate in a DDoS attack, anonymizing proxy service, or bitcoin mining rig behind my back.

Bogus Argument 2: The app can already leak data by opening a web page using an intent.

The Android team argues that an app can always use Android Intents to ask Chrome to open the developer’s web site, encoding my sensitive data as a URL parameter, thereby leaking my data. Because this is possible, they say, trying to provide confinement is pointless.

First, two simple responses:

1. I will likely notice if an app opens Chrome with some weird URL, and be suspicious. That’s much better than it happening in secret.
2. The app probably can’t participate in a botnet through browser intents.

More importantly, though, if intents allow trivial data leakage, perhaps that is a problem in intents. Perhaps the user needs to be asked whether or not they really want to open that link.

But would that be annoying? I actually don’t think it would be too bad. People who have installed multiple browsers on Android today are, in fact, already protected: Android prompts the user to choose which browser to use. The user can, at this point, press “back” to avoid the interaction altogether. Perhaps Android Intents should in fact prompt the user to choose an app even when there is only one choice: in fact, there is always a second choice, which is “don’t open this at all”. Meanwhile, this interstitial lets the user know that they are switching apps, which may help them be less confused.

Legitimate Argument: UX is hard.

I think that the real reason the Android team doesn’t want to implement internet access as a permission is because getting the UX right is legitimately hard. Pushing an “allow/deny” prompt in the user’s face on the first packet sent is genuinely annoying and not very helpful to the user, and the Android people aren’t feeling particularly excited about trying to develop something better, perhaps because they think that users don’t care (a popular but incorrect assumption).

I believe there is a better way: Instead of prompting the user to allow or deny internet access as a whole, prompt them for individual capabilities that the app needs, and then merge that prompt with a choice that they were already making. It turns out that most security decisions, if you look carefully enough, are in fact paired with some functionality choice. If you merge the choices together, then one of two things happens:

1. The functionality choice is a choice the user already had to make, and by merging the security choice, you’ve avoided forcing the user to answer a separate security question.
2. The functionality choice is a choice the user wasn’t already being offered, but by offering them a choice, you are giving them a real, useful ability that they didn’t have.

Let’s illustrate with some examples:

• Contacts: Many Android apps want to send “viral” invites to your friends. To accomplish this, the app first asks for permission to your contact list. A legitimate app uses that permission to display a contact picker back to you, from which you can choose the people whom you want to invite, and the app will then only spam invite those people. An illegitimate app will use the permission to spam or harvest your contacts without asking you first. (Sometimes these illegitimate apps are big names!) So what are the two choices here?
  • Security choice: Do you want give the app permission to use your contacts?
  • Functionality choice: Which contacts do you want to invite?

  Android actually provides a contact picker UI which can be invoked via an intent. When used, instead of requesting permission to your whole contact list just to show you a picker, the app asks Android to display the picker, and receives permissions only to the contacts you choose. To the user, the UX is exactly the same (they choose whom to invite), but there is no security prompt, and yet illegitimate use is blocked. Hooray!

  Sadly, many apps choose not to use this built-in picker, perhaps because developers think they can draw a prettier picker themselves and that the user doesn’t care about granting the extra permission. In my opinion, the Android-provided picker should be improved and the contacts permission discouraged – or disabled – in order to push developers away from drawing their own pickers.

• Email app: An app which wants to access your email (say, though IMAP) needs to know your server address and credentials, and then needs internet connectivity to talk to it. But can we do better?
  • Security choice: Do you want to give the app permission to talk to your server?
  • Functionality choice: What server should the app talk to, and what is the password?

  What if the platform implemented a “server picker” UI, so that the mail app merely says “I need a server address, username, and password”, the platform displays a form to the user, and then the requesting app not only receives information back, but also receives permission to access specifically that server? The user is, again, only doing something they had to do anyway: choose their server. No security prompt was ever presented, and yet the security ends up correct. (Plus, if you take it a step further by having the app proxy requests through the platform, then the platform could in fact hold on to the user’s mail server password, preventing the app from accidentally leaking it.)

• Locked-in Cloud API: Say a scheduling app wants to talk to the Google Calendar cloud API. The app only integrates with Google Calendar and no other service. Here we see an interesting side-effect come into play:
  • Security choice: Do you want to give the app permission to access your Calendar account?
  • Functionality choice: Which account do you want the app to use? (If you have more than one.)
  • Freedom choice: Which server do you want the app to talk to?

  In this case, Android actually has an account management system and picker UI which handles the first two choices as one unit, exactly as I’d like. But I am not allowed to choose which server to use – I am locked into Google’s server. What if there is a third-party service – or open source server app – which I would like to use which has implemented a Google-calendar-compatible API? As long as the API is implemented correctly, I ought to be able to make apps use the alternate service, rather than be locked into Google.

  If the security choice is mandatory anyway, and it is done in a fine-grained way (i.e. the request is for a specific server, rather than arbitrary network access), then the freedom choice can naturally be provided at the same time, without the app even knowing about it.

The Powerbox UI

All of the examples above will be supported through Sandstorm’s “Powerbox” UI. In general, the Powerbox is an arbitrary picker which can be invoked by any app and extended by any app. Underlying the Powerbox is the Cap’n Proto RPC protocol, which naturally represents capabilities (as granted by the powerbox) as RPC object references, automatically taking care of permissions and message routing.

We have been laying the groundwork for the Powerbox for some time. The infrastructure is ready, and we are now working on giving it a UI. This will happen gradually over the next couple months.

Even without the Powerbox, Sandstorm is highly usable today. Try the demo, install your own (it’s open source), or preorder hosting.

Sandcats.io: free dynamic DNS for Sandstorm users

By Asheesh Laroia - 18 May 2015

Sandstorm is open source server software that makes it easy to install web apps like Ethercalc or Let’s Chat. But that’s not much use if your server doesn’t have a name, and setting up DNS correctly for Sandstorm has until now been a complicated, fiddly process.

That’s why today I’m announcing sandcats.io, a free dynamic DNS service for Sandstorm users. It now takes 120 seconds to go from an empty Linux virtual machine to a working personal server, DNS and all.

The Sandstorm install script asks you what subdomain you want; if you type alice, then your server is online at alice.sandcats.io.

It’s as simple as that. Check out this 30 second ASCII screencast.

Solving DNS for Sandstorm users

I say it solves DNS for Sandstorm users because the sandcats.io service handles all the following complications:

• Domain provisioning. You type the name you want for your server while running the install script.

• Wildcard DNS. Sandstorm needs wildcard DNS because, with its security model, each session of each app runs on a unique unguessable subdomain. This protects against most cross-site request forgery attacks, for example. Sandcats.io provides wildcard DNS; this also means that any time a user runs a new app on your personal Sandstorm server, DNS is already configured.

• Automatic updates. Every 60 seconds, your Sandstorm server sends a small UDP message to the Sandcats.io service. If your IP address has changed, the service replies with another short message. Upon receipt of that, your server sends an authenticated message, and sandcats.io updates its records. Our DNS records have a 60 second TTL, so if your IP address changes, it will propagate out within two minutes, and you never had to lift a finger.

• Domain recovery. If you lose your authentication keys, you can recover the domain by typing help into the Sandstorm installer.

I’d love to hear your feedback; I’m [email protected].

The code is open souce, and you can read more in the technical documentation, but what I really recommend you do is try it out.

Switch to your own domain whenever you want

The Sandcats service is optional. If you already have a domain of your own, you can join the many other people actively running Sandstorm on their own domain.

If you know you want to go it alone, the install script allows you to opt out and configure DNS yourself.

Moreover, if you start out with a sandcats.io sudomain, and you decide you want a little more personality to your server, you can reconfigure it at any time. Look for your server’s sandstorm.conf file.

Install Sandstorm now to try it out

Sandstorm exists to make it easy to run web apps like Etherpad, HackerSlides, Let’s Chat, and others as easily as you install apps on your phone. If that’s something you want on a server for you or your organization, I hope you install Sandstorm right now.

Install Sandstorm with our easy install instructions!

First San Francisco Meetup

By Asheesh Laroia - 14 May 2015

Last Thursday, May 7, I helped organize the first event of the new Sandstorm SF Bay Area meetup group. The event was a Project Night, modeled after the Boston Python Project Nights that Jessica McKellar, Ned Batchelder, and I helped start a few years ago.

Project nights are unstructured chances for Sandstorm developers & users to work together, mentor each other, connect socially, teach, learn, or do whatever else it is Sandstorm users & developers want to do together.

I started with a brief introduction to Sandstorm, to ensure new people had some context.

After that, we laptopped and chatted. Here are some highlights from photo album.

Thanks to Jack Singleton and Thoughtworks for hosting the event, and to Ti Zhao for the wide panoramic shot.

If you’re near the San Francisco Bay, get notified of the next event and join the Meetup group!