344 CHAPTER 13 Languages and Security PCC has several complications. For example, how does one generate the proof? Proofs can be generated by a compiler or they can be con- structed by the developer. There has to be some agreed upon definition of what operations the program is permitted to perform and what oper- ations are considered "bad." This policy must be constructed by some trusted party, be it the com- piler writer or some other person. The policy may specify a set of data invariants, or it may specify system calls that are not allowed to be executed. The generation of a good policy is the linchpin in the whole system. If the policy is too strict, then too many programs would be considered unsafe. If the policy is too lenient, then malicious pro- grams will be allowed to execute. Other researchers have extended PCC to other domains, such as authentication. In Proof- Carrying Authentication (PCA), a subject who wishes to access some object (be it a server or allocate for data. This allows for a program that is executed multiple times to have different heap layouts, minimizing the chance for an attacker to determine where critical heap data is stored. 13.5. PROOF-CARRYING CODE AND AUTHENTICATION As described in Section 13.3, it can be difficult to ascertain what a program will do at compile time. So how can we increase our confidence in the software we are using beyond the simple "trust the vendor"? One such technique is to use run- time contracts, such as the one employed by the Android OS with third-party applications. When installing new applications, the installer notifies the end user on what the application will do and what information the application will access. These permissions are statically defined in the application. This solution is fine for the Android