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

Thanks again, Michael.  My apologies if I didn't close the loop - I
think some of my questions were just verbally asked at TPAC, etc.
I'll try to be better about making sure they are formally recorded,
but I don't think it materializes to a practical issue in this case,
as I said.

cheers,

Brad

On Wed, Jul 2, 2014 at 9:54 AM, Michael Cooper <cooper@w3.org> wrote:
> 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> 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/.
>>
>> 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.
>> 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?
>>
>> 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."
>> 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/">Inaccessibility of CAPTCHA</a> for
>> more information about accessible CAPTCHA."
>
>
>

Received on Wednesday, 2 July 2014 17:14:22 UTC