RE: webmail vulnerabilities: a new pragma token?

Larry,

I think you are coming real close here.  We are definitely looking at an issue 
of 'levels of trust' that must be understood by client implementations and 
end-users.  I suppose another MIME type would address the issue and allow some 
freeform for a time as to how to handle unsafe content.  For me you have made 
it no longer as perplexing a conundrum as before:

1.  A change in the way WebMail systems are implemented (which could include 
protocol changes) or;
2.  A change in the functionality of browsers at some level (read HTML 
parsing).

and,

On Thursday, January 20, 2000 2:16 PM, Larry Masinter 
[SMTP:masinter@attlabs.att.com] wrote:
--8<--snip-->8--
>
> Even if sticking this kind of information in HTTP were appropriate
> (which I don't think it is), using "pragma" would be the wrong
> way to go about it. The whole notion of "Pragma" as a HTTP header
> came from programming languages which used "Pragma" as a way of
> sticking in random additional compiler directives because there were
> a fixed number of "reserved words" in the language. There's was no
> reason to use "Pragma" as an extension mechanism in the first place,
> and certainly it shouldn't be continued.
>

I think the intent of the HTTP/1.1 support was for backward compatibility, only 
yes?  The 1.0 header request Pragma was a way of addressing "no-cache".

> > It would be nice if there were on an HTTP header that, if sent
> > to the client, would cause the client to disable javascript,
> > vbscript, etc. for that document only.
>
> If you really wanted to go this way, how about a new MIME type, e.g.,
> "message/unsafe;type=http" which would have the semantics of
> message/type (message/rfc822 or message/http) with the proviso that
> the body is likely to be unsafe content.

Here is where the 'levels of trust' (that's the bug-a-boo) would be important 
(to me).  It would be good not to limit the description here to merely 
"unsafe", per se I think I see your point clearly.

> At least it would have the right extension behavior, namely
> that unaware recipients might save the content to disk but would
> be less likely to open it.

I don't know about that; if its not safe to a later 'aware' recipient is 
probable and good, but older clients would not be able to discriminate.  That 
could set up an interesting situation where browsers are updated or 
trust-levels are upgraded; Excellent though.

Eric

Eric Williams, Pres.
Information Brokers, Inc.    Phone: +1 202.889.4395
http://www.infobro.com/        Fax: +1 202.889.4396
mailto:eric@infobro.com
           For More Info: info@infobro.com

Received on Thursday, 20 January 2000 12:27:10 UTC