[rescue] Cookies, JS, and other "evils"

[Greg A. Woods]

[ On Friday, March 8, 2002 at 16:55:38 (-0500), Joshua D Boyd wrote: ]
> Subject: Re: [rescue] Cookies, JS, and other "evils"
>
> This view depends on whether we want the web to be strictly documentation, or
> also networked applications.

The "web" _IS_ just a document distribution system, with simple forms
for basic feedback and data collection.

The documents can be dynamic, and all is well (provided static elements
are still cachable of course), just so long as what the browser ends up
seeing is pure standard HTML.

>  I believe it is important for a site to pick
> one or the other, and follow it's choice exactly.  

Huh?  I think you're drawing conclusions right out of thin air.

> Except, that there is further blurring of which is appriate where.  For 
> instance, the MSDN Library site downlowds a custom control type thing for the
> TOC in the left hand frame.  This custom control is basically just a treeview
> control.  Now, this could in theory be implemented in pure JS and
> DHTML.

That's a really stupid and non-portable implementation of a very
commonly mis-used UI feature.  BAD BAD BAD.  DO NOT USE!

>  It
> could even be implemented in pure HTML, but that would require at least a 
> frame load for tree action.

A fetch for every new displayed document is just fine.  Caching is built
into the protocol (and most browser implementations).  "Just in time delivery"

>  Now, I suppose you could argue that a tree tag
> should have been included in HTML.

Why?  What a waste that would be!  Unnecessary complexity is the root of
all evil.

> For online applications, it really sucks to be limited to only what pure HTML
> can do, and I don't see any good way around it.

Bullshit.  What really sucks are so-called designers with zero
creativity and common sense.

If something cannot be implemented with simple forms and HTML output
then it's not worth implementing on the web.  Period.  Write a real
proper client-server application and distributed that over the web
(perhaps as Java, if you feel such a language is truly worth its costs).

No good will ever come from those who think the web is the hammer for
all the nails they perceive.

There is nothing worthwhile on the web that cannot be implemented with
standard HTTP (or HTTPS) and HTML, and many standard features could
easily be thrown away and forgotten with no real loss to anyone.

> Why shouldn't they be stored on disk?

Because storing temporary authentication tickets is a very bad practice,
since often they reveal secrets unintentionally and sometimes there are
bugs which make them not so temporary.  Browser implementers must come
to understand that persistent storage of such information can never come
to any good.

> I suppose.  But, then it takes great care to make sure that someone doesn't 
> write down a URL passed session key and use it to hijack someones else's 
> session.

Huh?  You're not looking at the whole picture.  If you need that much
security then you _NEED_ SSL and probably some kind of cryptographically
secure authentication ticket too.  If you've implemented anything that
can be "hijacked", even by accident via a bookmark, then you've
implemented it incorrectly.

>  I haven't seen any good way to deal with this.  The best is a 
> combination of timed session key expiration, and offer a close session button,

such "logout" buttons are nice features, but they really should be
implemented by the browser, not by some form submitted to the server.

> That is for windows users (needing a password to start it).  I don't trust
> Mozilla with storing passwords, logins, etc.  On important things, I generally
> don't allow Mozilla to save permenant cookies (like eBay's stay logged in
> feature, etc).

So you would trust some crappy J$ and then not trust the very software
you use to run it!?!?!?!?  You need to really think harder about what
trust really means and what you really are trusting and why.

Obviously if your home directory is on NFS and you share the network
with untrusted third parties then you shouldn't be using this kind of
feature, but the only alternative is to do things the hard way and type
your passwords as necessary.  I have colleague who once said that anyone
not willing to type a password for every window they open (he meant
xterm, but the same applies to web sites today) should not be allowed to
use a networked computer, and may not even deserve to use any computer.
Over time my agreement with him has only strengthened.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>