All packages are cryptographically signed. Two packages signed with the same key represent versions of the same app. You specify the version number in the app manifest. When a user installs an updated package, the platform offers to replace the old package.
Automatic/push updates will be implemented eventually.
does it use zerovm?
No, Sandstorm has a custom sandbox implemented on the same Linux kernel features underlying Docker. This means that existing Linux binaries can run in the Sandstorm sandbox. In fact, many of the existing apps were created by just copying over binaries from my local Linux installation.
Currently the sandbox is mostly based on chroot() and unshare(). In the future we'll lock it down more with seccomp-bpf syscall filtering.
how are unresponsive apps managed?
Currently, an app server is killed off after a few minutes of the app not being open in any users' browsers. The server starts back up the next time you open the app.
Perhaps it also makes sense to stick in a "reset" button for apps that are wedged. That would be pretty easy to implement, but hasn't been needed yet. (You can also just "killall sandstorm-supervisor" if you have shell access to the box, then refresh the app. It should come back up gracefully.)
can apps use protocols like websocket, webrtc?
WebSocket is implemented now. WebRTC is not, but certainly could be some day.
how are data backed up/restored?
Nothing has been implemented yet on that front, but eventually it will be possible to download a tarball of a particular app (or all your apps) easily, and then re-upload it to the same or a different host later.
Of course, hosts should also implement a backup solution so that users don't have to worry about data security. Any existing solution that just dumps the hard drive should work fine with the current Sandstorm implementation (just back up /var/sandstorm).
This is a bit different from -- but IMO superior to -- the Chrome Extension and Android models.
Yes please don't emulate the Chrome/Android permissions functionality (particularly Android).
Android apps often ask for broad permissions upfront just to do a one-off thing, like inviting your friends to use the app. Then they get to keep that permission for as long as the app is installed.
And it's "take it or leave it". If you're not happy you get to stop using the app/service, or you just have to bite your tongue and install anyways. Ugh.
Exactly. In the Sandstorm model, the app would ask for a list of people to invite by telling the platform to present you with a picker UI. The platform knows all your contacts, but the app only ever receives the ones that you select. Yet, from your perspective, the UI is effectively the same as what you'd see on Android.
Comments
Currently, there are no permissions; apps are totally isolated. Soon, it will become possible to grant permissions to apps through a powerbox interface. This is a bit different from -- but IMO superior to -- the Chrome Extension and Android models. http://plash.beasts.org/powerbox.html http://en.wikipedia.org/wiki/Capability-based_security
All packages are cryptographically signed. Two packages signed with the same key represent versions of the same app. You specify the version number in the app manifest. When a user installs an updated package, the platform offers to replace the old package.
Automatic/push updates will be implemented eventually.
No, Sandstorm has a custom sandbox implemented on the same Linux kernel features underlying Docker. This means that existing Linux binaries can run in the Sandstorm sandbox. In fact, many of the existing apps were created by just copying over binaries from my local Linux installation.
Currently the sandbox is mostly based on chroot() and unshare(). In the future we'll lock it down more with seccomp-bpf syscall filtering.
Currently, an app server is killed off after a few minutes of the app not being open in any users' browsers. The server starts back up the next time you open the app.
Perhaps it also makes sense to stick in a "reset" button for apps that are wedged. That would be pretty easy to implement, but hasn't been needed yet. (You can also just "killall sandstorm-supervisor" if you have shell access to the box, then refresh the app. It should come back up gracefully.)
WebSocket is implemented now. WebRTC is not, but certainly could be some day.
Nothing has been implemented yet on that front, but eventually it will be possible to download a tarball of a particular app (or all your apps) easily, and then re-upload it to the same or a different host later.
Of course, hosts should also implement a backup solution so that users don't have to worry about data security. Any existing solution that just dumps the hard drive should work fine with the current Sandstorm implementation (just back up /var/sandstorm).
Yes please don't emulate the Chrome/Android permissions functionality (particularly Android).
Android apps often ask for broad permissions upfront just to do a one-off thing, like inviting your friends to use the app. Then they get to keep that permission for as long as the app is installed.
And it's "take it or leave it". If you're not happy you get to stop using the app/service, or you just have to bite your tongue and install anyways. Ugh.
Exactly. In the Sandstorm model, the app would ask for a list of people to invite by telling the platform to present you with a picker UI. The platform knows all your contacts, but the app only ever receives the ones that you select. Yet, from your perspective, the UI is effectively the same as what you'd see on Android.