Re: Local program exection in WWW browsers
Stan Letovsky <letovsky-stan@CS.YALE.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 13 Apr 1994 15:48:05 --100
Message-id: <199404131344.AA18182@RA.DEPT.CS.YALE.EDU>
Errors-To: listmaster@www0.cern.ch
Reply-To: letovsky-stan@CS.YALE.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Stan Letovsky <letovsky-stan@CS.YALE.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Local program exection in WWW browsers
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2082
Subject: Local program exection in WWW browsers
From: David.J.Heiland@att.com
Date: Wed, 13 Apr 94 14:41:53
To: Multiple recipients of list <www-talk@www0.cern.ch>
---------
>
>In order to make full use of WWW browsers I'd like them to execute local
>programs, possibly using their output as HTML (ie a local CGI script).
Why not just have your local server execute it as a cgi-bin script?
>To do this generally is dangerous as has been mentioned elsewhere.
>However, it should be possible to have Mosaic only execute a program
>link (whether it is a form ACTION or an HREF) if:
>
>1. The page with the link is a local page (since remote pages shouldn't
>point to local executables)
>2. The program to be executed is local
>3. The program to be executed is in your PATH (since PATH contains programs
>you already trust).
These conditions strike me as both inadequate to ensure security
(especially 3 -- e.g. rm is a trusted program given the right
arguments, but it could still be misused.) and overly restrictive in
terms of the space of possible browser-programs one might want -- 1 &
2 seem contrary to the spirit of the Web. For database applications I
want browser scripts whose main function is to manipulate the internal
state of the browser, since servers do not maintain any kind of
transaction state. 1 & 2 would mean I could not offer up an
application to the Web generally -- each potential user would have to
explicitly download the scripts before they could run my application.
If this guaranteed security it might be worth it, but its hard to see
how it would.
I think what is needed is a scripting language extension to
HTML that allows programs to manipulate the browser state, including
possibly dynamic restructuring of the displayed documents. Dave Raggett
is including an API for such languages in the HTML+ spec. Security concerns
can be addressed by restricting the operations available in the language --
e.g. no file system manipulations, or only interactively confirmed ones.
Cheers. -Stan
http://cgsc.biology.yale.edu/stan.html