[Jyaif]

> there’s no way you can restrict mysubdomain.foo.com/phonehome vs mysubdomain.foo.com/normal

Of course you can!

With capabilities you can tell a program: "if you want to communicate with the external world here's the only function you can use :

`void postToMySubDomainSlashWhatever(char* payload, size_t size)`

[vlovich123]

Ok great. Now I put the phone home stuff within payload. It’s a game of whackamole you’re bound to lose. Like I said - if I control both endpoints, it’s going to be very hard for you to simultaneously give me a pipe connecting them while controlling the set of messages I’m allowed to send.

[bestorworse]

Sure, like you said, having control of the endpoints you could communicate anything if you can transmit bits. That’s unavoidable.

But don’t lose the perspective on the benefits of such an architecture. Considering the networking access example:

* If your process gets compromised it won’t be able to access the attacker’s C&C server. It wouldn’t have access to any other stuff that the process didn’t already have for that matter.

* You wouldn’t be able to use http. It would be https only.

* Your process wouldn’t need a lib to talk HTTP. It would just need to talk the IPC protocol (whose wire-format and related details are standardized in Fuchsia which allows for the binding code for (de)serialization to be auto-generated).

* You wouldn’t be able (for better or worse) to mess with SSL certificates, proxies, DNS resolution, etc.

Consider another example -- file access. Say your app wants to access a photo. It doesn’t have access to the filesystem nor to the user’s folders -- it only has access to, say, an “app framework services” capability (eg. services from an UI-capable OS like Android) whose one of the “sub-capabilities” is requesting a photo. When your app does that request the ‘system’ opens a file selection GUI for the user to pick a photo. Note that the photo picker GUI is running on a different process and your app doesn’t know and can’t access anything about it. All that matters is that your app will receive an opened file handle in the end. The opened file handle is a capability as well. The file handle would be ready-only and wouldn't need to actually exist in any file system. In this example, before handing the file descriptor to your app, the “system” (or whatever process is implementing the ‘photo-picking’ capability) could process the image to remove metadata, blur faces, offer the user to edit the image (and maybe actually save it to a persistent store), log that access for reviewing later, etc.

(We already have something kinda similar in Android, but the implementation is not from first principles, so it’s very complex and prone to issues (requires an obviously non-POSIX Android userspace using lots of security features from the Linux kernel to sort of implement a microkernel/services like architecture)).

EDIT: adding the detail that Fuchsia's IPC lang ecosystem has autogen features due to its standardization.

[vlovich123]

I really don’t know what point you’re trying to make. I am 100% in favor of capabilities and think it leads to better decomposed software with better security boundaries (provided the software engineers put in the work to separate components across process boundaries and the APIs make it convenient to do so).

All I said was that capabilities don’t solve the spyware problem and they largely don’t. They help protect you write software that itself can’t be hijacked to become uncontrolled spyware due to a compromise but if I am selling you software with “malware” bundled you’re going to have a hard time isolating the functional and “malware” bits (malware here being defined as software against the users wishes and intents).

You’ve extolled the benefits of it and they’re great and I think I largely agree with all of that, but it’s completely irrelevant to my initial point that it’s not a silver bullet for the vendor intentionally bundling malware into the code they’re distributing.