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

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/
>