Shader security model discussions: breaking it down?

As was mentioned in today's call, there may or may not be agreement on what
is required of our security model.

As a first step I want to make sure agree on a *lower bound* on the
strictness of the security model before we go into debates about further
restrictions. My understanding:

* Any memory or data access of any kind MUST NOT make data visible to the
Application other than (a) default values or (b) any data produced by the
program.
* This must be implementable in a performant way on all current, existing
target platforms. (Platform-specific optimizations like robustness
guarantees or page table controls optional.)

Beyond that, I'd like to figure out how to break down the discussion before
moving forward. Example questions (but I don't want to discuss these
questions YET):

* Do we want fully general pointer behavior, the SPIR-V restricted pointer
behavior mentioned today, logical addressing only, or something else? What
high-level language features, algorithms, and techniques might require more
flexibility?
* Is it possible to provide any kind of "fault" behavior? - e.g.,
termination of execution in such a way that IF outside data is accessed by
the Device, the Device is terminated before that data can become visible to
the Application. If it's possible, is it useful?
* Can our security model be "optional" for an insecure-mode, "native"
(C/C++) version of the API? (Useful for native platform portability as well
as apps with both native and web versions.)

What other questions can we add to this list?

-Kai