[Python-Dev] doc for new restricted execution design for Python

[Ka-Ping Yee]

On Wed, 5 Jul 2006, Brett Cannon wrote:
> On 7/4/06, Ka-Ping Yee <python-dev at zesty.ca> wrote:
> > In response to Guido's comment about confusing the words "trusted" and
> > "untrusted", how about "empowered" and "restricted"?
>
> Maybe.  I am really starting to lean towards trusted and sandboxed.

It can be risky to use words of the form '*trust*' when talking
about security because 'trust' can have different meanings in
different contexts.  (Examples: 'X is trusted' might mean 'X is
something i feel safe running without restrictions' or 'X *is*
in fact allowed to run without restrictions' or 'i need to run X
without restrictions in order to accomplish my task' or 'X is
something i am relying on for the security of my system'.)

The most common context for 'trusted' that i seem to come across
is in the phrase 'trusted computing base' (TCB), which refers to
'the thing that is supposed to be enforcing security restrictions'
as opposed to 'something i'm willing to let run unrestricted'.
So when i read 'trusted code' what comes to mind is the C implementation
of the Python interpreter, and it may be a good idea to reserve that
phrase for that purpose, if it's to be used at all.

In any case, let's try to nail down clear names for the different
pieces we're talking about here, and i gently advise avoiding
'*trust*' words or using them with very limited meaning.


-- ?!ng