This note explores the problem of confining a program during its execution so that it cannot transmit information to any other program except its caller. Examples are given to illustrate the boundaries of the problem. Necessary conditions for a solution are stated and informally justified. Key words: protection, confinement, proprietary program, privacy, security, leakage of data. The problem is to confine an arbitrary program so that it cannot leak data. Examples are given to show possible ways data can leak. A confined program must be memoryless and make no calls on other programs. However, this rule is impractical. A better rule is transitivity: if a confined program calls another program which is not trusted, the called program must also be confined. A trustworthy program must guard against any possible leakage of data. The number of possible channels for such leakage is large, but not infinite. Examples show that it is possible to block these channels. A simple principle, masking, is sufficient to block all legitimate and covert channels. The caller must determine all inputs into legitimate and covert channels. For covert channels, the supervisor must ensure that the input conforms to the caller's specifications. The cost of enforcement may be high, but a cheaper alternative is to bound the capacity of the covert channels. The note concludes that a classification of the ways in which a service program can transmit information to its owner has been proposed. This leakage can happen through a call on a program with memory, through misuse of storage facilities, or through channels intended for other uses. Some simple principles can be used to block these paths.This note explores the problem of confining a program during its execution so that it cannot transmit information to any other program except its caller. Examples are given to illustrate the boundaries of the problem. Necessary conditions for a solution are stated and informally justified. Key words: protection, confinement, proprietary program, privacy, security, leakage of data. The problem is to confine an arbitrary program so that it cannot leak data. Examples are given to show possible ways data can leak. A confined program must be memoryless and make no calls on other programs. However, this rule is impractical. A better rule is transitivity: if a confined program calls another program which is not trusted, the called program must also be confined. A trustworthy program must guard against any possible leakage of data. The number of possible channels for such leakage is large, but not infinite. Examples show that it is possible to block these channels. A simple principle, masking, is sufficient to block all legitimate and covert channels. The caller must determine all inputs into legitimate and covert channels. For covert channels, the supervisor must ensure that the input conforms to the caller's specifications. The cost of enforcement may be high, but a cheaper alternative is to bound the capacity of the covert channels. The note concludes that a classification of the ways in which a service program can transmit information to its owner has been proposed. This leakage can happen through a call on a program with memory, through misuse of storage facilities, or through channels intended for other uses. Some simple principles can be used to block these paths.