Richard M. Smith writes:
[ mail readers disabling inline images ]
> It will be interesting to see how email marketing companies and
> spammers adapt to these technical changes in HTML email.

ASCII porn, perhaps? Especially if the sender can control the color, and
size, of text. I suppose those will be the next casualties in the war on
spam.

It's quite depressing that this is what people think of as ``security'':
patch maniacally; install a scanner that checks for yesterday's attacks;
don't view the pictures, don't drink the water, don't breathe the air.

I've been playing with a radically different system design (I'm thinking
of calling it ``UNIX'') where conceptually separate tasks are split into
separate processes. If you want to gunzip a stream of data, for example,
you run a gunzip program in its own chroot jail, under its own uid, with
no way to read any interesting data except through a predefined IPC hook
(I'm thinking of calling that a ``pipe'' on ``standard input'') and with
no way to touch anything except through another predefined IPC hook. The
only thing that an attacker can do by taking over this gunzip program is
generate arbitrary output data, which he could have done anyway. Typical
picture-generating programs can be isolated in the same way.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

P.S. It's hard for a portable chroot tool to cut off a program's network
access. Kernel designers should provide a disablenetwork() syscall, with
the disabling inherited by children. Other kernel changes would be nice,
but disablenetwork() is the only critical change.

[ reply ]