We don't think monolithic firewall-based security has been very successful at preventing hacks. Our goal is to create an environment that involves much more fine-grained separations, and enforces security properties at the platform level so that bugs in apps are largely mitigated. We want you to be able to deploy apps without having to security-review them first, which means the platform itself must provide guarantees.

Arguably an app-driven SSRF is a pretty big problem in that threat model. I think we missed it earlier because we imagine a future world where people don't expose unauthenticated services on the internal network and rely on their firewall to protect them. Of course, we need to keep in mind that the existing world isn't going to go away when people deploy Sandstorm and so we need to handle both worlds gracefully.

Another point to make is that we do envision use cases where someone sets up a personal server and invites their friends to it to chat and collaborate -- usually as "visitors" (can't install apps), but sometimes as full users sharing one server. Typically you'd only invite trusted friends to be "full users", though, unless you are running a hosting service. Hosting services (like ours) ought to be extra-careful with multiple layers of security.

That's an argument people have been making for at least 10 years, and it falls apart pretty quickly: how secure do you think most companies would be if you opened up all their AWS security groups to the world?

Right. As I said, it's not the case today, for most companies (with Sandstorm ourselves, as a company, being an exception). With most infrastructure people use today, leaving services unauthenticated makes life easier, so people are going to do it.

One of the goals of Sandstorm is to make it easy to connect services to each other where desired without making them open to the world, with the goal of solving this sort of problem.

> In the enterprise, there is already F5, NIDS etc so nobody can get in.

Completely aside from the fact that there are thousands of breeches that prove that statement wrong, one must also be concerned with insiders, credential theft attacks, and tons of other threats that a monolithic 'build a wall' security model doesn't solve.

Sandstorm's model is close to what I call MSaaS, or managed software as a service. These services can be managed as a SaaS service on prem, yet still be hosted inside a company's network. The equivalence can come from companies selling software "services" by doing deployments of different required SaaS "packages" which can be accessed as a whole.

I think it's extremely important to highlight the security requirements for this type of business model deployment and don't think that focusing on security shouldn't be occurring just because it's running code in a private location.