RE: webmail vulnerabilities: a new pragma token?

In my opinion, the whole idea of using HTTP to alert the client of
"unsafe content" is wrong-headed.  ALL content is unsafe unless you
trust it.  Therefore, the client *must* provide facilities to let the
user identify trusted content and to protect him/her from untrusted
content.  The content could come equally well from FTP or some other

We have seen that bugs in design and/or implementation of scripting
languages have left users vulnerable.  These bugs would still exist
even if an HTTP header were added.  And an HTTP header would provide no
protection from scripts obtained via FTP.  The real solution is to fix
the implementations.

That may seem like a slow and painful solution, but it puts control in
the hands of the user, who has the most at stake.  And given that new
browsers would be required to detect a new HTTP header anyway, fixing
the problem (faulty browser security), and not the symptom (scripts
embedded in web-based email), is the right way to go.

Dave Kristol

Received on Thursday, 20 January 2000 11:45:58 UTC