From the FAQ:

5.  'Saaaay, what _is_ the design of Penguin?'

    Glad you asked.

    Consider two machines, foo and bar.  A user on foo (or perhaps
    a program on foo) wishes to execute a program on machine bar.
    However, imagine that the people running bar don't want just
    anyone running code on their machine for security reasons.
    This is the normal case on the Internet, and one which the
    World Wide Web attempts to emulate with HTTP and CGI.

    Normally, there is no well-known channel for foo to transmit
    code to bar.  Further, there is no provision for the code to
    undergo verification after transmission.  Too, there is no
    well-defined way for bar to ensure that foo's code does not
    attempt to perform insecure or damaging operations.

    Penguin attempts to solve these issues while making sure the
    code language maintains some acceptable degree of sufficiency
    and power.
    
    Using Penguin, the user/program on foo 'digitally signs' the
    code that's earmarked for delivery to bar.  The signature
    encodes the code in such a way that it is impossible to alter
    the code or deny that the signer signed it.

    The code is then wrapped up into a packet and transmitted
    through a 'channel' to a Penguin process running on machine
    bar.  The channel's protocol layer is abstracted away
    enough that it becomes unimportant; Penguin code can just 
    as easily be delivered through SMTP or AOL Mail as through
    TCP/IP, DECNet, AppleTalk, whatever.

    The Penguin process on bar unwraps the packet, which contains
    further verification and checksum information, and then
    'digitally unsigns' the code, a process which provides the
    code in 'clear' form while telling the receiver who digitally
    signed it.

    The receiver then cross-references the signer's identity with
    a list of rights that the receiver associates with the signer,
    reverting to a set of default rights if the signer is unknown
    or unlisted.

    A safe compartment is then created, populated with the
    functions allowed to the signer, and told to limit the
    operations it can perform to only those permitted to the
    signer.

    The code is then compiled within that safe compartment.  If
    it attempts to do something which the signer is not allowed
    to do, or if it attempts to call a function not permitted
    to the signer, the compartment immediately traps the operation
    and throws the code away before it can execute.  If the code
    uses no unsafe or illegal operations, then it executes and
    produces a result.

    The code executing side then becomes the master in the
    transaction, and can send code to the original sender,
    send the return value back in a data packet, and so forth.
    The process repeats as necessary until both parties are
    done; the channel then closes, and the Penguin transaction is complete.

    The basic sentiment behind the idea of 'identity' being
    correlated to 'rights' in the receiver is that in signing
    the code, the signer commits her identity and her reputation
    on the correct operation of the code.

    'highly trustable' signers (as one might imagine Larry Wall,
    Randal Schwartz, and Tom Christiansen to be) might be assigned
    very high levels of trust and equivalent degrees of 'rights',
    so that programs they sign can perform very complex and
    interesting operations on your computer.  By the same token,
    paranoid sites or those wishing isolation could assign zero
    rights to everyone except for a select (perhaps internal) few.

    Part of the 'rights' given to signers include possibly specialized
    functions that encapsulate the functionality of extremely dangerous
    operations.  For instance, a store opening up on the Internet might
    put up a Penguin server which put functions called 'list_items'
    and 'buy_item()' into the limited compartments all users get.
    'list_items' might open up a file on the store's machine, read
    the contents, and spit them out -- an operation which, if allowed
    in the general case, would clearly breach security.  However,
    by creating a specialized function, the security concern is
    removed, and by letting potential customers know of the function,
    the power and ease of use are kept high.

    Niggling but important technical issues currently being wrestled
    with include the way that foreign functions are registered into
    the namespace, the construction of a foreign function framework
    so that the names and function of the functions are well-known,
    and a superior-than-current 'digital signature' method.