Applications designed for capability systems naturally distribute access to their components to just those places where access is required.
A large application thus appears as one lump with portals only at the application interfaces required by the mission of the application.
This is in contrast to other systems where an application will have many files scattered in different directories of different machines.

The ideas that we have described for distributing parts of applications use crypto to (1) assure their own secrecy and (2) authenticate messages thus providing their own defense against spoofing.
It would seem that firewalls are unneeded to protect such applications except, perhaps, to protect the systems upon which the capability technology is built.
If the foundation systems do not need firewalls then neither do the applications.
Of course we advocate the use of such systems.

There seems to be no need for firewalls in distributed capability design.
The distributed modules of an application are invulnerable to bogus signals if we have done our crypto right.
There remains the question of the platform that a particular application module runs on.
If it runs on Unix then there are the usual fears about the integrity of that Unix platform.
Firewalls seem mainly designed to prevent hostile signals from beyond the firewall, reaching gullible Unix programs that were not designed to reject commands that would breach abstractions or damage their community.

Macintosh or Windows platforms may well be less vulnerable since they do not have so many such traditional deamons designed to obey external commands.