Edit comment LC-2057 for Web Security Context Working Group

Quick access to LC-2056 LC-2057 LC-2058 LC-2059 LC-2087 LC-2088 LC-2092 LC-2093 LC-2094 LC-2095 LC-2129

Comment LC-2057

Comment Shortname:

Commenter: Sam Hartman <hartmans-ietf@mit.edu>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeWeb Security Context: User Interface Guidelines... Web Security Context: User Interface Guidelines W3C Working Draft 24 July 2008 Abstract Status of this Document Table of Contents 1 Overview 2 Acknowledgments 3 Conformance 3.1 Product classes 3.2 Language conventions 3.3 Conformance levels 3.4 Conformance claims 4 Interaction and content model 4.1 Overview 4.2 Terms and definitions 4.2.1 Common User Interface elements 5 Applying TLS to the Web 5.1 Certificate Handling and Information 5.1.1 Interactively accepting trust anchors or certificates 5.1.2 Augmented Assurance Certificates 5.1.3 Validated Certificates 5.1.4 Logotype Certificates 5.1.5 Self-signed Certificates and Untrusted Root Certificates 5.1.6 Petnames 5.2 Types of TLS 5.3 Mixed Content 5.4 Error conditions 5.4.1 TLS errors 5.4.2 Error Conditions based on Third Party or Heuristic Information 5.4.3 Redirection chains 5.4.4 Insecure form submission 6 Indicators and Interactions 6.1 Identity and Trust Anchor Signalling 6.1.1 Identity Signal 6.1.2 Identity Signal Content 6.2 Additional Security Context Information 6.3 TLS indicator 6.4 Error handling and signalling 6.4.1 Common Error Interaction Requirements 6.4.2 Notifications and Status Indicators 6.4.3 Warning/Caution Messages 6.4.4 Danger Messages 6.5 Chrome Reconfiguration 7 Robustness 7.1 Chrome and User Interface Practices 7.1.1 Use Shared Secrets to Establish a Trusted Path 7.1.2 Keep Security Chrome Visible 7.2 Do not mix content and security indicators 7.3 Managing User Attention 7.4 APIs Exposed To Web Content 7.4.1 Obscuring or disabling Security User Interfaces 7.4.2 Software Installation 7.4.3 Bookmarking APIs 7.4.4 Pop-up Window APIs 8 Security Considerations 8.1 Active attacks during initial TLS interactions 8.2 Certificate Status Checking Failures 8.3 Certificates assure identity, not security 8.4 Binding "human readable" names to domain names 8.5 Warning Fatigue 8.6 Mixing Augmented Assurance and Validated Certificates 9 References
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

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

Related issues: (space separated ids)

WG Notes: 2008-08-22, asked Al Gilman for review: http://lists.w3.org/Archives/Public/public-wsc-wg/2008Aug/0022.html 2008-09-03, pinged again; Al ponged, but didn't give material response quite yet It's been removed from wsc-ui.

Resolution: 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.

(Please make sure the resolution is adapted for public consumption)