Re: audio, checksums, and trojan horses

Bill Janssen writes:

> > AUTHORS' POSTION:  We should not define/endorse any content-types that
> > are known to have Trojan horses.  (This is one reason why we removed
> > troff & tex.)  We should add a Security Appendix explaining the dangers
> > of certain conceivable content-types, but we should ban nothing.
> I think this ignores the real world.  In particular, there is a real and
> heavy demand for sending "shar" files, troff, TeX, and PostScript
> documents, all of which present nasty Trojan horse problems.  All will
> still be used, and the fact that they are dangerous should not excuse us
> from defining that use (while at the same time explaining the dangers,
> and perhaps deprecating their use).
> For that matter, taking your attitude to a meta-level, the "application"
> type shouldn't even exist, since many applications will present us with
> Trojan horse problems :-)
> So:  Add/keep definitions for troff, TeX and PostScript.
I think I need to clarify my position on this. I had no strong objections to
the removal of troff and TeX types because I don't see these types of
information being something that a UA will use directly. Sure, these types are
useful for general identification purposes of the material people mail around
all the time, but I for one don't propose to use them directly in a UA, and as
such I felt they could wait for definitive documents of their own.

I happen to think that this Trojan horse stuff is a little silly. However, even
if you ignore the Trojan horse problems, the difficulty of displaying TeX (I
have almost no familiarity with troff) within a standalone interactive UA
application is enormous. I can get into all the details if anyone really cares,
but take it from someone who uses TeX all the time -- TeX documents have too
many external references to make it possible to blithly process them in a
mailer.

This in no way reduces the need to label TeX input as TeX when it appears in
mail, but it does reduce the necessity of having this subtype available right
away for all those multimedia mail applications we're all going to write ;-)

PostScript, on the other hand, is a different kettle of fish. Looking at TeX
and PostScript side by side is a very interesting exercise. Both languages have
the potential to make external references to all sorts of things. However,
PostScript documents have resisted the temptation to make use of such
references, whereas TeX documents seem to delight in them (no book done in TeX
is complete without its own macro package). The reasons for this are pretty
obvious -- PostScript has by and large been a language to implement on
printers, and printers tend not to have the ability to resolve external
references. People have come to accept the availability of a limited number of
standard fonts in the base set; other fonts have to be included in the document
itself.

When PostScript moved into the realm of being a language for controlling
displays, the Trojan horse problem presented itself, and that led to many
features of the language being disabled in display applications. Thus,
PostScript documents do tend to be standalone (or can be made standalone with
the addition of a simple header).

PostScript documents almost never attempt to do any sort of output (excluding
marking the output page, of course) since very few PostScript interpreters even
allow the creation of output files. (TeX, on the other hand, loves to produce
auxiliary files and the inability to produce them and reprocess them would be a
major hardship).

But the bottom line is simply that people send PostScript documents around and
expect to be able to view them interactively. People do NOT send TeX documents
around on the same basis. Others can yowl and scream about the security
implications of this, but the fact remains that people can do it, people
will do it, and people will not stop doing it because we don't provide a
subtype for PostScript.

The UA I'm using right now has a PostScript viewer in it. It is of course safe
-- all of the PostScript file operators are disabled.

If it comes down to it I'll write the necessary "security implications" text
for PostScript myself. I'd prefer to have someone more expert than I do it, but
if I have to do it in order to keep PostScript in the document I will.

In case anyone hasn't guessed, not having PostScript in some form is a
SHOW-STOPPER for me.

                                        Ned