A reason not to use browsers for e-mail - e-mail wiretapping (fwd)

[Ken Brown]

Charles Lindsey wrote:

>         On Thu, 8 Feb 2001 11:26:22 +0000 (/etc/localtime)
>         Ben Clifford <benc@hawaga.org.uk> said...
> 
> > Javascript has a data tainting model (at least according to my O'reilly
> > "Javascript: the definitive guide" from a few years ago. Whether this is
> > implemented by IE or still implemented by Netscape, I don't know.
> 
> Sorry, what is "data tainting"?

The interpreter or compiler takes a view  on  the reliability of some
information that is passed to it, depending on the source of the
information. If some data is tainted then the program will refuse to do
certain things with it, or with other data that depends on it. So if Y
is tainted  but Z isn't then after X= Y+Z, X will be tainted as well.

Most often met with in Perl programs. For example, I wrote a  CGI
program the other day that calls a 2nd program to search for some data.
It calls the 2nd program by concatenating the name of the program (in a
variable) with a search string derived from user input. When run in its
most secure mode the Perl language refuses to do this. The string
entered by the user is considered "tainted" - for all we know the user
might have stuck some unexpected nasty things in it.

In Perl *any* data provided from outside the program is considered
"tainted". In Javascript 1.1, as far as I know (I'm not an expert) data
from a remote site was considered tainted by Javascript code run from
another site. So if you have web pages www.a.com up in one browser
window & www.b.com in another, a Javascript program running code from A
will consider data directly or indirectly derived from B to be tainted
by B (& vice versa)

Apparently Javascript 1.2 jacked all this in for a code-signing model
(which is, as we all know, the Microsoft solution & more or less useless
because it relies on the trustworthiness of the originators of the
code). Discussed at length at:
http://space.arch.ethz.ch/~mieusset/Doc/javascript/guide/sec.htm#1015075


> > How can you programmatically determine if a downloaded programs actions
> > are safe or not?
> >
> > An e-mail message that says "Welcome to Ben's mail service - click here to
> > upload your address book to your new central account" is not easily
> > machine-distinguishable from a message that says "Click here to claim your
> > free five pounds" [which then proceeds to upload your address book on
> > click].
> 
> I think it would be reasonable for a Javascript implementation, when
> obeying a command that caused data to be uploaded, or email sent, to
> put up a window saying "the script on the page <http:www.....> that you
> are currently viewing wishes to upload/send email/whatever; click here
> to proceed". If that comes up when you have just agreed to upload your
> address book, or even claim your five pounds, you will likely click
> automatically (it depends whether you are willing to trust the site
> concerned - with Ben's email probably yes, with free offers of five
> pounds maybe no).

Yes. It should prompt the user *every* *time* data is sent to a remote
computer. It also ought to be capable of prompting the user whenever
data is written to disk. 

The only long-term way to make things safe is to run browsers, email
readers & so on in their own virtual machine, under a userid that has no
access to damage any other virtual machine. The Java "sandbox" idea
approaches this but it needs to be properly supported  by the operating
system. This of course is the normal situation on multi-user Unix or
mainframe systems. Whatever I read in my mail can hurt my files but not
yours - and if I want to I can set ACLs for my files that prevent even
me from inadvertently destroying them.

In a secure system you can set up mail programs so they don't have the
authority to write to system areas and so cannot damage anything outside
of their own province, and you can deny them access to other programs
you don't want them to run. 
A truly cautious user would use different logonids to send & receive
mail, so that when they were reading their mail (or web-browsing) they
actually didn't have permission to send mail. I suspect no-one in the
whole world does this, though it would be pretty trivial to set up in
Unix with different ids logged on to different virtual terminals - it
might be harder in NT which isn't a true multiuser system & of course is
impossible in the legacy dossy-Windows or pre-X Macs.


Ken Brown