Re: UI Safety Obstruction check and transforms

Hi.
for the "block" mode,
do you mean the safe-zone in browser sandbox?

how about to improve the concept of Signed-JS (
http://www.mozilla.org/projects/security/components/signed-scripts.html) ?

or

at least we have integrity values of initial JS source, we can protect more.


On Wed, Dec 5, 2012 at 9:42 AM, Hill, Brad <bhill@paypal-inc.com> 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> 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
> To: fredandw@live.com
> CC: 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> 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****
>
> ** **
>
> ** **
>



-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World