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.
