Sandstorm App Market
github.com
github.com
(Hope our actual launch isn't marked as a "dupe" of this... :) )
This will happen one day, and I hope more will follow Sandstorm's path.
I think I've heard of some approaches to conceal the actual algorithm from the computing unit (by obfuscation, or by distributing the actual calculation between multiple units), given that the software we're actively using doesn't do anything secret - and is likely to be a free and open source software, it doesn't make much sense to protect the executable code besides integrity checks.
Otherwise, if we talk about - just for example - a receiving mail server (MDA) that has encrypted mailbox storage like [1], then it really depends on how much mail you receive. For a typical personal mailbox, where the steady rate is less than an email-per-minute (and usual email size is some kilobytes, not megabytes), encryption overhead is negligible. Such server would sleep most of time anyway.
[1]: https://grepular.com/Automatically_Encrypting_all_Incoming_E...
I guess what I meant to point out is that the convenience of having a server in a data center is probably pretty significant for most people.
Physically, this is true. But politically, a well-designed personal server ecosystem is more robust than it looks against this attack.
The key is, as Kenton points out, server mobility. The server that's your whole network identity has to be able to migrate easily, even automatically, between hosts public and private.
One way to think about how mobility makes a personal server more private -- even against a global adversary -- is the epidemiological concept of "herd immunity."
For any global network, the percentage of users who demand absolute privacy is small. It works better to host your machine in the cloud. But the costs and pain points of closet hosting are acceptable for this specialty market.
What's not acceptable is a situation in which the pro-privacy users form a small isolated network which can only talk to itself, losing on Metcalfe's law. Instead they need to be externally indistinguishable from normal users. Moreover, they need to be able to switch back and forth from absolute to relative privacy -- cloaking and uncloaking, as it were.
Normal users care only about relative privacy, ie, security against all non-sovereign adversaries. Excellent relative privacy is available from an ordinary data center. "Linode hacks" happen, but less and less often.
But actually, just as the privacy-conscious users can blend into the herd of normal users, the normal users benefit from the small minority of privacy-conscious users.
Any global adversary has to assume that anyone with something to hide has probably hid it already. So cost-effectiveness concerns decrease the adversary's motivation to search in data centers. Why would anyone with anything to hide, not hide it at home? Home searches are much more difficult.
Moreover, most people computing at home probably have nothing at all to hide -- they are just normal people who care about privacy. So as long as they stick up for their digital rights, the global adversary remains politically quite weak.
A related and somewhat more tangible point: Having the majority datacenter users using the _same platform_ with the _same apps_ as the pro-privacy users means that the pro-privacy users will have a much better selection of apps to choose from. Whereas today, non-SaaS apps are rather neglected due to their inability to reach a large userbase, but those non-SaaS apps are the only things the privacy-critical users can use.
It's what you describe. They're working on it, hopefully to be released some time this year. You upload something, it gets distributed to random nodes on the SAFE network. Minimum of 4 live copies of your data, and if any of them get taken down, another copy is immediately created on another machine. This completely eliminates the need for hosted servers for most types of apps. You can upload any files, including javascript, which means you can essentially run entire SPA and other applications using this network.
http://meetings-archive.debian.net/pub/debian-meetings/2015/...
(FWIW, back when I was at Google I spent a couple years working on Google Docs sharing, so I have a pretty good idea of what is needed here. Just have to write code.)
That being said, they really do something cool if you spend some time looking at it. They tackle security issues with a good approach IMO.
Making it easier to run open source apps really is the reason I started this project, not marketing.
(Everything I wrote in this blog post is actually what I think: https://blog.sandstorm.io/news/2014-07-21-open-source-web-ap...)
What about client-side web apps? Like Chrome apps? I've been working on an open-source web app with the intention of deploying it as a client-side Chrome app that is capable of syncing to many popular services (Dropbox, Google Drive, etc) for cloud storage.
For apps that fit the model, a client-side approach can work well. There are a lot of limitations, though, that make it not ideal for a lot of apps. An incomplete list of issues:
- Basically all existing apps with server-side code would need to be rewritten to fit in this model. (Sandstorm can run arbitrary Linux binaries.)
- A large class of apps fundamentally need to be running even when you aren't present. E.g., a mail server.
- Sharing with other users, or connecting to other app instances, is tricky at best when there's no server to mediate.
- Real-time collaboration requires much lower latency than you can get when syncing through Dropbox and the like. You could maybe pull it off through WebRTC but it's much easier to use a server.
- Access control is really hard to enforce without an app-aware server. E.g. if you want to give users permission to comment on your doc but not edit it, how do you do that with dropbox permissions?
- Limited sandboxing: Generally you can't e.g. prevent the app from secretly phoning home to its developer, at least given the security model currently provided by e.g. Chrome.
PS. offtopic but can you merge this PR? :D https://github.com/google/protobuf/pull/710
I am particularly interested whether your security model could support the following: I'm working on an accounting app, and want to support letting the app automatically pull transactions from the user's bank accounts, mint.com-style. So the app needs to be able to log into the bank's websites as the user, probably using a real web browser. But I (as the developer) don't want to have access to the user's credentials or have the app capable of phoning home to me.
I also want users to have confidence that they can use third-party contributed, bank-specific plugins for pulling this data, but be guaranteed that these plugins can't steal their data or their money. A slightly difficult problem, given that once you have a bank login, you can probably use it to move money around. But curious if you have an answer to this!
The tight security of the app model is compelling, given how sensitive my users data would be.
> PS. offtopic but can you merge this PR? :D
I totally had a long-ish reply typed out but must have closed my browser before I hit "submit" -- d'oh! Sorry, will get to that now.
Of course the next question is: will any user actually understand how to set this up? I think with the powerbox UI, it will actually be quite reasonable. It would look like this:
- User installs the base app, which initially has no permission to talk to the outside world.
- User clicks "add an account", causing the app to make a powerbox request for an object implementing "BankAccountConnector".
- The user doesn't have any of those yet, so Sandstorm would guide the user through finding a matching app on the app market, installing it, and setting it up. It's not hard to imagine a reasonable UI here: You see a list of matches like "Bank of America Connector", "Wells Fargo Connector", etc.
- As part of installing an app, the user will be able to see who the author is, look at reviews, and (if they are so inclined) click through to code.
- Once installed, the connector app prompts for the user's bank credentials and then makes a powerbox request for "access to bankofamerica.com" (or whatever). Sandstorm asks the user if the app may access this site, and the user confirms.
- Everything now resolves and the user is returned to the original app, which now is able to pull data from their bank account.
This is, of course, still very vaporware right now, but that's the vision, and there honestly aren't many open questions about how it will work, just code to write.
The only part of this that seems short of ideal to me is: I want the connector to use a real web browser to talk to the bank's website, for several reasons, but chief among them is that if the website asks the user something unexpectedly (like a security question), or something doesn't work, it's easy for the user to see what is going on. That is one aspect of the client-side approach I liked: the browser running the accounting app is the same browser being used to actually fetch the data. Do you have an answer for this?
Yep. Through Cap'n Proto RPC -- or HTTP layered on top of Cap'n Proto RPC.
> I want the connector to use a real web browser to talk to the bank's website
Interesting. That does add complication, but it seems doable. Perhaps the connector grain could act as a proxy, embedding the bank's UI in an iframe, where the iframe src of course doesn't point directly to the bank but points back to the connector grain in proxy mode.
FWIW, we definitely want grains to be able to embed each other's UIs in iframes (with proper permissions), which might play a part in this.
You're saying MITM the user's HTTP connection? I can't imagine how that would work with SSL?
This might be too tricky to actually be feasible, just dreaming here! Hopefully it is useful to help you imagine cool scenarios and possible requirements.
The browser wouldn't think it's talking to bankofamerica.com. The browser would think it's talking to your sandstorm server. The user is willingly letting the grain MITM the connection so that the app can get their data out.
There would certainly be complications, though.
First, I'm still unclear on how urls work. For example, can I host a multiple wordpress blogs at multiple domains? Like jerrac.tld, foobar.tld, and example.org?
What if I also want to have other apps on those domains?
Also, how do I view a wordpress instance as an anonymous user? I couldn't figure it out.
Second, how do multiple users work? For example, a user that has editor perms in wordpress and can create Lychee and Etherpad apps, but can't do anything else.
Third, is it possible for me to install a customized version of an app? Like if I commit the crime of hacking wordpress core, could I get that to install on my Sandstorm instance?
Fourth, has anyone looked at adding Drupal 7 and 8 to the available apps?
> First, I'm still unclear on how urls work. For example, can I host a multiple wordpress blogs at multiple domains? Like jerrac.tld, foobar.tld, and example.org?
Yes, you can create multiple Wordpress instances and connect them to different domains. Note that publishing content to domains is something that only the Wordpress, Ghost, and Hacker CMS apps do currently.
Most apps are designed to be accessed embedded in the Sandstorm UI, where they get free authentication, authorization, document management, sharing, etc.
> What if I also want to have other apps on those domains?
You can always set up nginx in front.
> Also, how do I view a wordpress instance as an anonymous user? I couldn't figure it out.
The dashboard contains instructions for publishing content to your domain. (Though you can't actually do this under the demo -- you can only get a randomly-generated domain.)
> Second, how do multiple users work? For example, a user that has editor perms in wordpress and can create Lychee and Etherpad apps, but can't do anything else.
You can invite users to your Sandstorm server. Once invited, a user can install apps and create grains. Each user installs apps for themselves -- the admin does not choose the apps for them. Different users on the same server can actually have different versions of an app installed. (Of course, when they have the same version installed, Sandstorm will de-dupe behind the scenes.)
You can share grains you create with other users by clicking the "share" button in the top bar. Some apps -- including Wordpress -- offer you the ability to share different access levels here.
> Third, is it possible for me to install a customized version of an app? Like if I commit the crime of hacking wordpress core, could I get that to install on my Sandstorm instance?
Absolutely. All the tools for building packages are open source and you can directly upload packages to your server without going through the app market.
> Fourth, has anyone looked at adding Drupal 7 and 8 to the available apps?
Not yet, but it'd be cool if someone did. :)
Note that a lot of server-style apps actually don't perform so well on raspi. People seem to like to write servers in interpreted languages that are slow and ram-hungry, and server infrastructure tends not to target ARM (e.g. MongoDB last I checked). Of course, this will all improve in time, so eventually it will make a lot more sense to target this...
By the way, this is a model (click-install) employed by countless hosting providers. From that point-of-view, I don't see a clear value proposition in this project, but still wish you good luck!
Sandstorm also gives a standard interface for writing apps, where you don't have to worry about authentication or user management. And in the future I can imagine apps exposing their capabilities to other apps in the same way your mobile device can have multiple mail readers, browsers, etc.
One feature that I think would be cool is if there was a way to associate a custom subdomain with a grain rather than the auto-generated stuff like "xh37vmw0h5276mj7h5eh.blah.company.com". Being able to host at "docs.company.com" makes link sharing a lot nicer for everyone!
Generally when sharing you send a link like "sandstorm.company.com/share/xh37vmw0h5276mj7h5eh" -- the random hostname you quote is actually an implementation detail that you weren't meant to see. :)
Once a user has opened a sharing link once, the grain will appear in their "shared with me" list, so they can find it again by going to sandstorm.company.com. We will soon support sharing by other mechanisms that don't involve sending a secret link, too.
https://d85snt1c8mqgrfxcd2o1.blah.company.com/gitlab/repo/bl...
Another issue with this is because of the navigation being done with frames, those URLs are somewhat hidden from the user. I have some thoughts on this, but they may be worth saving for the issue tracker as this appears to be an issue with the GitLab port and not Sandstorm itself.
Congrats to the Sandstorm team for their awesome work. Looking forward to a huge ecosystem with the market!
(E.g. a Sandstorm app ID is actually a base-32 encoding of the ed25519 public key with which the app package is signed.)
A nice option to run your startup/project infrastructure (such as etherpad or project management) without having to trust third-party SaaS companies with your data. And avoid monthly subscriptions from 10 different companies.
It's easiest to understand if you try the 60-second demo: https://demo.sandstorm.io
You can also read about the security: https://docs.sandstorm.io/en/latest/developing/security-prac...
- Will I be able to access the apps from outside the dashboard (regular url)?
- Is there a paid support version for self hosting?
- Any quick tutorial for contributors?
- Where do I sign up for updates?
Sometimes.
Technically, a Sandstorm app can publish content to a domain outside of the shell (as Ghost, Wordpress, and Hacker CMS -- blogging apps -- do).
However, in general, this is not the way that Sandstorm is intended to be used, and not a use case we intend to focus much effort on. Apps on Sandstorm generally remove their own code for login, sharing, file management, user management, etc., and instead integrate with Sandstorm's facilities for all these things (apps written explicitly for Sandstorm never write all that code in the first place!). This has a lot of huge advantages in terms of usability and security when the app is running inside the shell, but it generally means the app is no longer suitable for running outside the shell.
Also worth noting is that running "webscale" apps is explicitly not a goal of ours. Lots of infrastructure targets the "I need to run 1 app on 1000 machines" SaaS use case, but we're aiming at the "I need to run 100 apps on one machine (or a small number of machines)" personal/business-internal use case.
> - Is there a paid support version for self hosting?
We haven't officially reached that point yet... but if this is something you're interested in, please drop us a line (sales@). :)
> - Any quick tutorial for contributors?
https://github.com/sandstorm-io/sandstorm/wiki/Get-Involved (possibly a bit stale) https://docs.sandstorm.io/ (pretty new!)
> - Where do I sign up for updates?
There's a box to join our email list in the front page banner:
you couldn't help but think of this also..