[Sigia-l] defining acct. profile

[Listera]

"Jody Hankinson" wrote:

> My concern is that novice users on shared machines will change each others
> settings causing maddness.

This is the part I wanted to be sure of. What's the set up here? Is this an
HTML/HTTP or a client/server app? Is the unique ID deposited as a cookie on
the client machine or embedded in the URLs or passed as a token by the
server? When a second user takes over, is there log in/out process wrt to
the app or wrt the OS? Is the unique ID machine specific or user specific?

I'll assume the worst case scenario: it's an HTTP app running in a web
browser, so anybody can walk up to the browser and start where the last user
left off.

This is the classic case of "If you are not UserX, click here" scenario that
you can see at Yahoo, etc. There's no solution, unless the previous user
logs out or somehow the new user logs in (I'm site-stepping authentication
here, which is a further complication.) Architecturally, you cannot rely on
the honesty/initiative of (new) users logging in/re-authenticating. So
whatever the previous user's ID was, it will continued to be used. Of
course, you could re-authenticate *every* time a message is send to a
thread, but that's way too annoying to be usable.

So until a cookie is rewritten or a server is (re)notified, switching from
one user to another remains a technical problem. Solutions lie in OS- or
app-level log in/out, re-launching the app, randomly sending an
authentication challenge to the user (at a statistically significant
interval), etc., which are all usability barriers.

*Before* you get to the account editing button, your fundamental problem
remains the user switching issue I outlined above. Otherwise, if you can be
sure that at *any* given time the person using the app is in fact the user
whose unique ID is the current authenticator, then there's no reason to
authenticate before the account/sub info can be edited.

> The technologist, who thinks of himself as an IA,
> thinks users will not make subscription changes if they have to validate.

That's entirely possible. If I had to authenticate myself every time I
checked my Yahoo page or switched among sections, I'd never use it. But I do
have to authenticate to view/edit my account. After having set it up many
moons ago once, I don't remember having to mess with it again. So it's
tolerable to me.
 
> My solution: be conservative, do it my way to start, test as soon as money
> and time are available.

How sensitive is the info in the account area? How damaging would it be if
it were compromised? How many cases do you anticipate where users would
share without having to log in/out?
 
> The tech solution: no user validation to make any account or subscription
> changes and if someone complains, change it later.

Sounds reasonable, unless it's OK for private info to be compromised or
someone to mess with another's sub settings. But if even a single case of
compromised account info is not tolerable, then you don't have to agonize
much: you need to authenticate *every* time "Edit Account" or
"Subscriptions" button is clicked.

Sorry, there's no easy answer to your dilemma: it is a balancing act between
info leakage and forcing your specific user base to authenticate, all mapped
against the value of the process to the user. In a banking app, there'd be
no question of the necessity to authenticate, in a list server full of
"acerbic and noisy" users like SIGIA, who knows :-)

Ziya
Nullius in Verba