Transparency is a feature that shipped in the second version of the CLR, but it’s one that’s easy to overlook unless you are concerned with partial trust scenarios. The goal of transparency is to reduce the amount of security-related work for developers who write libraries or frameworks intended for consumption in partial trust.

If partial trust code can call your assembly, it’s important that you audit your assembly to ensure that no caller can elevate its privileges and execute code it shouldn’t have access to. Unfortunately, code bases can become very large, which makes this review very time-consuming. This is the exact situation where transparency is designed to help.

Imagine partitioning your assembly into various layers with regards to security and elevation of privilege. One layer can include all the code that doesn’t do anything interesting from that point-of-view. On the other hand, the code that does is placed in another layer. The first layer is called transparent code, and the second is called critical code.

The transparency feature concretizes these layers by enforcing that transparent code cannot leave you exposed to elevation of privilege attacks. The CLR supports this by saying that everything that transparent code attempts to do that requires permissions will require the same permission from the entire call stack. This means that LinkDemands are converted to full demands, and any transparent code that calls unverifiable/unsafe code faces an "injected" demand for unmanaged code. Transparent code also cannot assert for permissions.

The beauty of this model is that in most cases, the amount of transparent code far surpasses the amount of critical code. This significantly reduces costs for library developers for investments in security audits and security testing, because only security critical code need be considered.