IP: re: today's nyt story, about safeweb.com - 'what's wrong withthis picture dept'

[David Farber <dave () farber net>]

> From: gep2 () terabites com
> Date: Fri, 31 Aug 2001 00:49:14 -0500
> Subject: IP: re: today's nyt story, about safeweb.com -  'what's wrong
>         withthis picture dept'
>
> To: dave () farber net
> X-Mailer: SPRY Mail Version: 04.00.06.17
>
> > SafeWeb is a proxy service.  When you use them, every single HTTP
> > request from your browser goes through their server. In other words, if
> > you don't trust them, then cookies are the least of your worries.
>
> > I understand the "credibility issue" point, but IMO SafeWeb should not
> > eschew the use of cookies just because people have an irrational fear
> > of them. Ad Bruce Schneier says, "Security is a process, not
> > a product"; part of that process is education.
>
> The fact is that cookies are a brain-dead, misguided "solution" to the 
> problem.
>  They operate based on the presumption (simply WRONG!) that a person's 
> session
> and access permissions are necessarily tied to a single (client) computer, 
> and
> likewise that nobody else uses that computer.
>
> Public access machines (in Internet cafes, public libraries, airport waiting
> lounges, and even in homes and businesses) demonstrate how clearly 
> bankrupt that
> design premise is.
>
> For example, just because Mom and Dad have the "authorization cookie" to 
> access
> an adult site, DOES NOT MEAN that the kids should have access later just 
> because
> they use the same family machine.
>
> If I get onto a Web site and my client machine dies in the middle of an 
> extended
> interaction of some kind, I'd like to be able to walk over to another 
> machine at
> my office (or here at my home!) and continue the session.
>
> It's really a trivial matter to store the "cookie" on a database/cookie 
> server
> AT THE HOST WEB SITE, specified by a simple unique user ID of some kind (the
> user could maybe even specify something that makes sense to them... an E-mail
> address would probably be relatively unique, or failing that could be 
> modified
> slightly to make it so...).  This would eliminate the need to ship the cookie
> down the (slow) client line, and also would eliminate most
> privacy/misappropriation concerns.  Once the unique ID is established, it can
> easily be passed as a URL suffix to permit the "host-side cookie" to be
> retrieved for subsequent processing, if any.
>
> A user can later continue the session from ANY computer ANYWHERE, and 
> likewise
> doesn't have to worry about some other user assuming their identity (just
> because they're using the same machine!) and having access to stuff they
> shouldn't have.
>
> Thoughtless and uncreative webmasters tend to use cookies and Java more 
> because
> they're familiar with those approaches (and enjoy 'showing off') than because
> those approaches really are GOOD solutions to the problems of functionality,
> persistency and session state.
>
> Gordon Peterson                  http://personal.terabites.com/
> Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
> 12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
> 12/09/00: the date the Republican Party took down democracy in America.



For archives see: http://www.interesting-people.org/