RE: webmail vulnerabilities: a new pragma token?

On Thursday, January 20, 2000 2:32 AM, Josh Cohen 
[SMTP:joshco@Exchange.Microsoft.com] wrote:
> > -----Original Message-----
> > From: Eric D. Williams [mailto:eric@infobro.com]
> > Sent: Wednesday, January 19, 2000 7:32 PM
> > To: 'Mark Nottingham'; Peter W
> > Cc: http-wg@cuckoo.hpl.hp.com
> > Subject: RE: webmail vulnerabilities: a new pragma token?
> >
> >
> > Mark,
> >
> > On Wednesday, January 19, 2000 7:46 PM, Mark Nottingham
> > [SMTP:mnot@pobox.com]
> > wrote:
> > >
> > > Just a reminder- Pragma: no-cache is a request header, not
> > a response header.
> >
> > This is as it should be.
> >
> But what your talking about means that the server would
> send the Pragma: disable-scripting to the client.
> That is a response header, not a request header as the
> spec defines it.
>
> > > Also, RFC2616 says that 'No new Pragma directives will be
> > defined in HTTP'.
> > > That seems to preclude this use of it.
> >
> > But what Peter suggests is an extension-pragma and not a new
> > Pragma directive
> > e.g.
> >
> > Pragma: no-cache, disable-scripting
> >
> No, thats a new directive.   You're just listing
> multiple directives in a single pragma statement.
>
> The point of that part of the spec is to declare
> pragma obsolete and not to be used in future work.
>

Got it.  That is a fine explanation of the intent as Pragma was included only 
for backward compatibility.

> >
> > The question that seems more apropos is what is the provider
> > expecting from the
> > client, not the converse.  Any implementor that decides to
> > modify her client to
> > extend Pragma: no-cache to Pragma: no-cache, disable-scripting should
> > reasonably expect the server to have implemented a Reply with
> > scripting
>
> I think the original poster meant that the CLIENT
> would disable scripting code that was sent by the server.

I disagree, I think the intent was to activate some 'procedure' in the response 
chain such that no scirpting elements would be returned in the content.  I 
certainly could have mis-interpreted this (and the Pragma directive is a 
request header) but it seems that is the intent.

> What you seem to be describing is that the client would
> send a request with "please don't send me any script"
> which defeats the purpose since you now have to trust
> the server....

That's the rub.

> I see your problem, but I dot think pragma is
> the right place for a solution.
> As a matter of fact, I dot think HTTP is the place
> for your solution.  Why not just stick a meta tag
> in the HTML itself ?

Therein lies the dilemma.  A question of whether the intended use of the 
browser as 'eMail UI' would be defeated in a substantial portion of WebMail 
based sites.  Also if the mere presence of a meta-tag could be used to disable 
(or enable) scripting in a browser (although, IMHO, disabling would be a good 
thing under some circumstances) it could lead to other issues concerning the 
'authenticity' or 'integrity' of page elements intended to be 'calculated' by 
the browser or passed to other modules for further processing.

Certainly we are not (yet) talking about SHTTP  like functionality for WebMail 
systems (maybe HTML or XML will?) but these issues of trusted and un-trusted 
scripting elements are currently being dealt with at the provider side through 
script filtering mechanisms, which seem to be inadequate at times.  This 
functionality may be best implemented as a Meta-Tag SUPPORTED in client 
implementations (who turns scripting back on?).  This would require a change in 
either usage expectations or browser HTML-parsing implementations ("I disable 
scripting every time I visit webmail.com?", "my browser ``remembers'' to 
disable scripting for this site element".) .  And still imposes a requirement 
on the provider concerning 'what to expect' the client will do as it relates to 
this meta-info certainly not a discussion for this WG, but IMHO may be best 
handled at the protocol level.

> Finally, as scott said, this problem can be solved
> by using existing browser functionality.  This
> is certainly easier than modifying the protocol and
> hoping that people will implement it.
> (I for one would recommend against implementing
>  your solution in our browser)

Just a note, this is not my solution.  Merely a seconding of a proposed measure 
to address some difficult areas concerning user expectations of behavior in 
these systems.  I would contend that the solution WILL require either:

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).


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      Pager: +1 301.303.8998
           For More Info: info@infobro.com

Received on Thursday, 20 January 2000 06:30:59 UTC