[nostrademons]

App permissions in iOS and Android are both too coarse-grained to really be considered capabilities. Capabilities (at least as they exist in something like Eros or Capsicum) are more "You have access to this specific file" or "You can make connections to this specific server" rather than "You have access to files" and "You have access to the network". The file descriptor is passed in externally from a privileged process where the user explicitly decides what rights to give the process; there is no open() or connect() syscall available to user programs.

[saagarjha]

This seems neat in theory but it is very difficult to actually do in practice. For example, let's say that you are allowed to make connections to a specific server. First, you have to get everyone onboard with isolating their code at that granularity, which requires a major rewrite that is easy to short-circuit by just being lazy and allowing overly broad permissions. But even then "a server" is hard to judge. Do you look at eTLD+1 (and ship PSL)? Do you look at IP (and find out that everything is actually Cloudflare)? Do you distinguish between an app that talks to the Gmail API, and one that is trying to reach Firebase for analytics? It's a hard problem. Most OSes do have some sort of capabilities as you've mentioned but the difficulty is not making them super fine-grained but actually designing them in a way that they have meaning.

[nostrademons]

Yes, exactly. The implementation difficulties are why this idea hasn't taken the world by storm yet. Incentives are also not there for app developers to think about programming this way - it's much easier to just request a general permission and then work out the details later.

For the server ID, it really should be based on the public key of the server. A particular service should keep its private key secret, broadcast a public key for talking to it, and then being able to encrypt traffic that the server can decrypt defines a valid connection capability. Then the physical location of the server can change as needed, and you can intersperse layers of DDoS protection and load balancing and caching while being secure in knowing that all the intervening routers do not have access to the actual communication.

[saagarjha]

Should Google and YouTube share a key? How about Google LLC and Google UK Limited?

[nostrademons]

No, and both Google and YouTube should be multiple keys. YouTube, for example, should have separate capabilities for watching videos (ideally on a video-by-video basis); autoplaying; viewing metadata; posting comments; uploading videos; viewing playlists; editing playlists; signing up for YouTube Premium; and a number of other operations. That way, somebody who has granted their software agent the capability to play YouTube instructional videos doesn't risk having their credit card charged for YouTube Premium or ruining their reputation by posting questionable spam on everybody else's videos.

Setting up the economic incentives to encourage this is a hard problem. Right now, the disincentives to this are: 1) it adds engineering overhead to secure everything behind a different private key 2) it adds PM overhead to determine what the right granularity is and what potential adversarial avenues exist 3) it creates user confusion as they're bombarded with a list of fine-grained permissions 4) it prevents tech companies from cross-selling new features and impedes new feature discovery. There's basically no reason to do it other than protecting the user, and the user probably won't know they've been compromised until long after they start using the service.

[Terretta]

One can sort of get there today combining something like attribute based access control, signed bearer tokens with attributes, and some sort of a degrees-of-delegability limiter that a bearer can pass along like a packet TTL.

Did you want it in rust?

- https://github.com/eclipse-biscuit/biscuit-rust

- https://www.biscuitsec.org/