- From: Brad Hill <hillbrad@gmail.com>
- Date: Thu, 31 Oct 2013 11:15:54 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAEeYn8ixFEiQVEL3mrXH0qC4ue23pdnyx2QVzhLDqkK_=3KdbQ@mail.gmail.com>
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