Today we build web applications with general purpose language runtimes. Osgood is an experiment that asks the question: "What if we built a runtime specifically for web apps? What kind of benefits can we get from being at a higher level of abstraction?"
Since the Osgood runtime has intimate knowledge of the routing table we get the ability to isolate controllers for free (we refer to these as Workers). The I/O performed by the application, as well as policy enforcement, happens in Rust-land. Each worker has its own set of permissions.
Consider the situation where Controller A has permission to send a message to evil.ru, and Controller B has access to user credentials. Within a properly configured Osgood application this means it's not possible to transmit user credentials to evil.ru.
(Incidentally our main product transparently provides similar isolation for Node.js apps. The architecture ends up looking quite different because Node.js wasn't created with this concept in mind)
Looked around your readme and wiki but didn't see anything about this vs. deno? Both are Rust wrappers around V8 with privilege mechanisms. Am I missing anything?
Edit: well one difference is that this isn't TypeScript. This is only the subset that is JavaScript.
Good question! Deno has four policies that I know of:
--allow-write
--allow-net
--allow-env
--allow-run
Today these policies are all-or-nothing and they are global to the entire Deno process. Consider and application which _only_ needs to make a GET request to a single GitHub API endpoint. This application will then use the `--allow-net` flag and will be able to communicate with arbitrary sites like evil.ru.
However, with Osgood, the permissions are much more granular. One can specify a policy to only get access to _exactly_ what is needed. The permissions are also granular enough to only apply to a subset of the overall application:
We will add further policies where it makes sense, such as with filesystem access. However, Osgood doesn't aim to be a _general_ platform for running code, so we will likely expose filesystem access in a manner akin to this:
Having the ability to whitelist particular URLs (or at least domains) is really really cool. This would prevent (or make much harder) many of previous npm packages hacks.
Maybe you guys should work together with deno team on exchanging these ideas? Anyway, great work!
> Today we build web applications with general purpose language runtimes. Osgood is an experiment that asks the question: "What if we built a runtime specifically for web apps? What kind of benefits can we get from being at a higher level of abstraction?"
Isn’t this also the PHP, Allaire ColdFusion, and ASP/ASP.net experiment, each making a very different set of tradeoffs? Or successors such as OpenRESTY with built in LuaJIT?
It’s true a lot of “we” think web apps are built in general purpose runtimes, but plenty who think that’s lower ROI, so there’s a body of prior art here.
Excited to see experiments continuing this direction. Also consider looking back over past 25 years to when that question was first experimented with — which concepts stuck the landing, which concepts were left behind, and why.
Today we build web applications with general purpose language runtimes. Osgood is an experiment that asks the question: "What if we built a runtime specifically for web apps? What kind of benefits can we get from being at a higher level of abstraction?"
Since the Osgood runtime has intimate knowledge of the routing table we get the ability to isolate controllers for free (we refer to these as Workers). The I/O performed by the application, as well as policy enforcement, happens in Rust-land. Each worker has its own set of permissions.
Consider the situation where Controller A has permission to send a message to evil.ru, and Controller B has access to user credentials. Within a properly configured Osgood application this means it's not possible to transmit user credentials to evil.ru.
(Incidentally our main product transparently provides similar isolation for Node.js apps. The architecture ends up looking quite different because Node.js wasn't created with this concept in mind)