At DEIMOS GUI day it was suggested that prospective users should be
able to run a demo of the GUI while it is still under development.

Further discussion resulted in the suggestion that, after deployment,
scheduled observers should be able to run the final GUI as a means of
setting up in advance of their observing runs.

Here are some ruminations about the implications of these ideas.
But first, a tiny glossary.

Local Dashboard
	Meaning to deploy the entire Dashboard software system (demo
	or finished product) so that it can run on machines at the
	site of the user.

Remote Dashboard
	Meaning to offer a means by which the Dashboard interface is
	available to persons sitting anywhere but the actual
	processing is occurring at a central point (demos at UCSC,
	finished product at Keck).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Issues involved in offering a Remote interface of any kind

Dashboard is currently a Tcl7/Tk4 application running on Unix.
The only means by which it can offer itself remotely is the X
Window System.

	Broadway doesn't really solve the remote problem

The X Window System is now a project of the Open Group, and its
latest release (X11R6.3) is known as "Broadway".  Broadway is
intended to permit exactly this kind of remote interface, and it
makes it possible to offer the interface within a WWW browser.
See http://www.opengroup.org/tech/desktop/x for details.

Unfortunately this WWW browser plug-in requires security features
which did not exist prior to X11R6.3.  There are apparently no
vendors who are shipping X servers that implement these features.

This means that Broadway as a means of remote GUI will only work for
those who have built their own X11R6.3.  In all likelihood such users
are already adept enough to build Dashboard locally.

	Existing, widely deployed X11 servers mean
	Security problems for the remote user

Dashboard uses the Tk send command which requires that the user be
sitting at an X server which is configured securely.  In particular
this means that the user must never have used the "xhost" command to
permit access to entire machines.  All access to the X server must
have been granted using the "xauth" command.  Even though it is a
grievous breach of security to use xhost, most users of X11 still tend
to do it.  Cognizance of the "xauth" command and its proper usage is
not widespread.

Thus, a WWW interface which offers a Remote Dashboard will require the
user to transmit the DISPLAY name and an authentication key from
xauth.  Secure transmission of this information would require that the
user have a commercial WWW browser (probably true) and that Lick or
CARA be using a commercial WWW server (not likely true).  The high
likelihood of insecure transmission would mean that the WWW page
which offered the interface should advise that the remote GUI user
terminate the entire X session immediately following the end of
Dashboard usage.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Security issues inherent to Dashboard, whether remote or local

Dashboard is capable of interacting with any KTL service for which
there exists a correctly configured KTL service library.  Naturally, a
Dashboard being used for pre-deployment demo or post-deployment
observing run setup would be configured to operate in the "fake" mode
where it could not affect any actual instruments.

However, Dashboard is a Tcl/Tk application which uses the send
command.  Developers of Tk applications are aware that this can be
used to completely change the run-time behavior of the application by
modifying the code on-the-fly.  In particular, this means that a user
of a remote Dashboard could modify its behavior such that it could
attempt to enter "engineering" mode and load any available KTL
service.  Alternatively (and somewhat easier for a hacker not familiar
with KTL) the remote Dashboard could be modified to give its user full
access to anything on the host running the remote Dashboard.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Security issues related to a Local interface of any kind
Ktcl/Ktk and the GNU kroot scheme in general

During 1997 the Keck code has been reworked by both Lick and CARA such
that it is now trivial to build the core control system on almost any
platform, including PCs.  Further, the rapid evolution of Dashboard
has clearly demonstrated that the advent of the Ktcl interface makes
it easy to create new code that controls Keck systems.

This means that distribution of the Keck source code (as would be
required for local Dashboard usage) is a much more sensitive issue
than it has been before.  If Dashboard code is packaged for easy
use by other sites, we should expect to see attempts at control
of Keck (and Lick) systems from other sites.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

User-selectable Dither Patterns

This is really only relevant for post-deployment.
It was suggested that the Dither patterns for multiple exposures be
under direct control of the observer by editing of files.

This problem is broadly equivalent to the problems of transmitting
slitmask configurations.  We know we have to solve that.  Some of the
same technology should be applicable here.

	If Dashboard is local

This means that the Dashboard must either be able to {
	parse such files, translate them to DCS commands,
	and transmit them to DCS
	and
	transmit the same information suitable for FITS archiving
} or {
	transmit such files to CARA via some (secure) means
}

	If Dashboard is remote

Then the user is running nothing locally.

The files have to be edited via a telnet/rlogin/ssh session to
a machine at CARA.  Alternatively we need an entirely separate
mechanism for securely transmitting and identifying such files
from the user's machine to CARA.

--
Steve A.