W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2013

Re: [webappsec] ISSUE-53: UISecurity input-protection heuristic for composited rendering

From: Giorgio Maone <g.maone@informaction.com>
Date: Sat, 26 Oct 2013 09:49:19 +0200
Message-ID: <526B73FF.70900@informaction.com>
To: robert@ocallahan.org
CC: Brad Hill <hillbrad@gmail.com>, David Lin-Shung Huang <linshung.huang@sv.cmu.edu>, "public-webappsec@w3.org" <public-webappsec@w3.org>, jamesr@google.com
Rob, thank you very much for contributing to this discussion about
https://dvcs.w3.org/hg/user-interface-safety/raw-file/43644c06b379/user-interface-safety.html#alt_heuristic

On 25/10/2013 16:23, Robert O'Callahan wrote:
> I think we could implement 9.3. We're already planning to add a
> frame-level compositor-based screenshot API to Gecko.
Great to hear that. Could you please CC me on the relevant Bugzilla
entries? It might be useful for NoScript's ClearClick as well, which
currently relies on Mozilla's privileged context.drawWindow() canvas API.

> I think it's viable. Clicking on an input-protected frame would be
> slowed down a little bit while we read back data for comparison, but
> that that's surely OK.
> My main concern about this whole proposal would be whether the false
> positive rate is acceptably low.
Considering that, differently from NoScript's ClearClick which is
"blind" and enabled by default, this proposal would be opt-in for the
protected resource and tailored on it, I think we're covered on that side.

>     Also if you know any other field expert from
>     Mozilla/Google/Apple/Microsoft who may want to help, please let us
>     know.
>
>
> James Robinson at Google.
CCed here. Mr. Robinson, anything about Webkit/Blink? Thanks in advance.

-- G



On 25/10/2013 16:23, Robert O'Callahan wrote:
> On Wed, Oct 23, 2013 at 12:13 AM, Giorgio Maone
> <g.maone@informaction.com <mailto:g.maone@informaction.com>> wrote:
>
>     I think before giving up we should ask some browser folks actually
>     well
>     versed in their layout/rendering implementations to chime in and
>     tell us
>     whether what we're trying to accomplish is more or less viable, and/or
>     if there's a better approach to achieve the same goals.
>
>
> I think it's viable. Clicking on an input-protected frame would be
> slowed down a little bit while we read back data for comparison, but
> that that's surely OK.
>
>     https://dvcs.w3.org/hg/user-interface-safety/raw-file/43644c06b379/user-interface-safety.html#alt_heuristic
>
>     ? Any comments/suggestions? Many thanks in advance!
>
>
> I think we could implement 9.3. We're already planning to add a
> frame-level compositor-based screenshot API to Gecko.
>
> My main concern about this whole proposal would be whether the false
> positive rate is acceptably low.
>
>     Also if you know any other field expert from
>     Mozilla/Google/Apple/Microsoft who may want to help, please let us
>     know.
>
>
> James Robinson at Google.
>
> Rob
> -- 
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny 
> eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha
> iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e 
> tfaokreg iyvoeunr, 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt
> hwea lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w  *
> *
Received on Saturday, 26 October 2013 07:49:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC