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

[Joshua D Boyd]

On Fri, Mar 08, 2002 at 04:27:45PM -0500, Greg A. Woods wrote:

> J$ is evil -- never "handy" -- it's the hand of some real devil (not
> that poofy incarnation in Redmond :-)
> 
> HTML is never supposed to be executed!  The person who thought of
> including code embedded in HTML should be shot.  Even delivering applets
> with HTTP is a questionable idea.  Any kind of code migration outside of
> a security domain is a very bad idea, even if it's written in a
> so-called "safe" language (which java really isn't).

This view depends on whether we want the web to be strictly documentation, or
also networked applications.  I believe it is important for a site to pick
one or the other, and follow it's choice exactly.  

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.  It
could even be implemented in pure HTML, but that would require at least a 
frame load for tree action.  Now, I suppose you could argue that a tree tag
should have been included in HTML.

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.  Online applications on the
greater internet generally suck, but on intranets, they can be quite handy.
 
>>  For ASP style sites
>> (ASP == Application Service Provider, ASP != MS Crap), cookies seem like
>> a good idea.
> 
> HTTP Cookies are "necessary" in so few situations that they really
> should be re-designed properly.  They MUST NOT EVER be stored on disk,
> for one.  That's where the evil of J$ and cookies gets right out of hand
> (because one good use for temporary cookies is to hold authentication
> tickets).

Why shouldn't they be stored on disk?
 
>>  Personally, for
>> application style sites, a session cookie is just a plain sensible way to do
>> things.
> 
> Nope.  Session cookies are evil incarnate too.  That's what URL
> parameters are for!

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.  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,
but most people (myself included) usually don't remeber to click the close
session button, and leaving the session active for even 2 minutes after the
person walked away from the computer (which is awefully short time because a 
single page might take more than 5 minutes for the user to contemplate, and 
you have no way of knowing if they left, or are just thinking) because it
allows someone else to scoot in and pick up the session (yes, I'm thinking 
from the point of view of what people do in computer labs on campus, the 
biggest web page session mangement nightmare that I've yet to come across).

Session cookies on the other hand get dumped when the web browser is closed,
a reasonably nice solution to the problem since most people do close their web
browsers before leaving the lab.
 
> However the mere concept of introducing "sessions" to HTTP accesses is
> totally brain dead.  Applications can be easily designed not to require
> "sessions" per se, usually just by following proper client/server
> protocol design guidelines.  Only problem is we need to resurrect a
> whole bunch of mainframe programmers to teach all the web weanies how to
> do it right (and even then we'd need to teach the mainframers how the
> web works first -- I've seen some attrocious implementations of web
> front-ends to mainframe applications too).
> 
>>  In general, I'm happy to allow session cookies for most sites.  I
>> dislike permenant cookies for the most part, except the NY Times site (that 
>> they require a login is a pain, but I'm willing to make the trade) and other
>> semi-"subscription" news and trade sites.  The three that I allow permenant
>> cookies for are the NY Times and Gamasutra sites.  Well, I don't go to far
>> out of my way to prevent other sites from setting cookies that I don't want
>> them to.  I should just get a proxy setup that does this for me.
> 
> Mozilla is beginning to get logins right -- it automatically logs you
> in, and you can set it up so it won't start without a password.  Just
> set up a profile with your private web passwords and away you go.

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).
 
>> There is one java applet that I want to run (but the sysadmin refuses to
>> install it on the web server).  That is the java ssh client applet. But, the
>> CS sysadmin won't install it.  That is something I intend to install on the
>> machine I configuring to colo.
> 
> Oh, yeah, I've used that one too -- and have it installed, but only with
> other people's browsers!  ;-)
> 
> You can put it on your personal web page -- it doesn't have to be
> installed by a sysadmin.

It does if you are given a total of 7 megs of disk space on the machine for
personal web pages, mail files, and homework projects.  300some CS students,
way over 30 gigs of disk space on the server (and lots of disks sitting around
from unused Sun machines), and they only allow students 7 megs.  For crying
out loud.

-- 
Joshua D. Boyd