Sounds cool but I think the WordPress implementation is TERRIBLE: it depends on a WordPress fork that is completely outdated, instead of downloading an up-to-date fresh archive.
I agree -- the current WordPress package needs work. Thank you for trying it and looking into it!
Community-wise, one thing we're going to need, as Sandstorm grows, is an ecosystem of app package maintainers. Part of what we're hoping is that more developers of the apps themselves will maintain the Sandstorm ports, like Audrey Tang is maintaining the EtherCalc port.
Tech-wise, one thing we're going to need is a solid story for how Sandstorm packages will easily stay up to date with the latest changes as the upstream author releases new updates.
I work on+for Sandstorm, and I'm also a Debian developer. Debian is not a shining example with regard to either of the above, and I'm sure we can do even better at Sandstorm.
It's not currently possible to run arbitrary Docker containers through Sandstorm, since we prefer app packages (we call them SPKs) to be:
* Self-contained -- if the app needs MySQL, bundle it;
* Able to run with external network access unavailable -- this improves security, since even if an app gets compromised, it's not a big deal since it can't leak any data out to the world;
and a few other constraints that are more technical than philosophical.
We actually don't want apps to bundle MySQL -- we'd prefer they use sqlite. :) But the point is, it's up to the app. The app gets a slice of filesystem and they can use whatever infrastructure they want to store stuff to it.
We want the experience for users to be install app, use app, without worrying about setting up databases and such. We also want to enforce isolation between apps so one app cannot access another's data, and that's a lot easier to do if they aren't sharing a database. Considering these desires, it makes sense to say that apps should simply bundle their database of choice.
Even so, I don't see how you could distinguish between a compromised app sending data to the outside world and an uncompromised app doing the same as part of its normal operation.
That's just marketing bullshit. Unless the API is magic (and I don't mean advanced technology "magic" but Harry Potter "magic") it has no way of knowing what the application is allowed to send or not and therefor cannot filter. It's like saying it cannot leak data because it has to use HTTP.
> Unless the API is magic (and I don't mean advanced technology "magic" but Harry Potter "magic") it has no way of knowing what the application is allowed to send or not and therefor cannot filter.
You're assuming that Sandstorm apps have arbitrary IP network access. They do not.
Sandstorm is based on capability-based security. Any outgoing request has to be addressed to a capability representing some specific permission that the user has granted to the app. A capability might point to another app, or it might point to a specific external host that the user has designated.
More specifically, a Sandstorm app's only connection to the outside world is through Cap'n Proto RPC, which is an object-capability protocol, meaning that an app can only send requests to objects to which it has explicitly received a reference.
Of course, for backwards-compatibility, we have translation layers so that apps written to use regular old HTTP need not be entirely rewritten. You just have to tweak it to make the correct permissions request first, which has proven not very hard in practice.
Sandboxed applications literally cannot send any data by default. They can't open a connection to <whatever server>, no matter what protocol.
The goal, once they've built their Powerbox, is to then implement a set of protocol drivers which the application can use. So it still can't connect to arbitrary servers, but it can ask the user for permission to, say, connect via SMTP to <wherever>, and the user has control over that.
Yes, they could leak anything that you put in them if you allow them to connect to someone you don't trust. However, even if you do so once, most applications will be per-document - you have an instance of your document editor for each document, and they don't know anything about any other documents you have.
In short: applications can only leak what you give them, and only to people you say to give them to. They can't call back to home base without your permission or the permission of someone you've given the app permission to contact. So for all reasonable definitions of "cannot leak data", applications cannot leak data without your permission.
* Backend: Due to Linux network namespaces, the app can't communicate with the network (except over "sandstorm-http-bridge" which allows it to respond to inbound HTTP requests).
* Frontend: Due to Content-Security-Policy, the client part of the app can't communicate with any hostname other than the one the app runs on. The CSP header is set by Sandstorm, not the app.
So then it has no network access, and therefore even if it is compromised, can't leak anything.
This does hinge on the app's dynamic code only being run for logged-in users. For many apps -- imagine a Google Docs spreadsheet only accessible to people within your domain -- this is a pretty straightforwardly reasonable model. Sandstorm handles authentication for apps, so it can enforce this even if the app is 0wned.
Community-wise, one thing we're going to need, as Sandstorm grows, is an ecosystem of app package maintainers. Part of what we're hoping is that more developers of the apps themselves will maintain the Sandstorm ports, like Audrey Tang is maintaining the EtherCalc port.
Tech-wise, one thing we're going to need is a solid story for how Sandstorm packages will easily stay up to date with the latest changes as the upstream author releases new updates.
I work on+for Sandstorm, and I'm also a Debian developer. Debian is not a shining example with regard to either of the above, and I'm sure we can do even better at Sandstorm.