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

[Ken Brown]

Ian BROWN wrote:
> 
> >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.
> 
> I just don't understand why Outlook and friends don't do this on WinNT/2000.
> My NT hacking friends say it is trivial to spawn a process with fewer rights
> than its parent. In Win2k you can even run programs and control panel-lets as
> a different user (hold down shift, right-click on the program and select "Run
> as...")
> 
> Similarly, they should use cut-down versions of programs like Word that DON'T
> have the ability to run macros to view attachments!

Maybe it's time to write our own mailer! Or try to modify Netscape to
behave correctly.

I haven't used W2000 much yet, but it seems to have finally became a
real multi-user system (NT was almost there but there were a few
irritating gaps that made things unneedfully hard). Maybe we will see an
improvement in the products available to end users. Though I doubt if MS
will be first to market with them - or 21st. They came out of the the
desktop standalone PC mindset so fast that they never really adjusted to
being able to handle large-scale system administration issues, and (at
least in the NT era) although they had lots of good people writing (or
more often porting) decent software, they never got over the DOS
legacy.  The tools available to me to handle large number of users on NT
and Exchange and so on are still less capable than those that were
available to me on VM/CMS over 10 years ago. Maybe W2000 will improve
things.

Back to the topic, what would a security-friendly mail client include?

The most obvious missing feature from my point of view is to run the
decoding of all attachments,  macros, html-formatted mail etc. in a
daughter process with severely limited rights - ideally in a tightly
controlled virtual machine in its own address space.  In fact fork
*everything* off. Every mail you open should be a new process (not
thread, process) and every MIME part, attachment, graphic whatever in
that mail should be opened by a new process. When in doubt, fork. 

With the machines we have these days surely performance isn't an issue?
Our current desktops our hundreds of times faster than ones that quite
happily ran Mosaic, Lotus Notes, & the last-but-one Microsoft Word in
the early 1990s. If anything perceived performance should improve with
this sort of method, because there will be fewer unexplained waits,
short-term hangs, failed timeouts. Anything that takes longer to
complete will just hang around int he background.  (I get really fed up
with the way that a timeout or other delay in one Netscape window hangs
all the others including my mail - one of the reasons I don't like MSIE
& Outlook is that the same wait will hang my  whole desktop & therefore
everything on NT)

Also security should improve as reliability improves because this is an
easier model to program to.

When this is set up then we won't need to tell people to leave scripting
turned off, to refrain from sending HTML formatted mail, to turn off
cookies. After all there is nothing *immoral* about wanting to have
pretty pictures in your email - it's just dangerous in a MicroSplodge
world.

Next obvious thing (though we've been here before) is a seamless
integration of whatever encryption package the user wants to use. It
should be able to pick up plain text & drop it into outgoing mail
without ever permanently writing on disk. 
(Of course in a virtual memory environment there is no such thing as
without *ever* writing to disk at all)

Ken Brown (Birkbeck College CCS Systems Team)