W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] AllowSeamless feedback

From: Markus Ernst <derernst@gmx.ch>
Date: Fri, 18 Jan 2013 14:23:27 +0100
Message-ID: <50F94CCF.2060403@gmx.ch>
To: Nasko Oskov <nasko@chromium.org>
Cc: whatwg@whatwg.org
Am 15.01.2013 00:39 schrieb Nasko Oskov:
> Hi whatwg,
> I recently became aware of the proposal to add AllowSeamless attribute that
> will permit cross-origin seamless iframes (
> http://wiki.whatwg.org/wiki/AllowSeamless). We are currently working on a
> new security policy in Chrome, which will separate each site into its own
> renderer process. More information can be found at
> http://www.chromium.org/developers/design-documents/site-isolation.

Re-reading this Chromium document, I had the idea that AllowSeamless may 
be a special case of something which should rather be like 
"AllowSameOrigin"?

A document that allows to be treated as same-origin by the including 
document would then be removed from the "siteInstance" (or security 
context) of its own origin, and added to the one of the including document.

I think that per-origin control would be necessary in this case, so it 
would look somehow like:
<meta name="allow-same-origin" content="foo.net, bar.com">
Or:
<html allow-same-origin="foo.net, bar.com">
<html allow-same-origin="all">

I see the following advantages compared to an AllowSeamless solution:
- New spec is only needed for the mechanism itself. All issues that 
derive from the mechanism are already covered by the same-origin policy.
- Authors who decide to use AllowSameOrigin in a resource are more 
likely to be aware of security risks than they were about an 
AllowSeamless solution (which actually sounds like something purely 
design-related)

(Excuse me in case this is a silly idea - I am a web author with zero 
knowledge on browser implementation.)
Received on Friday, 18 January 2013 13:24:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT