W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2012

RE: UI Safety Obstruction check and transforms

From: Fred Andrews <fredandw@live.com>
Date: Wed, 5 Dec 2012 12:55:03 +0000
Message-ID: <BLU002-W5583719ECF08A22540DDB8AA460@phx.gbl>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Thank you for the feedback David, Brad, and Giorgio.

If it were technically possible to present an input protected frame un-transformed and un-obscured then this still seems to me to be the best solution for the use case of a user wanting to protect content not designed to use the new UI safety event flags etc.  For example input protection enabled via UserCSP.  This need only be applied when the obstruction check fails, so should not affect the majority of content.  Even using the new 'unsafe' flag, widgets will likely redirect to a new window to be unframed upon an obstruction test failure.  Advertisements in an iframe can already expand when the mouse moves over them (with the cooperation of the parent), and pop up windows are generally permitted in response to an intentional events, so it is not immediately clear what extra pop-up capability might be exploitable to annoy the user but I appreciate this deserves more consideration.  Perhaps there are some technical show stoppers to this option.

I agree that reacting to the 'unsafe' flag would be a good design for framed widgets.  These widgets likely already open in an unframed window for safety when necessary (prompting the user), but can now use the 'unsafe' flag to detect some situations in which they can handle input safely while being framed.  This has a good deployment path, and seems a clear win for this spec.  If widget input fails the obstruction check then it can just fall back to prompting the user in an unframed window.  The only issue would be widget authors that start to depend on the obstruction check alone and do not redirecting to an unframed page upon failure.  The 'unsafe' event flag does not help if JS is disabled.

Giorgio, a fallback url may not help the use case of protecting content not written with the UI safety spec. in mind.  It might help the JS-disabled case, and this might be something I am personally interested in for PUA options.  If JS is enabled then the 'unsafe' event flag could be checked and might be used to better effect.  It appears that ClearClick is still needed to protect general content and can not yet be replaced by UserCSP.

It is a complex solution space.  I would need to explore the technical practicality of popping up an iframe to help more.


Date: Wed, 5 Dec 2012 10:01:27 +0100
From: g.maone@informaction.com
To: bhill@paypal-inc.com
CC: linshung.huang@sv.cmu.edu; fredandw@live.com; public-webappsec@w3.org
Subject: 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"


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

            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.
            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
                  David Lin-Shung Huang

                  Sent: Wednesday, November 28, 2012 12:03 PM

                  To: Fred Andrews

                  Cc: public-webappsec@w3.org

                  Subject: Re: UI Safety Obstruction check and
          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).
              On Wed, Nov 28, 2012 at 3:45 AM, Fred
                Andrews <fredandw@live.com>


                    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


                    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.



                    Date: Wed, 28 Nov 2012 00:22:33

                      From: linshung.huang@sv.cmu.edu

                      To: fredandw@live.com

                      CC: public-webappsec@w3.org

                      Subject: Re: UI Safety Obstruction check and


                          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.
                            On Wed, Nov 21, 2012 at
                              2:21 AM, Fred Andrews <fredandw@live.com>
                                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


                                  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


                                  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.



Received on Wednesday, 5 December 2012 12:56:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:30 UTC