Re: PFWG comments on User Interface Security Directives for Content Security Policy

Thank you for your acknowledgement of the PF comments on WebAppSec. The 
PFWG formally accepts your disposition of these comments.

With regards to the unclosed loop on resolving the questions about how 
the source of events affect assistive technologies, we apologize for any 
communication breakdown on our part. We have attempted to figure out 
what threads were unclosed but are not quite sure what happened. We are 
working to improve our process to reduce unclosed loops in the future. 
At the moment, we are unable to offer further substantive insight on the 
question at hand so will look to see how things play out in deployment.

Michael Cooper
PFWG staff contact

On 30/06/2014 5:33 PM, Brad Hill wrote:
> Thank you for the feedback, Michael and WAI.
>
> Regarding 1, use of RFC2119 in informative sections, I've fixed this.
>
> Regarding 2:
>
>    WebAnywhere proxies content, it doesn't frame it.  As such, CSP 
> headers are never delivered to the end user.  I believe that is the 
> only plausible way for such a system to work without requiring browser 
> modifications because otherwise the Same Origin Policy would prevent 
> the wrapping frame from gaining access to the content.  I've added the 
> following text to make this clear:
>
> "Accessibility technologies that act as a proxy MAY filter
> any UISecurity policies if they cause interference with the user's
> chosen methods of accessing the content."
>
>   I mention screen magnifiers in the text already - I can't say 
> normatively how any given one would work because each might be 
> implemented at a different layer (in the user agent vs. in the 
> operating system), and each browser implementation might obtain its 
> "control image" from a different layer: some might use getUserMedia() 
> of an off-screen canvas unaffected by an operating-system magnifier, 
> others might use an OS facility that does.
>
>   I don't have any reason to think, and the specification doesn't say 
> anything about, the source of events, be they from mouse actions, 
> simulated or not, platform accessibility APIs or the DOM, so I don't 
> believe this should impact how it is enforced in UI Event Handling. 
>  These kinds of questions were ones WebAppSec originally brought to 
> the WAI as subject matter experts, but we haven't been able to obtain 
> any clarification as to how specifically they change the DOM event model.
>
>  I've changed the relevant paragraph to read more strongly:
>
> "Use of accessibility technologies MUST NOT by itself cause
> the input-protection heuristic to be triggered.
> Accessibility technologies that modify the appearance of a resource,
> such as screen magnifiers, contrast enhancers, or screen readers
> that highlight the element currently being read, have the potential to
> interfere with the obstruction check.
> If a user agent is able to detect that accessibility technologies are 
> in use
> that could cause interference, the check MUST be disabled.  In some cases,
> interference from accessiblity tools may be avoided by acquiring
> the user image in terms of the user agent's local
> rendering surface, rather than using an operating-system level
> screenshot."
>
>
> Regarding 3 and 4, I have added the requested text.
>
> Updates can be verified at:
>
> https://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html
>
>
> thank you,
>
> Brad Hill
>
>
> On Thu, Jun 19, 2014 at 6:19 AM, Michael Cooper <cooper@w3.org 
> <mailto:cooper@w3.org>> wrote:
>
>     Below are comments from the WAI Protocols and Formats Working
>     Group on User Interface Security Directives for Content Security
>     Policy http://www.w3.org/TR/2014/WD-UISecurity-20140318/.
>
>      1. We note that there are RFC2119 MUST statements in sections
>         marked as informative. This is confusing for implementation
>         requirements and review. Please ensure that all sections that
>         have RFC2119 MUST statements are in normative sections.
>      2. We welcome the section 14.1 on assistive technologies.
>         However, we do think the section is clear enough as written.
>         More detail, and perhaps some examples, would be welcome. Some
>         specific questions we had, that we didn't now how to answer
>         based on what was present in the section, include:
>           * Would an app using UI Security Directives be able to be
>             operated by a cloud-based screen reader, such as Web
>             Anywhere, which wraps a frame around all content it reads?
>             http://webanywhere.cs.washington.edu/
>           * Will the input protection heuristic work when a screen
>             magnifier, such as Windows Magnifier or ZoomText is
>             running on the machine?
>           * How will browser zooming impact the input protection
>             heuristic?  What if the zoom occurs during the user
>             interaction?
>           * Some assistive technology simulates mouse actions.  How
>             will this impact UI Event Handling?
>           * Some assistive technology simulates user actions via
>             platform accessibility APIs.  How will this impact UI
>             Event Handling?
>           * Some assistive technology simulates user actions via the
>             DOM.  How will this impact UI Event Handling?
>      3. In the same section 14.1, we request that the statement "User
>         agents SHOULD provide a means ..." be changed to MUST and add
>         a sentence at the end "The mechanism for manually disable
>         enforcement of the Input Protection Heuristic MUST be operable
>         by assistive technolgies and by people with cognitive
>         disabilities who are able to understand the security risk."
>      4. In Section 15 we request addition of the paragraph "Mechanisms
>         for CAPTCHA and user verification should include options for
>         people with different disabilities, including cognitive
>         disabilities, people with impaired visual and auditory
>         discrimination skills, and for different modalities. For
>         example, if CAPTCHA or user verification  require biometrics,
>         a choice should be offered of what biometrics to use, as
>         people with different disabilities may be unable to use one or
>         more specific  biometric mechanisms. Further, when two step
>         verification procedures are used, any time limit is problem
>         and it should not be dependent on the user's short term memory
>         or on the user's ability to copy accurately. See <a
>         href="http://www.w3.org/TR/turingtest/"
>         <http://www.w3.org/TR/turingtest/>>Inaccessibility of
>         CAPTCHA</a> for more information about accessible CAPTCHA."
>
>