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

Re: [webappsec] UISecurity input protection: same origin or same document?

From: Brad Hill <hillbrad@gmail.com>
Date: Thu, 31 Oct 2013 11:15:54 -0700
Message-ID: <CAEeYn8ixFEiQVEL3mrXH0qC4ue23pdnyx2QVzhLDqkK_=3KdbQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Thanks, and that raises another good question.  Should we prohibit
displaying content with an input-protection policy in a seamless iframe?
 Because CSS gets cascaded into such a frame, it arguably already has no UI
integrity from it's parent - but seamless also already requires that the
parent be same-origin.

Should an input-protection policy be treated as "frame-options 'deny'" when
a resource is embedded with the seamless flag?

Or should we allow it, because the embedder must be same-origin?  If yes,
should we cascade input-protection from the embedding parent (including
selectors) or attempt to continue to enforce it as-specified?

On Thu, Oct 31, 2013 at 10:52 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> On Thu, Oct 31, 2013 at 5:25 PM, Brad Hill <hillbrad@gmail.com> wrote:
> > The current input protection heuristic says that repaint events or
> > obstructions caused by a different document trigger a violation.
> >
> > As it is likely that user agents may composite together rendering of
> nested
> > iframes from the same origin, are there any objections to weakening the
> > heuristic from being same-document to merely same-origin, to avoid
> another
> > implementation barrier here?
> It seems likely for <iframe seamless> (which we want cross-origin too)
> but I might be missing what this is about.
> --
> http://annevankesteren.nl/
Received on Thursday, 31 October 2013 18:16:22 UTC

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