As used by NS (now available in the Web Archive) & MS (not now available), multiple capabilities may be ascribed to a program (class) automatically according to the origin of the program as (usually) evidenced by digital signatures. Which sources warrant which capabilities is manually controlled by the user. As the program runs and attempts to access something, the system considers the program and its callers to see if their collective “capabilities” provide access to the thing.
By contrast traditional capabilities are bound to program identifiers which must appear at the code site where the program accesses the thing.
The new approach may appear to unburden the program from security issues, but I claim that instead it makes the job of writing such code much more difficult and prone to security flaws. This is evidenced by Netscape’s setScopePermission scheme that Java “system” code must use over and above the normal naming of those things that it would access.
The traditional theory of capabilities concerns protected names and the authority that those names convey to the program using those names. A capability is a name of something much as “x”, in a code fragment “a + x/y” is a name of something. Such a name must be used each time the thing is accessed.
Capability theory asserts that a capability to something is necessary and sufficient to access that thing. In traditional capability systems these names are explicitly designated when used by the program. Holding a capability to something is insufficient to access that thing unless you designate that capability each and every time you access that thing. Each access is mediated by the capability explicitly named by the program that justifies that access.
Ironically Java has made a significant advance towards applying traditional capability ideas. The Java object reference serves well as a traditional capability. While Scheme and SmallTalk have similar properties their environments are not conducive to the practice of capability theory.