W3C home > Mailing lists > Public > public-usable-authentication@w3.org > January 2009

Re: Last Call Comment: Implications of Audio and Visual Logotypes at the same Time ( LC-2057)

From: <mzurko@us.ibm.com>
Date: Fri, 09 Jan 2009 20:03:03 +0000
To: Sam Hartman <hartmans-ietf@mit.edu>
Cc: public-usable-authentication@w3.org
Message-Id: <E1LLNZP-0000Fm-LB@farnsworth.w3.org>


 Dear Sam Hartman ,

The Web Security Context Working Group has reviewed the comments you sent
[1] on the Last Call Working Draft [2] of the Web Security Context: User
Interface Guidelines published on 24 Jul 2008. Thank you for having taken
the time to review the document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-usable-authentication@w3.org if you agree with it or not before 26
January 2009. In case of disagreement, you are requested to provide a
specific solution for or a path to a consensus with the Working Group. If
such a consensus cannot be achieved, you will be given the opportunity to
raise a formal objection which will then be reviewed by the Director
during the transition of this document to the next stage in the W3C
Recommendation Track.

Thanks,

For the Web Security Context Working Group,
Thomas Roessler
W3C Staff Contact

 1.
http://www.w3.org/mid/20080813135303.CF9DE41EF@carter-zimmerman.suchdamage.org
 2. http://www.w3.org/TR/2008/WD-wsc-ui-20080724/


=====

Your comment on 5.1.4 Logotype Certificates:
> I have finished reviewing the July 24 draft of the user interface
> guidelines.  This is excellent work.  However I do have a couple of
> comments, the first of which I'll raise in this message.
> 
> Section 5.1.4 requires that if a user agent is going to render both an
> audio and visual logotype, that the rendering by time synchronized so
> they both start at the same time.
> 
> Outside of accessibility contexts, this is a fine requirement.
> However, I'm familiar with a number of Screen Readers (software
> designed to make resources accessible to blind users) where this
> requirement would be problematic.  In particular, on Windows (for
> products such as Window Eyes, JAWS and Microsoft's Narrator), for Unix
> (products such as Orca) and Mac (products such as Voice Over),
> rendering of the audio interface is handled by a separate software
> component than the visual interface.  The audio interface has access
> to special accessibility APIs to get access to the DOM, security
> context and other information.
> 
> So, it would be very difficult in accessibility contexts to
> synchronize the rendering of these two components.  I suspect that if
> people implement this requirement they will do so by moving the audio
> rendering into the main browser rather than the accessibility
> component.  That seems highly problematic, because it separates
> rendering of the logotype from rendering of other security context
> information.  The information is synchronized visually, but for those
> who use the audio user interface, this will mean that logotypes will
> be rendered at some random time while the page loads, out of
> synchronization with any rendering of signals in section 6.  As a
> result, it seems like techniques such as using a different voice for
> security context information would be ineffective at preventing
> spoofing of the logotype.  An attacker could simply play the logotype
> sound at any point in order to spoof an audio user.
> 
> To provide a good security experience for audio users, I think it is
> important that the logotype be rendered along with other audio
> security context information, regardless of when that happens or
> whether it is synchronized with visual indicators.
> 
> I think the easiest fix is to remove the requirement for
> synchronization.  If that is problematic, then scope the requirement
> to cases where both logotypes are rendered outside of accessibility
> contexts and suggest that accessibility API for browsers provide a
> mechanism for screen readers to suppress the browser's own rendering
> of the audio logotype.  Screen readers are already security sensitive;
> allowing them to configure chrome is no worse than any other trusted
> component.
> 
> 
> Thanks for your Consideration,
> 
> Sam Hartman
> Principal, Painless Security LLC


Working Group Resolution (LC-2057):
Thank you. We have removed a number of items in wsc-ui due to lack of
implementation and testing, and audio logotypes are among the items that
have been removed. 

----
Received on Friday, 9 January 2009 20:03:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:15 GMT