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

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> 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."
>
>