- From: Léonie Watson <tink@tink.co.uk>
- Date: Wed, 5 Dec 2012 17:54:46 -0000
- To: "'Hill, Brad'" <bhill@paypal-inc.com>
- Cc: <public-webappsec@w3.org>, <w3c-wai-pf@w3.org>
- Message-ID: <23f301cdd311$9cfcf260$d6f6d720$@tink.co.uk>
Thanks Brad. PF discussed the proposed text today. It captures the situation well, but we had a couple of questions and suggested amendments. “Certain classes of accessibility technologies such as screen readers will provide strong defenses against many classes of UI Redressing attacks by presenting the content to the user in a manner not subject to interference.” Until we can be sure this is the case, it should be a “may provide strong defenses”, instead of “will provide strong defenses”. When there are test cases available, we can take a more detailed look at AT behaviour and that sould put us in a better position to be more certain. The detection of transformative settings and/or ATs is still the biggest challenge. As previously mentioned, techniques for doing this are limited, so we’re still left with a potential vulnerability in people who need to turn off the security measures in order to prevent false positives. One question was raised on the PF call. What happens when someone has chosen a personalised colour scheme within their browser (or no other reason than asthetic choice)? Would this have the potential to trigger a false positive too? Léonie. From: Hill, Brad [mailto:bhill@paypal-inc.com] Sent: 21 November 2012 18:58 To: tink@tink.co.uk Cc: public-webappsec@w3.org; w3c-wai-pf@w3.org Subject: RE: A11y for Web App Sec Anti clickjacking spec Thanks for this, Léonie. It was nice to meet you as well, and we really appreciate your and the WAI’s taking the time to review our spec. The canvas used to render the “control image” for obstruction testing will never be accessible to the user, so those concerns are moot. Below is the text I’ve added based on this feedback. I think the UA implementers should have an easier time telling if A11Y technologies are enabled in the browser, because they are coding “from the inside”, even if no external APIs are exposed. As a final fallback, we suggest that UAs should provide a way to disable the obstruction check manually if it interferes with users’ chosen A11Y technology. -Brad 9.1 Accessibility Technologies Certain classes of accessibility technologies such as screen readers will provide strong defenses against many classes of UI Redressing attacks by presenting the content to the user in a manner not subject to interference. Such user agents should set the unsafe attribute of the UIEvent interface as this may be interrogated by client applications doing feature detection, and should ignore X-Frame-Options headers when presented in combination with UI Safety directives in a Content Security Policy. Use of accessibility technologies must not cause the input-protection heuristic to be triggered. Accessibility technologies that modify the appearance of a resource, such as screen magnifiers or color and contrast modifications to the display have the potential to interfere with the obstruction checkif not applied in a consistent manner to both the user image and control image. To prevent this inteference, user agents should apply accessibility transformations to the control image. If a user agent is able to detect that accessibility technologies are in use that cannot be applied uniformly as part of the obstruction check, the check must be disabled. User agents should provide a means for the user to manually disable enforcement of the Input Protection Heuristic if it interferes with their chosen accessibility technologies. From: Léonie Watson [mailto:tink@tink.co.uk] Sent: Sunday, November 18, 2012 7:01 AM To: Hill, Brad Cc: public-webappsec@w3.org; w3c-wai-pf@w3.org Subject: A11y for Web App Sec Anti clickjacking spec Brad, It was good to meet you and the Web App Sec WG at TPAC. Thanks for inviting PF to work with you on the accessibility of this specification: http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safe ty.html Our assumption is that screen readers afford a measure of protection against some clickjacking techniques, because of their reliance on HTML (rather than what’s visible on screen). This should be tested when any example use cases become available though. One instance when this behaviour is likely to influence the spec is when HTML5 canvas is used as part of an obstruction check. The method used to hide the canvas content off screen should render it invisible to screen readers as well. Either visibility:hidden; or display:none; should do the trick. Assuming there is no intention for the canvas to be available to the user, its accessibility is a moot point. If that’s not the case though, the following notes might prove helpful. You can include HTML elements inside the canvas element. This fall back content is keyboard navigable, and you can create relationships between the rendered canvas and elements within the HTML. You can define a path around an object in the canvas and bind it to an element in the fall back content. This creates a location that can be used to pass mouse events through to the fall back content (hit testing). If you don’t define paths, the hit testing is handled by the canvas. Anything without a path is routed to the canvas element, and the mouse event is routed to the handlers associated with it. When you associate a path with a fall back element, it can be used to form a rectangle that can be exposed to the browser’s accessibility API. For example, a screen magnifier would be able to zoom in on a targeted area of the canvas. In terms of the visual appearance of content to be compared in an obstruction check, canvas isn’t subject to CSS styling or adaptations such as high contrast mode. The challenge will be preventing a false positive from being triggered when legitimate accessibility adaptations have been made to the on screen content. Microsoft has introduced a proprietary CSS3 media query for detecting high contrast mode in Windows8/IE10: http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx Otherwise, I haven’t been able to find other methods for detecting high contrast or increased text size adaptations at the UA or OS level. It may be that the browser vendors can offer some suggestions for detecting adaptations made within the browser, but detecting the presence of assistive technologies like screen magnifiers isn’t viable. This may mean catch 22. If it isn’t possible to detect accessibility adaptations there is no way to disable the policy (and that has security implications as an action anyway of course), but if the policy isn’t disabled the likely outcome is a false positive trigger. Léonie. -- Léonie Watson E. tink@tink.co.uk T. @LeonieWatson S. Leonie.Watson W. tink.co.uk
Received on Wednesday, 5 December 2012 17:55:27 UTC