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.
Note that Sandstorm is still in development and for the moment we've created a hack to allow ttrss to make arbitrary HTTP requests in order to update feeds.
However, in a few more months this won't be necessary. Instead, when you click "subscribe to feed", the app will call a method on the Sandstorm API saying "Prompt the user for a URL and then give me permission to access it". So, you'll get a dialog box to enter the URL rendered by Sandstorm itself. If you enter a URL, it's plainly obvious that you want the app to have permission to fetch it, so Sandstorm grants said permission. We call this UI the "powerbox".
Notice how the UX here is equivalent to what we have today, where the app renders its own prompt. This technique of inferring security decisions from actions the user was doing anyway is the core of how we plan to implement tight security without inconveniencing the user.
I've been using TinyTinyRSS on Sandstorm for a while. It even has a mobile app that works with Sandstorm's API. (Though it's a fork, not the official Play Store version.)
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.
It's worth keeping covert and side channels in mind, though: e.g. an instance can leak bits by timing variations. Capability security is a big big deal, a qualitative change in the game, but I think this comment is over-promising things.
Yes, covert side channels should always be assumed to be possible.
However, there are two reasons I think you don't need to worry about them too much:
1) They'll typically be fairly expensive and low-bandwidth.
2) They're unambiguously malicious. This is not a technical barrier to using them, but it's a huge political barrier. Today, major developers will happily stick covert statistics gathering into their code, and then when called out on it, will make some contrived argument about how it benefits users (if that's true, why don't you ask them first?) and how it's mentioned in the privacy policy so therefore it's legit. OTOH, you can't exploit a covert channel in Sandstorm and then plausibly claim you haven't done anything wrong.
Some hardcore security nerds will of course scoff at this argument, and to them I can only say: "OK, yes, there are possibly covert channels, sorry. Please don't put sensitive data into an app you don't trust."
A theoretical long-term solution is deterministic computing, but that probably requires apps to be written in a different language or be run in a heavy-handed VM. Not practical at the moment.
It's also worth noting that Sandstorm is designed to make it impossible for an app to leak capabilities via covert channels. They can only leak bits, and a capability is not just bits.
Yep, good points; I just think the GP was too absolute. It's good to hear Sandstorm's built on object capabilities instead of password capabilities; since I wasn't sure I didn't get into that, or deafening (determinism to eliminate side channels into a process; I gather that outward is much harder to control).
