Re: UI Safety Obstruction check and transforms

Maybe an useful addition to address this use case (parent site applying
a CSS transformation to the content, with intents which may or may not
be malicious but in any case make the obstruction check trigger) would
be input-protections options like

"fallback-url=" url

a URL (absolute or relative to the current document's) to be opened if
the obstruction check fails (by default in the "_blank" context)

"fallback-context=" browsing-context-name

The context where the fallback URL should be loaded. If fallback-context
is specified by fallback-url is not, the current document is loaded
(from cache?) in the specified context.

This could be a declarative, simpler, scriptless way for authors to
provide a fallback page, shown in an independent "clean" browsing
context, to complete/confirm the transaction when using UI safety in
blocking mode and false positives are possible because of the "creative"
ways embedders may want to incorporate sensitive widgets.

How does it sound?
-- G


On 05/12/2012 01:42, Hill, Brad wrote:
>
> <hat=”editor”>
>
>  
>
> I also think we might be more willing to consider an approach to
> resolving this that does not involve prompting the user.  It is an
> explicit goal of this work to NOT prompt the user, because users are
> not prepared to understand and respond to such prompts, and therefore
> neither browsers nor application authors have any interest in
> presenting such prompts.
>
>  
>
> This is also likely only a problem with naïve use of “block” mode.  It
> seems that by using report-only or the “unsafe” property, sites could
> respond to these and other kinds of false positives in a way that
> doesn’t violate the contextual integrity of the embedding resource as
> David points out below.
>
>  
>
> Thoughts?
>
>  
>
> -Brad
>
>  
>
> *From:*David Lin-Shung Huang [mailto:linshung.huang@sv.cmu.edu]
> *Sent:* Wednesday, November 28, 2012 12:03 PM
> *To:* Fred Andrews
> *Cc:* public-webappsec@w3.org
> *Subject:* Re: UI Safety Obstruction check and transforms
>
>  
>
> Hi Fred,
>
>  
>
> The idea of providing a force-topmost (or force-opaque, etc) attribute
> or style is actually an interesting approach and has been brought up a
> couple of times by other researchers. However, as far as I know, it is
> not simple in practice for the UA to guarantee that a widget bypasses
> all transforms imposed by parents, while rendering existing webpages
> properly. One thing to keep in mind is that altering the appearance of
> webpages that are non-attacks would be unacceptable to major websites
> and browser vendors. We should also be concerned that such a feature
> might be abused by widgets/ads to override pixels on the parent
> page maliciously.
>
>  
>
> I think worth pointing out is that the obstruction detection
> approach doesn't require modifying the default appearance of existing
> webpages, and taking screenshots is rather straightforward to
> implement while agnostic to new HTML5/CSS/SVG features (proven
> feasible in ClearClick and InContext).
>
>  
>
> Thanks,
>
> David
>
>  
>
> On Wed, Nov 28, 2012 at 3:45 AM, Fred Andrews <fredandw@live.com
> <mailto:fredandw@live.com>> wrote:
>
> Hi David,
>
> Thank you for the suggestion.  I guess if a widget received an event
> with this flag set it could redirect to a confirmation page in which
> it was not framed.  However it is not clear if the event flag could be
> used to bypass a transform imposed on a widget by its parent to avoid
> the obstruction check failure.
>
> For example, consider a social widget that has simply been scaled so
> that it fails an obstruction check.  A reasonable default action for
> the UA could be to present the widget unscaled when hovering over it. 
> The UA needs to compute this unscaled view anyway for comparison so it
> may not be a big extra step.  It may well be that the spec. already
> allows a UA to do this, but it might be handy to have an event sent to
> the widgets parent document to give it the option to present the
> widget unscaled itself, and perhaps this could even link into the CSS
> to allow for 'unobstructed' styling when needed.
>
> BTW: your papers are very good resources, thanks.
>
> cheers
> Fred
>
> ------------------------------------------------------------------------
>
> Date: Wed, 28 Nov 2012 00:22:33 -0800
> From: linshung.huang@sv.cmu.edu <mailto:linshung.huang@sv.cmu.edu>
> To: fredandw@live.com <mailto:fredandw@live.com>
> CC: public-webappsec@w3.org <mailto:public-webappsec@w3.org>
> Subject: Re: UI Safety Obstruction check and transforms
>
>
>
> Hi Fred,
>
>  
>
> In Section 4 of the draft, the proposed "unsafe" boolean flag in the
> UIEvent object signals the webpage that obstruction was detected by
> the UA (whether it was caused by an attack or a benign transform).
> This allows the webpage to react with an extra confirmation dialog,
> or implement other custom fallbacks.
>
>  
>
> Thanks,
>
> David
>
>  
>
> On Wed, Nov 21, 2012 at 2:21 AM, Fred Andrews <fredandw@live.com
> <mailto:fredandw@live.com>> wrote:
>
> The issue of transforms applied to an element receiving an event has
> been discussed before and the opinion offered was that transformed
> elements are not supported.   Given that an element needs to be
> non-transformed to pass the obstruction check perhaps it would be
> appropriate to support elements being presented without transforms
> when about to receive events.  The use case would be to support rich
> UI designs that still offer UI safety.
>
> For example, consider a UI that docks social widgets at the side of a
> page and scales them down and applies a perspective transform for
> effect.  If input protection has been requested then these widgets
> would need to be presented unscaled and without the transform to pass
> the obstruction check.
>
> Could a UA recognize the issue and present the element in a little
> popup when hovering over it, or could the UA apply an extra
> confirmation step when an obstruction is detected and present the
> element unscaled and without the transform for confirmation?   If so
> then perhaps an implementation note of the possibilities would be
> appropriate.
>
> Might it be appropriate to signal an event that the webpage could use
> to implement such presentation itself, with a default left to the UA? 
> If so then the spec. would presumably need to define this event.
>
> For the case of a docked widget, a two step process would not be an
> unreasonable UI design, and is there enough support for webpage
> designers to be able to implement such a design.
>
> cheers
> Fred
>
>  
>
>  
>