Fun todo: Install this somewhere, nmap it for open ports, then ask "How many of these services had a remotely exploitable CVE in the last year?" "If one of these services had one tomorrow, would I know to patch it and take action faster than someone would takeover my box?" I don't see any containment mechanisms on any of these services beyond what's included by default so a compromise of one service likely leads to total compromise of the entire box.
I had to think about this a lot with AlgoVPN (https://github.com/trailofbits/algo), and we built a system with no out-of-the-box remote administration, strong isolation between services with AppArmor, CPU accounting, and privilege reductions, and limited third party dependencies and software. You can't count on a full-time, expert system administrator.
For some things, I'm happy to use SaaS providers, where they are responsible for the whole stack. For others, I'm happy to use apps, where they just provide the code, and I provide the platform. But for a number of things, I want something in between: I provide storage and compute, they provide code and operations.
Bitwarden for me is a good example. They're a password manager who provides their backend as a docker container anybody can run. I like that, as I don't really want them to have my data, and if they go out of business, I don't want to be cut off from my passwords. But I won't run the backend myself, because I don't have the time and expertise necessary to make sure it stays secure.
Another good example is photo hosting. I would rather keep all my photos on space I control. But I also need modern, maintained software for syncing, serving, and controlling access to photos and related data. I'm happy to pay somebody to make and maintain that software, but not nearly as happy if that means that at any point they might shut down and take my data with them.
I suspect we're headed toward a future where people like Synology and Digital Ocean sell storage+compute, and then other companies sell and maintain user-selected software that runs on those environments. Basically, some sort of app store for servers. But I'd love to see this happen in an open, nonproprietary way, as the drawbacks of Apple's and Google's app stores have become pretty clear.
The notion that every document is its own independent unit sounds pretty menacing to me. Could be fine for some things, but getting things running there is sounding like a fair bit of work to me, and very limited.
And then this part is especially bad: "[maybe someday] You won't have to deal with payments | Eventually, we hope to make Sansdtorm implement in-app purchases and deposit the proceeds directly to your bank account"
Right there a lot of incentive to integrate has leaked out. "Please build for our platform in exchange for no money" is not quite the worst offer I've had, but it's definitely not appealing. Looking through the Wayback machine, I see
But the part that really concerns me is that they seem to think that server apps can run like mobile apps. To me one of the most powerful things about SaaS products is that the aggregated use information drives both product and operational improvements and allows rapid response to bugs and issues. So as a developer choosing between this and a SaaS approach, this feels like having one foot in a bucket to me.
For example, I recently outsourced my mail hosting to Fastmail precisely because I want experts to run things. Would I be happier if the data were stored somewhere I control? Definitely. But not if that means the experts aren't paying attention anymore.
But the end goal is pretty well worth it: Any grain is incredibly secure by default, and for the most part, app vulnerabilities are irrelevant. A grain where only you have access doesn't need any sort of authentication or security in the app at all. And since each document is it's own sandbox, sharing a document with someone doesn't give them a way in to exploit access to your other documents as might happen with a vulnerability in a more traditional design.
The business model story for selling Sandstorm apps isn't super great right now, you probably could have a licensing model that requested network access through the Powerbox to check the license or something, but in many cases, there's already a wide variety of great open source apps that are free and just frustrating to host and manage without a platform like Sandstorm (or Cloudron). (EDIT: Now that I think about it, Sandstorm used to have a paid license key/feature key system that made no callbacks, I think the licensing info was encrypted asymmetrically.)
As for your support of SaaS data collection, I just can't really agree with you: People who want to give data to a developer can choose to do so, but I think it's ethically wrong to collect data without permission. (Sandstorm servers do have the ability to opt in to provide basic app usage data back to Sandstorm's development team.)
I love FastMail, and have been an enthusiastic customer since 2016. :)
> But the part that really concerns me is that they seem to think that server apps can run like mobile apps. To me one of the most powerful things about SaaS products is that the aggregated use...
That definitely seems like the current state of affairs but I think there isn't a reason why writing server apps like mobile apps has to inherently throw away aggregated data. Especially with Google's research in federated learning, apps will soon be able to get insights across their users while preserving their privacy.
This is the same concern I have with self-hosting anything with sensitive personal information on it. Without continuous monitoring, alerts and periodic review of audit trails, it’s anybody’s guess what’s going on with all the self-hosters’ data. With larger companies that provide a SaaS solution, there’s a little more hope that someone is looking at this seriously all the time.
You can also comment out the bits you don't want from https://github.com/sovereign/sovereign/blob/master/site.yml before you run the top level playbook.
For extra security, bind ssh to localhost only and run a tor hidden service on the machine for accessing it.
If I were to provide services for me and my family (or for a small company), I won't make them publicly available at all.
I would have every device connected to them over VPN (OpenVPN, WireGuard, ZeroTier). Of course it would prevent self-registration, and would take some work to distribute keys — but by definition we are a small operation, so this is manageable.
No service would ever listen on a publicly accessible IP. The machine(s) hosting that would firewall off all other incoming connections, except the VPN and SSH for admin purposes. I hope I would be able to quickly address CVEs in these two services, plus the kernel.
A setup like this is already pretty standard with AWS, but you can reproduce it almost anywhere, including your own physical box(es).
The weakest link with this setup is the client computers. So inside the VPN you still need good security practices — but the attack surface becomes much smaller, and a DDoS becomes harder to pull off.
> Don’t want one or more of the above services? Comment out the relevant role in site.yml.