\section{Security Issues}
\label{sec-security}

Web browsers are expected to guarantee the execution of untrusted
applet code in a safe manner.  To provide this guarantee, various
measures are to be used by browsers, including the enforcement of the
host-of-origin policy. This policy disallows applets from (1)
initiating a network connection to any host other than the one they
came from, and (2) listening for network connections initiated
elsewhere.  It is apparent that the RMI mechanisms used by {\kfapplet}
violate the host-of-origin policy in providing direct applet-to-applet
communication.\footnote{Experiments were conducted using Java
Developers Kit version 1.1.3, and HotJava Browser Version 1.1 running
on Linux and Windows NT 4.0.}

The justification for the host-of-origin policy is given as ``the
intent is to prevent applets from using network connections to
circumvent file protections or people's expectations of
privacy''~\cite{sequrityfaq}, another aspect is to protect machines
behind a firewall from an attack by an applet downloaded from outside
the firewall to a machine within.  As discussed earlier, the typical
solution~\cite{bbcffp,secure-comp-java,hns97} to overcome these
limitations has been to use a stand-alone application to route
messages between applets.  {\kfapplet} has been designed to only work
for applets belonging to the same session.  In some sense, this does
not violate the spirit of Java, but only the specific technical
mechanisms.  The usefulness of inter-applet communication has been
demonstrated, and it may be possible to formally incorporate certain
inter-applet communication in future versions of Java in a secure
fashion.


%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "paper"
%%% End: 
