RE: session timeouts - Re: Guideline 2.2 Issue Summary

Thanks David,

I don't see the need for the extra line -- and I see problems. 

Security is the primary reason that ATMs time out -- and those timeouts (if
no extension is allowed) prevents any use by some people.   Allowing
extension of time does not hurt security but does make it accessible.    

On the other hand - allowing a security exception would result in them not
providing the extension.

So the question is "How does the current set of choices not meet the needs?"
Only one I can see is if people asked for an indefinite number of
extensions.  So maybe we just change that one by adding "(for up to 5
extensions)" so that it reads  


-the user is warned before time expires, allowed to extend the time-out with
a simple action (for example, "hit any key") and given at least 20 seconds
to respond (for up to 5 extensions), or 


is there another problem we are trying to prevent? 
 
Gregg
 


 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 


-----Original Message-----
From: public-wcag-teama-request@w3.org
[mailto:public-wcag-teama-request@w3.org] On Behalf Of David MacDonald
Sent: Tuesday, October 11, 2005 11:50 AM
To: 'Gregg Vanderheiden'; 'Gez Lemon'; 'WCAG WG mailing list';
public-wcag-teama@w3.org
Subject: RE: session timeouts - Re: Guideline 2.2 Issue Summary


I had an action item to do complete the end to end for 2.2 L1 SC1

And that was also an issue that I wanted to bring to our TEAM A meeting. The
security issues in saying "no timed events."

In light of Gregg's suggestion below I would like to suggest the following
bullet to be added to 2.2 L1 SC1 where it says:

"Content is designed so that time-outs are not an essential part of
interaction, or at least one of the following is true for each time-out that
is a function of the content:

-the user is allowed to deactivate the time-out or; -the user is allowed to
adjust the time-out over a wide range which is at least ten times the length
of the default setting or; -the user is warned before time expires, allowed
to extend the time-out with a simple action (for example, "hit any key") and
given at least 20 seconds to respond or; -the time-out is an important part
of a real-time event (for example, an auction), and no alternative to the
time-out is possible or;
- the time-out is part of an activity where timing is essential (for
example, competitive gaming or time-based testing) and time limits can not
be extended further without invalidating the activity.

<proposed>
- the time-out is an essential security issue (for example, online banking)
</proposed>


And then in the guide doc I could add: 

<proposed> in situations where time-outs are an essential security issue, a
function allows the user to extent the time-out to at least 10 times the
timeout period. This would allow the site to drop people who left the
process but keep most people who are just slower.
</proposed>



.Access empowers people
            .barriers disable them.

 www.eramp.com


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Gregg Vanderheiden
Sent: Monday, October 10, 2005 2:59 PM
To: 'Gez Lemon'; w3c-wai-gl@w3.org
Subject: RE: session timeouts - Re: Guideline 2.2 Issue Summary


Yes

How about "at least 10 times the timeout period".  That would allow you to
drop people who left the process but keep most all people who are just
slower. 


 
Gregg

 -- ------------------------------
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison 


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Gez Lemon
Sent: Monday, October 10, 2005 1:47 PM
To: w3c-wai-gl@w3.org
Subject: Re: session timeouts - Re: Guideline 2.2 Issue Summary


On 10/10/05, Isofarro <lists@isofarro.uklinux.net> wrote:
> Be a little wary of the practical implications of these ideas (both 
> ideas). Server session timeouts are typically there as a means of a 
> server reclaiming unused memory. In the UK there's also the Data 
> Protection Act to consider, which, in terms of financial websites and 
> its related webapplications, its not advisable to keep a session open 
> indefinitely, nor is it advisable to store potentially private 
> information in a cookie.

Good points, Mike. The only other technique I can think of would be to offer
registration and keep the transaction in a database, which would allow them
a reasonable amount of time (however much the administrator could afford for
a transaction table) to complete the form.

Best regards,

Gez

--
_____________________________
Supplement your vitamins
http://juicystudio.com

Received on Tuesday, 11 October 2005 17:23:20 UTC