[cap-talk] Capabilities and Freedom vs. Safety

[David Hopwood]

Jonathan S. Shapiro wrote:
> On Sun, 2007-07-22 at 17:54 +0100, David Hopwood wrote:
>> Pierre THIERRY wrote:
>>
>>> And why should an uninspectable code be more malicious than one
>>> inspectable? Isn't it partly because code inspection isn't effective as
>>> a practical security measure that we are designing capability systems?
>>
>> A design goal of many capability systems is to make code inspection more
>> effective (in addition to constraining uninspected code).

Correction: "(in addition to constraining all code, even if uninspected)".

> Pierre: inspectable code is subject to social feedback. Uninspectable
> code is not.
> 
> David: can you expand on what you mean by that? I agree that POLA
> designs tend to be more inspectible simply because the components are of
> manageable size, but I would not have categorized this as a goal of
> capability designs.

It is an explicit goal of E, for example, to facilitate adversarial code
review. From <http://www.erights.org/data/irrelevance.html>:

# Given a question and a large body of largely unfamiliar code, the first
# job of a programming language notation is to help human readers (both with
# and without IDE help) do a quick reject: to disqualify most of the program
# as being irrelevant to the current question without needing to look at
# most of it. (See also Visible Workings.)
#
# Scope analysis is the reader's main tool for quickly determining, when
# looking at a program fragment, which things cannot influence what other
# things. Scope analysis gives a first conservative bound on possible
# influence analysis. [...]

This is not specifically dependent on E being a capability-secure language;
it's just a good idea that is generally recognized as such by designers of
capability systems. Being a capability-secure language may affect what
code properties we want to make particularly apparent.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>