<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3199" name=GENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<P>David Hopwood wrote:<BR>&gt;<BR>&gt; Alice creates a document which contains 
FooCo proprietary information,<BR>&gt; and puts it on the web server marked as 
only readable by FooCo logins.<BR>&gt; She also writes an email about the 
collaborative project, which is<BR>&gt; mostly fine for BarCo employees to read, 
but also contains a YURL to<BR>&gt; the document. She reasons (incorrectly, but 
plausibly), that it is<BR>&gt; okay to send this email to the list because the 
login check will only<BR>&gt; allow the document to be accessed by FooCo 
employees.<BR>&gt;<BR>Interesting example.&nbsp; It's almost exactly the 
situation that caused HP to announce its quarterly results a couple of days 
ahead of schedule last year.&nbsp; The only difference is that&nbsp;the 
proprietary data was in the email, not on a web page.&nbsp; Had that data been 
on a web page behind the firewall, there would have been no leak.&nbsp; The 
choice is between hoping that employees never make such a mistake and having a 
mechanism in place to protect you when they do.&nbsp; That's the essence of 
VOC.<BR><BR>The check that I proposed cut off access if the invoker wasn't in my 
domain.&nbsp; (Note that I never suggested that the check could add privileges, 
as in some of the discussion on this thread.)&nbsp; In the absence of the 
ability to keep YURLs from leaking outside the domain, as in your email example, 
not letting them back in might be useful.<BR><BR>I'm having trouble seeing how a 
strict reduction of authority can lead to a confused deputy.&nbsp; If the filter 
(Horton or non-cap) allows access, the invocation involves only 
capabilities.&nbsp; If the filter blocks the request, there is no invocation, so 
there can't be a deputy to be confused.<BR><BR>________________________<BR>Alan 
Karp<BR>Principal Scientist<BR>Virus Safe Computing 
Initiative<BR>Hewlett-Packard Laboratories<BR>1501 Page Mill Road<BR>Palo Alto, 
CA 94304<BR>(650) 857-3967, fax (650) 857-7029<BR><A 
href="http://www.hpl.hp.com/personal/Alan_Karp">http://www.hpl.hp.com/personal/Alan_Karp</A><BR>&nbsp; 
</P></BODY></HTML>