TL;DR: apps should run on moons and their access to each other's data managed by a server running on your ship.
Right now, an "app" on Urbit is more like a desktop environment. Apps have access to all of your data, and manage your interaction with your Urbit. Basically, the TempleOS security model.
But in the words of ~wicdev-wisryt, Urbit is eminently securable (X).
Other proposals have been proffered, typically requiring a VM application to run on top of Urbit, which you would run apps inside of.
I dislike this because it reduces Urbit from a computing platform to merely a networking stack. It's also a lot of work, and it seems easier to leverage Urbit's existing architecture to achieve security, rather than retreat into a VM-inside-a-VM.
I think a more Urbit-like solution is within reach...
Your apps would run on moons. Your ship would run a server, Selen, to manage interprocess communication and permissions between the moons.
Viz, Selen watching over your Urbit while you sleep.
When you install an app through Landscape, Tlon (or whoever) would spin up a moon and install the app on it. Your ship's Selen would register the app's permissions (which you would have seen and approved, ala browser extensions) during install.
A moon used to host an app in this architecture is called a Pandi (plural Pandia).
To elucidate this architecture, imagine a social checkers app called Checkur. Checkur wants to enable users to chat with each other, so it wants to access (and publish to) your chat history. Specifically, it wants to integrate with the chat history managed by the (also hypothetical) Chatur app.
In this scenario:
- Checkur requests the Chatur chat history from Selen
- Selen verifies that Checkur has correct permissions
- Selen requests the history from Chatur
- Selen responds to Checkur with the Chatur chat history
This same system of permissions can enable file permissions to discriminate which Pandia can access which data on your ship itself via Selen.
(In practice, those steps can be streamlined - see the "Make Selen fast" section for some ideas)
O bright maid Pandia, the moon's own daughter, piercing & lovely among the deathless gods.
Homeric Hymn 32
No changes would be required in Urbit itself. Which is good. All of this could be implemented on top of Urbit as it exists now. Either the Urbit Foundation could develop this, or Tlon, because Selen is just a normal Urbit application that does normal Urbit things like create moons and communicate with them. Without the need to make any modifications to Urbit itself, the only remaining tasks are:
- Developing the Selen software
- Developing Pandi software
- Rigging the Tlon infrastructure to handle this
- Updating the current app ecosystem
In other words, now that I've written a blogpost, the only remaining thing is to do all of the actual work. A few quick man-years and voila!
Anyway, back to the more comfortable realm of theory...
Pandia include a manifest describing their required permissions. They also could include a list of what permissions other apps can ask of them - ie, permission to access certain data on an app needn't provide you with all of that app's data.
For example, the Checkur app we imagined earlier might have a manifest like this:
{
// Data we need to access from other Pandia
"requiredPermissions": [
{
"Chattur": [
"read_messages", "write_messages"
]
}
],
// Other Pandia can't access Checkur's data
"availablePermissions": []
}In other words, apps choose to make their data interactable from other apps. This makes things more complicated, so maybe it's better to keep things simple and just have permission to all an app's data, or not.
For sure, there should be some kind of "everything" permission that gives an app the same degree of authority as Selen. In fact, such an app could even live on the main ship, since it has full access via Selen anyway.
Such a debate belongs in a Github issue or a Zoom call or something.
Revoking or modifying access is no problem. Selen simply revises the app's permissions in its own database, and (if Pandia share data p2p as proposed in the next section) distributed to the Pandia.
What about existing apps?
When Tlon (or whoever, but I hope it's Tlon) distributes the update implementing this permission system, current applications could be grandfathered in by granting them the "everything" permission. This permission gives an app access to anything Selen has access to (ie, anything the ship has access to) and also allows it to live on the same ship as Selen.
Basically, that's what an Urbit app is right now: an app with permission to do whatever it wants, living right there on your ship with access to everything. And maybe that should exist as an option. Just not the only option.
Remember how it takes lots of requests for a Pandi app to access data from another Pandi? Well, Selen already maintains a list of which moon's have which permissions - it could simply distribute this list to its Pandia.
Auth is already built-in to moons, so you don't need the request to come from Selen to know it's legit - simply check the Pandi's permissions (using your cached copy of the permissions list you received most recently from Selen) and either give access or don't!
Selen only needs to be involved when updating this list.
Pandia, then, could be free to communicate directly amongst each other, in a mixed peer-to-peer, client/server architecture.
It's possible that full, actual network requests won't even be necessary most of the time. Usually (though not necessarily!) Pandia will all run on the same machine, along with their Selen. Thus, they could communicate via local sockets. Or, even faster, they could use a vane like the upcoming %lick to take advantage of the underlying OS's native IPC mechanisms.
Really, the question above is just a particular instance of the more general question: What is the fastest way to communicate among Urbits running on the same machine? Whatever the answer to that question is, should also be applied to Selen.
Yet, the fact remains...
Process isolation bears an intrinsic performance penalty. I once saw a site called Make Linux Fast Again. Their tip was literally to just boot the kernel with mitigations=off.
TempleOS runs blazingly fast by simply running every process in a single shared memory space with no oversight. Buffer overflow? More like writing into another process's memory.
However, the optimizations outlined in this section would go a long way towards making this have, at worst, a negligible impact on performance. Furthermore, I'm sure other engineers will have many more ideas for how we can make Selen fast.
As we moon-dwellers learned long ago, there's no such thing as a free lunch.
Running process isolation and IPC as a normal application casts Arvo as a microkernel; consequently, I wonder what other fundamental architectural components could live on a ship and do important things, once userspace apps have moved to moons.
Selen and her Pandia blur the line between p2p and client/server, which matches the relationships of moons to their ship as described in urbit.org/blog/iot. The Selen/Pandi architecture even fulfills the doe-eyed hopes outlined in that same blogpost:
Moons are the undeveloped wild outback of Urbit, with a story waiting to be told that promises to be as enormous in scale as the cloud personal computing story told by planets, and possibly even more so.
Maybe if I get my way, the next big blogpost about moons will reside at urbit.org/blog/appsec.