<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In other words, to support Browse launching Pippy when a .py file is<br>
clicked, Rainbow would have to confer upon Browse the privilege of<br>
launching other activities (which may, and in the case of execution<br>
environments such as Pippy and eToys, regularly will) have higher<br>
privileges than Browse itself, have such launched activities operate<br>
on arbitrary input provided by Browse, and not require user approval<br>
anywhere in the process.</blockquote><div><br>Higher privileges in what way? If all we're talking about is P_MIC_CAM, the problem is only for data flows in the other direction (from Record to Browse, for instance). That problem, though separate from the current use case, is real, and I have suggested a mechanism ("private" files which are not openable by an activity with P_NETWORK) which will prevent the problem data flow, once Bitfrost is further implemented (and until then, it is not actually a problem, because there's no security here anyway).<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The way to do it is to throw up a (system-, not Browse- rendered!)<br>
warning dialog indicating that a security boundary is about to be<br>
crossed, and allowing the user to stop the action -- unless this<br>
particular boundary traversal was specifically approved ahead of time.</blockquote><div><br>I agree, this is good enough, precisely because the only* attack this should allow is temporary DOS (ie, "I didn't mean to open that activity, now I have to wait until it finishes opening and close it"). Since the consequences are immediate and visible, it will condition the user to understand what's going on, not to ignore the dialog.<br>
<br>If there is another attack possible, we will need more than just a dialog for security. For instance, the private files mentioned above.</div></div><br>Jameson<br><br>*secondary spy attacks would be possible if a networked activity makes stupid or deliberate security mistakes, using settings to corrupt later instances of the same activity. These attacks would still be limited by the access of the later instances.<br>