Java Security Manager has a rich history of leaking capabilities to code that should not have them. As has practically every capability-based system ever.
Capabilities are no Silver Bullet. They work exceptionally well with small teams, but like memory leaks, reachability decisions tend not to scale to very large teams, and people start exposing information for a feature without being able to trace the consequences of having done so.
I could potentially see someone recasting this story as a parable against shared state, but I'm not convinced it's the sole cause or that you could have one without the other. I think it is true that they share a problem space, but that's neither a particularly brave nor illuminating statement.
Do you have a favorite alternative to the capability model that you feel is superior? I somewhat casually follow these discussions and I'm always looking for new ideas (or old ones that actually work better in some cases).
The weird thing about the security APIs in Java is that it contained both capabilities and an ACL model with a sort of hierarchy to it, both of inheritance and being able to run a function in a scope. I got to use it for real on a project and if you overlooked the extreme clunkiness of trying to capture a set of rights as configuration, it wasn't that bad.
So I could say, do that again but with a better way to define rules programatically instead of a priori. Multi-tenant, multiple roles, or a Cartesian product of the two sort of demand a little bit of bespoke rules engine work.
Except Java has support for shared memory between threads, whereas WASM is single-threaded with message passing. Don't expect e.g. to implement a high-performance multi-threaded database in WASM anytime soon.
