3 ms·

System wide capabilities is an interesting concept - I'd love to see it implemented. I'm not sure if it meaningfully fits into a programming language though - i

System wide capabilities is an interesting concept - I'd love to see it implemented. I'm not sure if it meaningfully fits into a programming language though - it seems like an operating system concept. But I might be mistaken? Firefly currently only uses capabilities for security within a single program, which I think is also a big issue in software development today, the Log4j fiasco being a recent example.

mikewarot 5y ago
Since you're in the mindset of capabilities, what do you think is a reasonable way to pipe them through the internet, or between cooperating programs on a given machine?
- continuational 5y ago
  Well, the main challenge is that you can take a capability and limit it before passing it on. For example, take the FileSystem capability and wrap it in a new object that only allows access to a specific directory. Otherwise, you could probably use OAuth! Now, Firefly makes it possible to limit capabilities with arbitrary code. But suppose you instead had a declarative format for limiting capabilities. Then you could probably represent capabilities like this: { "system": "FileSystem", "publicKey": "...", "parent": "...", "limitation": { "path": "/foo/bar" } } The publicKey is the public key of the system in question. The system should probably be a URI. The parent is the capability that was limited, encrypted with the public key, so that only the system in question can decrypt it. This allows the system to verify the capability, while not leaking the parent capability to anybody else. The limitation is a system-specific declarative limitation, and must be at least as strict as the parent capability. How does that sound?
  - mikewarot 5y ago
    That's a lot to consider, thanks! Ideally, I want something already baked as an OS, but if that isn't an option, then here's my backup plan. I want a system that could let you build a sandbox that consists of an emulator, and a pipe to the rest of the world that only speaks capabilities. This would allow you to run arbitrary code without risking the emulator by handling actual system calls. At its core, a capability is a token, which should be both authorization and address for some resource, there shouldn't be any other thing required. That is very much at odds with a channel subject to snooping. The thing is, if you have access to a single file, to keep it simple... it should be easy to write a filter that takes that access, and creates a new access that the filter then handles, to make the channel write only, or read only, a DBMS, etc. If you can run that filter on the same machine, or somewhere across the internet, no data should go around the filter. It should be possible for the filter to hide any URLS, etc. of the source capability. I'm sure those types of issues come up eventually even internally to programs, as you eventually implement the proverbial half a Lisp. If you support libraries, or units... how does a capability get passed between them? Like I said, lots to consider, thanks!

mikewarot 5y ago

Since you're in the mindset of capabilities, what do you think is a reasonable way to pipe them through the internet, or between cooperating programs on a given machine?

continuational 5y ago
Well, the main challenge is that you can take a capability and limit it before passing it on. For example, take the FileSystem capability and wrap it in a new object that only allows access to a specific directory. Otherwise, you could probably use OAuth! Now, Firefly makes it possible to limit capabilities with arbitrary code. But suppose you instead had a declarative format for limiting capabilities. Then you could probably represent capabilities like this: { "system": "FileSystem", "publicKey": "...", "parent": "...", "limitation": { "path": "/foo/bar" } } The publicKey is the public key of the system in question. The system should probably be a URI. The parent is the capability that was limited, encrypted with the public key, so that only the system in question can decrypt it. This allows the system to verify the capability, while not leaking the parent capability to anybody else. The limitation is a system-specific declarative limitation, and must be at least as strict as the parent capability. How does that sound?
- mikewarot 5y ago
  That's a lot to consider, thanks! Ideally, I want something already baked as an OS, but if that isn't an option, then here's my backup plan. I want a system that could let you build a sandbox that consists of an emulator, and a pipe to the rest of the world that only speaks capabilities. This would allow you to run arbitrary code without risking the emulator by handling actual system calls. At its core, a capability is a token, which should be both authorization and address for some resource, there shouldn't be any other thing required. That is very much at odds with a channel subject to snooping. The thing is, if you have access to a single file, to keep it simple... it should be easy to write a filter that takes that access, and creates a new access that the filter then handles, to make the channel write only, or read only, a DBMS, etc. If you can run that filter on the same machine, or somewhere across the internet, no data should go around the filter. It should be possible for the filter to hide any URLS, etc. of the source capability. I'm sure those types of issues come up eventually even internally to programs, as you eventually implement the proverbial half a Lisp. If you support libraries, or units... how does a capability get passed between them? Like I said, lots to consider, thanks!