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

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

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 25 Oct 2013 16:23:02 +0200
Message-ID: <CAOp6jLYzs3sKKp=rcj2OYv0rbsRWyimNk4n3fbVcgppPCFKe0Q@mail.gmail.com>
To: Giorgio Maone <g.maone@informaction.com>
Cc: Brad Hill <hillbrad@gmail.com>, David Lin-Shung Huang <linshung.huang@sv.cmu.edu>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Oct 23, 2013 at 12:13 AM, Giorgio Maone <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.

> ? 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.

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 Friday, 25 October 2013 14:23:29 UTC

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