- From: Markus Ernst <derernst@gmx.ch>
- Date: Tue, 15 Jan 2013 14:44:31 +0100
- To: Nasko Oskov <nasko@chromium.org>
- Cc: whatwg@whatwg.org
Am 15.01.2013 01:36 schrieb Nasko Oskov: > On Mon, Jan 14, 2013 at 3:48 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > >> On Tue, Jan 15, 2013 at 12:39 AM, Nasko Oskov <nasko@chromium.org> wrote: >>> Based on the existing security concerns listed in the proposal and the >> fact >>> that it might prevent a useful new security architecture in browsers, I >>> would suggest this not be added to the web platform. >> >> FWIW, I think that "limitation" is known. (At least I cannot remember >> the last time someone actually proposed new API surface requiring >> synchronous access between two cross-origin Window objects.) <iframe >> seamless> could still be useful however cross-origin, even without >> cross-boundary events. >> > > The input events was just one example. There are other cases where having > an asynchronous boundary can lead to unexpected behavior for developers. [...] > It's not clear whether implementing these asynchronously will lead to a > good experience. The allow-seamless mechanism is to be triggered at the side of the embedded resource, which would also be the one affected by possible security risks (if I get this right). The developer of this resource will have to be aware of these risks, and avoid to expose critical stuff in pages that allow seamless embedding. So, would it be possible to generally treat resources that allow seamless embedding as same-origin from the security POV? (It would be a real pity if a useful security architecture would prevent a useful inclusion mechanism, and vice versa.)
Received on Tuesday, 15 January 2013 13:45:02 UTC