web commit by NealWalfield: Create.

1 files changed, 22 insertions, 0 deletions

diff --git a/destructiveinterference.mdwn b/destructiveinterference.mdwn
new file mode 100644
index 00000000..4def1b87
--- /dev/null
+++ b/destructiveinterference.mdwn
@@ -0,0 +1,22 @@
+Interference can be destructive or non-destructive.  When a principal
+invokes an object (thereby requesting a service) and the implementation
+carries out the principal's intent, the interference was non-destructive
+in the sense that the interference was desired.
+
+In invoking the object, the principal may make itself vulnerable to
+destructive interference.  When a user runs Solitaire on Windows,
+the Solitaire program is instantiated and given all of the user's
+authority.  The program may delete all of the users files after
+publishing credit card and other sensitive information on the Internet.
+This type of interference is undesirable, however, generally practically
+unavoidable due to the way programs work on Windows (and Unix, for that
+matter).
+
+The problem is that the callee has induced negative consequence for caller
+due to actions of the former.  To not have to depend on another program (and
+thereby not have to add it to its [[tcb]]), it is necessary that the
+caller only make itself vulnerable to destructive inference in ways that
+can be detected and from which it can recover.
+
+Mark Miller examines the idea of destructive interference in his PhD thesis
+[Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control](http://www.erights.org/talks/thesis/).