CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jo Meder <[log in to unmask]>
Reply To:
Date:
Wed, 26 Aug 1998 22:13:06 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (95 lines)
derek bambach <[log in to unmask]> writes:
> At 04:57 PM 8/26/98 +0200, Jo Meder wrote:
> >derek bambach <[log in to unmask]> writes:


(I think this gets more heated than it deserves. Blame it on my poor
comand of English, which I apologize for now and should perhaps have
done earlier, if I sounded to harsh.  No pun intended, really.)

> the MIDDLE button? what kind of machine are you using?

Why, unix of course. ;-)

> what percentage of web users have a 3 button mouse? that's awfully
> sophisticated of you, but i would not attribute such savey to the
> majority of newer web users

The function of opening a new window on demand of the user is AFAIK
not limited to those using 3-button-mice.

> incidentally, we build web-based *software* - not pure
> content/information websites).


> if we write the code so that you loose your log-in session, we
> probably did for a reason (you certainly wouldn't want to walk away
> from your machine and have someone else come sit down and just
> "back" their way into your bank account, would you??).

Of course I wouldn't. But application-level-security is obviously not
possible if OS-level-security is missing to that extent. If you have an
inherently insecure OS (like one that would allow a different user to
back up into another's history) I wouldn't trust this machine anyway to
store or even receive any data that is dangerous wrt security such as
the example of online financial transactions you gave. More so if it
was in a public place where everbody and his brother can walk up to the
machine and start tampering with it.


> there are very clear reasons why improperly traversing a secure
> process *should* force you to log-in again. it's a security measure. we
> re-set the cookie, too.

But you can not clear the local page-cache of the machine or ensure
that memory used to store the pages is zeroed out.


> SO... are you telling me that
[I'd like to repeat a whole complicated process all over just because
 I opened a link in the same window which deviated from the standard
 path]

No, of course I'm not. But I think that there is something more
fundamentally wrong than an opened window more or a followed link if
you have to try to force people to go through a process along a
predefined line in one large sweep. Perhaps http and its decendants
are just not very well suited for this kind of application.

HTTP is a stateless protocol and what I'm trying to say is that IMHO
any application trying to work against that to the extent you describe
is bound to fail.

And neither HTTP nor HTML offer anything wrt security but I suppose
you're using HTTPS or something similar anyway. But if you have a
complex procedure like the one you describe that has to be followed
step by step to be successfull, why not use a Java-client? But then,
who am I to tell you what to do.


Take all coments below with a laaarge IMHO:

> contrary to what is obviously a very strongly held attitude about this, the
> end-user does NOT always know what the best way to accomplish something is
> because often times they are
> (A) unaware what is actually going on behind the scenes,

Tell them.

> (B) unaware of basic technological limitations to web-based
>     applications, and

Use something else.

> (C) unaware of the consequences of doing something incorrectly or
>     incompletely.

Warn them.


> and then you are, as they say, "S-O-L".
(sorry, I don't know the term "S-O-L")


        Jo

ATOM RSS1 RSS2