Habitat Chronicles

The way you have defined "developer", you have defined an idiot. An unethical, incompetent idiot.

Our purpose, as computer engineers, is to convince piles of carefully-cooked rocks ("computers") to do a very specific thing repeatedly ("computing"). Since humans are terrible at understanding specificity, we design languages and abstractions that help us encode our goals into computer-readable codes.

At no point is "build something cool" the goal other than during recreational programming; our goal is not even to build, necessarily, but to understand the requirements of our users and to help them use their resources more effectively. To this end, "cool" is totally worthless; it is a facet of design, of product, and of marketing. Let them focus on the spectacle. We must focus on the specification.

Why don't developers care about security? Because we have raised them to not care about security. We have failed to instill a desire for security into our culture. Consider: Computers have been remotely hackable since the dawn of the Internet. (Check out the history of SSH or email for terrifying examples.) We do not have the cultural norms necessary for getting security correct; we barely know how to distrust soliciting strangers on the street, let alone Martian or Christmas-tree TCP packets.

How can I help? Well, I can try to shove POLA [0] and capabilities [1] down everybody's throat, but so far, it's been like trying to convince people that the world is a globe [2].

Here's…

That's all true and well, and the Spritely website does explain what it's going to do, but it's in a lot of words and I think that this isn't easy for people to absorb. I did put together a video which does a better job: https://conf.tube/videos/watch/18aa2f92-36cc-4424-9a4f-6f2de946fbd2

But I think part of the problem is that it's very hard to explain to people in words how something is going to work. In general people better understand from experiences. That's why Spritely is actually taking a demo-centric approach... people understand better from experiences than from being told. I wrote about this more here recently: https://dustycloud.org/blog/if-you-cant-tell-people-anything/

Which is a response to Chip Morningstar's article, "You Can't Tell People Anything": http://habitatchronicles.com/2004/04/you-cant-tell-people-anything/

... which has a really interesting quote in it about how baffled people were about the idea of hyperlinks:

> Years ago, before Lucasfilm, I worked for Project Xanadu (the original hypertext project, way before this newfangled World Wide Web thing). One of the things I did was travel around the country trying to evangelize the idea of hypertext. People loved it, but nobody got it. Nobody. We provided lots of explanation. We had pictures. We had scenarios, little stories that told what it would be like. People would ask astonishing questions, like “who’s going to pay to make all those links?” or “why would anyone want to put documents…

Well, first and foremost, Sandstorm uses Cap'n Proto because Cap'n Proto was built, first and foremost, to enable Sandstorm. :) Though of course, now it also powers Cloudflare Workers and a bunch of other things.

My favorite explainer on the object capability model is... the first half of this exceptionally long page: http://habitatchronicles.com/2017/05/what-are-capabilities/ It's worth the read, but read it when you have time to sit down.

So access to apps or documents by users, as well as those apps and documents being able to reach out to other resources, is all generally wrapped in capabilities.

I think as a self-hosting platform, the biggest advantages of Sandstorm is that we force developers to provide a no-config-file, no-sysadmin-required experience, so Sandstorm is probably the only self-hosting platform currently intended to be used by people who are not tech people. This naturally flows into some other things: If you don't have a sysadmin running it, it needs to be really secure (capabilities) and very good at self-managing it's own performance.

So Sandstorm apps do not consume any resources unless you are accessing them. Everything is spun up and closed down on demand. And the platform's security model not only means vulnerabilities in apps mostly aren't exploitable and apps don't need to be patched, but Sandstorm strives to safely allow non-technical users to install and run potentially even malicious apps without risk.

This is a really good question. You would want to ensure that the templating library cannot get access to the http request library unless the templating library is explicitly given a reference to it. So even though both libraries are imported, they can't access each other by default. Realms (the standards track proposal [1]) lets you do this, and Salesforce uses it right now as the security kernel that ensures that their third party apps can't view or mess with other apps [2].

The best way to enforce POLA, and especially this particular problem of not allowing libraries to have access to each other, is object capabilities (ocaps) [3]. An object capability combines designation with authority -- if you have access to a capability, you can use it. If you don't have access, you can't use it. You can think of this (very roughly) as a key to a car as opposed to your name being on a guest list for a party. I didn't really touch on ocaps in this piece, but it's a necessary component for being able to enforce POLA well.

[1] https://developers.google.com/caja/

[2] https://www.youtube.com/watch?v=3ME7oHHQbuM

[3] http://habitatchronicles.com/2017/05/what-are-capabilities/

Seriously. Considering the existential risk the AI Safety tribe says exists if sufficient care is not taken, they appear to be existentially incompetent in their messaging. It should be their number one priority to convince the legion of competent non-AI engineers who will be developing and running the infra for their systems to come to their side. Currently they seem to be failing spectacularly.

If it wasn't for others in the AI community vouching for their chops it'd be easy to mistake them for Philosophy of Mind majors going by their tweets. They need to convince their fellow engineers not politicians. Right now when people hear "safety" for AI they think "regulation by incompetent bureaucrats".

The AI safety people need to remember that "you can't tell people anything", you have to show them [0].

[0]http://habitatchronicles.com/2004/04/you-cant-tell-people-anything/#

Bash may need a high level of authority as it's spawning processes and wiring them together, but those processes don't necessarily need to have as much access as you do themselves.

Take the venerable `cowsay` for example. Currently, running `cowsay` (as with any other program) can cryptolocker your hard drive, delete all your files, reach out to arbitrary servers on the internet, etc. But how much access to your system does it actually need to do its job? Well, mostly... STDIN, and STDOUT, really.

Yes, actually doing this is complicated. Another reply has linked to some broad info about object-capability security, but here's a good introduction to the subject: http://habitatchronicles.com/2017/05/what-are-capabilities/

...and this paper is an excellent deep dive into a capability system: https://mumble.net/~jar/pubs/secureos/secureos.html