Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
On Mon, 3 Dec 2012, Mikko Rantalainen wrote: It seems to me like the best solution is to have a new HTTP header, with the four following values being allowed: Seamless-Options: allow-shrink-wrap Seamless-Options: allow-styling Seamless-Options: allow-shrink-wrap allow-styling Seamless-Options: allow-styling allow-shrink-wrap Not that I fancy for expendable advertisement, but I fail to see how that is supposed to work with those headers. Basically I think that in such case, the host document should be able to specify something like following: (1) I want to embed a seamless untrusted iframe here, and (2) iframe should have maximum size of e.g. 480x240 pixels (or any size set via CSS max-width/max-height). However, if user interacts (I guess moving focus inside the iframe is enough) with the iframe, then max-width and max-height are set to expanded state (whatever that means). It's not clear to me why the host would need to control this with the UA's help. If you trust the embedded page to say when it needs to expand, which it seems you must for any but the most trivial of interaction models, then you can just trust the page to expand any time it wants. If you don't trust the page at all, it seems dangerous to embed it at all, since it can spoof you (it's a seamlessly embedded page, after all). (You can set maximum dimensions using CSS, in any case -- the iframe is still just a regular block, so max-height applies.) Does there need to be any support for expendable seamless iframe without scripting? I doubt it, but in principle I don't see why scripting would be needed. On Mon, 3 Dec 2012, Adam Barth wrote: Yeah, I can see how you ended up with an HTTP header. I wonder if it would make sense to align this stylistically with CORS. For example: Access-Control: allow-shrink-wrap, allow-styling I don't know. Using CORS-like headers seems misleading to authors, they might think that they work together. Then for the per-origin control, we would extend CSP to have a flag for limiting who is allowed to embed you (subsuming X-Frame-Options, essentially). That's already planned for CSP [...] What progress has there been on the CSP front in terms of allowing a page to list which origins can embed it? That's the main missing link here; I'd really rather not reinvent CORS just for seamless iframes. (We can't use CORS itself, obviously, since that would grant reading privileges.) The proposed solution for cross-origin iframes is still the solution proposed at the bottom of this e-mail: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html On Sat, 15 Dec 2012, Jonas Sicking wrote: One solution would be not not render the contained document in the iframe seamless= until we hit the element that opts in to cross-origin seamless rendering. If the document never opts in, it'll never get rendered, but is still loaded. This might be non-trivial to implement though since I believe that unrendered documents is not something that exists in the platform today. The simplest way to emulate it would be to make the iframe act as if it was display:none. The other problem with markup is that it's mutable, which means we'd have to define how and when it takes effect and how to react to changes, and there's typically difficulties with dealing with race conditions and it can be vulnerable to injection attacks. Working around these is possible; we did so to a great extent with manifest=, but it requires deep integration into things like the parser and navigation algorithms. On Mon, 14 Jan 2013, Nasko Oskov wrote: 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 One of the requirements of this model is that cross-origin iframes will be rendered in a separate process from the main document. Since seamless iframes are currently allowed only if they are same-origin, this works fine. If we move to a mode where seamless iframes are allowed for cross-origin pages, it makes our isolation model very difficult to implement correctly. An example would be input events, which according to our reading of the spec for seamless should cross the iframe boundary. This means that we have to maintain synchronous model for event capture/bubble phases across multiple processes, which is prone to either deadlocks or environment inconsistency. 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. How would you propose to address the use cases instead? http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0006.html (Having said that, if we don't
Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
On Wed, Dec 5, 2012 at 8:54 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Dec 2012, Jonas Sicking wrote: It seems to me like the best solution is to have a new HTTP header, with the four following values being allowed: Seamless-Options: allow-shrink-wrap Seamless-Options: allow-styling Seamless-Options: allow-shrink-wrap allow-styling Seamless-Options: allow-styling allow-shrink-wrap I guess it depends how costly you think it is to mint new HTTP headers rather than having fewer, harder working headers. I hear no end of people arguing that HTTP headers are too hard for people to use. Could we make these settable through meta elements as well as, or instead of, using headers. The problem is that we need to have the information before we create the Document, since once the Document is created the page might be rendered, and if the information comes after the Document is rendered, there would be flicker (different sizes for the iframes, different styles in the iframes). One solution would be not not render the contained document in the iframe seamless= until we hit the element that opts in to cross-origin seamless rendering. If the document never opts in, it'll never get rendered, but is still loaded. This might be non-trivial to implement though since I believe that unrendered documents is not something that exists in the platform today. The simplest way to emulate it would be to make the iframe act as if it was display:none. / Jonas
Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
On Mon, Dec 3, 2012 at 9:57 AM, Adam Barth w...@adambarth.com wrote: On Fri, Nov 30, 2012 at 6:57 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 26 May 2012, Adam Barth wrote: [CSP] CSP doesn't seem to include any features that would let you limit who is allowed to iframe you, so I don't think CSP as designed today provides a solution for the per-origin part. Could it be extended? The current plan is for X-Frame-Options to become a CSP directive. CSP is quite extensible. The only hard restrictions are that new directives conform to this grammar (yes, error handling for parsing is also defined): directive = *WSP [ directive-name [ WSP directive-value ] ] directive-name= 1*( ALPHA / DIGIT / - ) directive-value = *( WSP / VCHAR except ; and , ) Philosophically, the current plan is to use CSP for things that might be called content restrictions, i.e., for restricting what a document might otherwise be able to do. As I wrote on the wiki [1], it's not a great match for this use case because here we're loosening restrictions rather than tightening them. Of course, this philosophy might evolve over time, so I wouldn't necessarily treat it as a hard-and-fast rule. [X-Frame-Options] This doesn't let you chose on a per-origin basis whether you can be framed either (since you don't get an Origin header in the request, and the X-F-O header only gives a thumbs-up or thumbs-down in general). I'm dubious about extending X-F-O since it lacks a spec and so how exactly to change it in a backwards-compatible way is unclear and getting it wrong would be very dodgy. On Thu, 12 Apr 2012, Ojan Vafai wrote: we could add a special http header and/or meta tag for this, like x-frame-options, but for the child frame to define it's relationship to the parent frame. Yeah. It seems to me like the best solution is to have a new HTTP header, with the four following values being allowed: Seamless-Options: allow-shrink-wrap Seamless-Options: allow-styling Seamless-Options: allow-shrink-wrap allow-styling Seamless-Options: allow-styling allow-shrink-wrap (Split on spaces, ignore unknown tokens.) Assuming that these are order independent, it's slightly more idiomatic for HTTP to use , as a delimiter. Then for the per-origin control, we would extend CSP to have a flag for limiting who is allowed to embed you (subsuming X-Frame-Options, essentially). That's already planned for CSP (e.g., http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html#frame-options is one current proposal). For the case of things that can be embedded by anyone but only seamlessly by paying clients, I would recommend putting the origin in the URL, and then limiting the embedding to that URL using CSP. Is this a viable direction? Yeah, I can see how you ended up with an HTTP header. I wonder if it would make sense to align this stylistically with CORS. For example: Access-Control: allow-shrink-wrap, allow-styling I guess it depends how costly you think it is to mint new HTTP headers rather than having fewer, harder working headers. I hear no end of people arguing that HTTP headers are too hard for people to use. Could we make these settable through meta elements as well as, or instead of, using headers. / Jonas
Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
Am 05.12.2012 10:45 schrieb Jonas Sicking: I hear no end of people arguing that HTTP headers are too hard for people to use. Could we make these settable through meta elements as well as, or instead of, using headers. I am one of those authors with limited technical background. IMHO the crucial point is that the solution works in shared hosting environments, without access to server configuration and hopefully without .htaccess hacks. Thus, everything that can be done via PHP or other server-side scripting should be ok. A meta element would be handy, but ?php header(...) ? is reasonable, too. Meta elements may have the downside that copy-paste authors who don't understand them may leave them in the code where they may be unnecessary or even harmful.
Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
On Wed, 5 Dec 2012, Jonas Sicking wrote: It seems to me like the best solution is to have a new HTTP header, with the four following values being allowed: Seamless-Options: allow-shrink-wrap Seamless-Options: allow-styling Seamless-Options: allow-shrink-wrap allow-styling Seamless-Options: allow-styling allow-shrink-wrap I guess it depends how costly you think it is to mint new HTTP headers rather than having fewer, harder working headers. I hear no end of people arguing that HTTP headers are too hard for people to use. Could we make these settable through meta elements as well as, or instead of, using headers. The problem is that we need to have the information before we create the Document, since once the Document is created the page might be rendered, and if the information comes after the Document is rendered, there would be flicker (different sizes for the iframes, different styles in the iframes). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
Ian Hickson, 2012-12-01 04:57 (Europe/Helsinki): ...and Adam Barth posted some on the wiki: Expandable Advertisement: A publisher wishes to display an advertisement that expands when the user interacts with the advertisement. Today, the common practice is for the advertising network to run script in the publisher's page that receives postMessage instructions to resize the advertisement's iframe, but this requires that the publisher allow the advertisement to run script in its page, potentially compromising the publisher's security. It seems to me like the best solution is to have a new HTTP header, with the four following values being allowed: Seamless-Options: allow-shrink-wrap Seamless-Options: allow-styling Seamless-Options: allow-shrink-wrap allow-styling Seamless-Options: allow-styling allow-shrink-wrap Not that I fancy for expendable advertisement, but I fail to see how that is supposed to work with those headers. Basically I think that in such case, the host document should be able to specify something like following: (1) I want to embed a seamless untrusted iframe here, and (2) iframe should have maximum size of e.g. 480x240 pixels (or any size set via CSS max-width/max-height). However, if user interacts (I guess moving focus inside the iframe is enough) with the iframe, then max-width and max-height are set to expanded state (whatever that means). Is it possible for host document to detect that the focus is within the iframe from cross-origin location? If yes, then all we need is cross-origin seamless iframe and a host document script that increases the max-width and max-height limitations for the seamless iframe. Does there need to be any support for expendable seamless iframe without scripting? -- Mikko
Re: [whatwg] Making cross-origin iframe seamless= (partly) usable
On Fri, Nov 30, 2012 at 6:57 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 26 May 2012, Adam Barth wrote: [CSP] CSP doesn't seem to include any features that would let you limit who is allowed to iframe you, so I don't think CSP as designed today provides a solution for the per-origin part. Could it be extended? The current plan is for X-Frame-Options to become a CSP directive. CSP is quite extensible. The only hard restrictions are that new directives conform to this grammar (yes, error handling for parsing is also defined): directive = *WSP [ directive-name [ WSP directive-value ] ] directive-name= 1*( ALPHA / DIGIT / - ) directive-value = *( WSP / VCHAR except ; and , ) Philosophically, the current plan is to use CSP for things that might be called content restrictions, i.e., for restricting what a document might otherwise be able to do. As I wrote on the wiki [1], it's not a great match for this use case because here we're loosening restrictions rather than tightening them. Of course, this philosophy might evolve over time, so I wouldn't necessarily treat it as a hard-and-fast rule. [X-Frame-Options] This doesn't let you chose on a per-origin basis whether you can be framed either (since you don't get an Origin header in the request, and the X-F-O header only gives a thumbs-up or thumbs-down in general). I'm dubious about extending X-F-O since it lacks a spec and so how exactly to change it in a backwards-compatible way is unclear and getting it wrong would be very dodgy. On Thu, 12 Apr 2012, Ojan Vafai wrote: we could add a special http header and/or meta tag for this, like x-frame-options, but for the child frame to define it's relationship to the parent frame. Yeah. It seems to me like the best solution is to have a new HTTP header, with the four following values being allowed: Seamless-Options: allow-shrink-wrap Seamless-Options: allow-styling Seamless-Options: allow-shrink-wrap allow-styling Seamless-Options: allow-styling allow-shrink-wrap (Split on spaces, ignore unknown tokens.) Assuming that these are order independent, it's slightly more idiomatic for HTTP to use , as a delimiter. Then for the per-origin control, we would extend CSP to have a flag for limiting who is allowed to embed you (subsuming X-Frame-Options, essentially). That's already planned for CSP (e.g., http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html#frame-options is one current proposal). For the case of things that can be embedded by anyone but only seamlessly by paying clients, I would recommend putting the origin in the URL, and then limiting the embedding to that URL using CSP. Is this a viable direction? Yeah, I can see how you ended up with an HTTP header. I wonder if it would make sense to align this stylistically with CORS. For example: Access-Control: allow-shrink-wrap, allow-styling I guess it depends how costly you think it is to mint new HTTP headers rather than having fewer, harder working headers. Adam [1] http://wiki.whatwg.org/wiki/AllowSeamless
[whatwg] Making cross-origin iframe seamless= (partly) usable
This thread discussed solutions for, amongst others, the following use cases, provided to me off-list by Steven Wittens: A first huge use case is Facebook Apps, which are inserted using iframes. They currently use ugly cross-frame communication methods to shrink-wrap and auto-size the iframe. As an ex-FB dev, this has always been a huge source of frustration and bugs. Facebook Apps don't want to inherit CSS from the parent site, it only means the layout will break whenever Facebook makes a stylistic change or reorganizes their CSS. Replace Facebook with any other service provider that allows some form of 3rd party development/integration through iframes. A second use case would be any sort of embeddable widget that comes with pre-baked styles (think Twitter sidebar widgets). Same problem, but in reverse. At my last job, we had a drop-in iframe product that provided an entire contest in a box, with media submission, entry browsing/searching, modal dialogs, etc. Inheriting styles from the parent page would simply destroy the careful layout of what's inside. We shrink wrapped it by requiring people to embed a script tag rather than iframe tag, using cross frame communication to send a manual measurement from the frame to the parent. Ugly, and didn't work in older browsers, and we didn't have the resources to come up with an XD-proxy workaround like Facebook has. Markus Ernst also discussed the use cases: On Fri, 13 Apr 2012, Markus Ernst wrote: I assume that one popular use case for seamlessly embedding cross-origin frame content is: A service provider allows his/her customers to embed the pages provided. In this case, the info needed is a list of domains that are allowed to embed the content, rather than an allowseemless yes/no flag. On Sun, 27 May 2012, Markus Ernst wrote: My use case is a content provider, who provides e.g. a Sudoku application or a weather forecast for wind surfers. Paying customers are allowed to embed the content seamlessly in their web sites. The content can also be embedded for free, but not seamlessly. The content provider includes some corporate info, such as his/her own logo, and a provided by XY notice and link to his/her own page. The paying customers then can apply their own styling, and set the corporate info to display:none in the style sheet of the top document, via seamless embedding. ...and Adam Barth posted some on the wiki: Dashboard: A dashboard web site wishes to display status indicators that are hosted on a number of different domains. The size of these status indicators varies depending on the status. For example, if a given domain is having difficulty, the status indicator might list the problems the domain is having. Expandable Advertisement: A publisher wishes to display an advertisement that expands when the user interacts with the advertisement. Today, the common practice is for the advertising network to run script in the publisher's page that receives postMessage instructions to resize the advertisement's iframe, but this requires that the publisher allow the advertisement to run script in its page, potentially compromising the publisher's security. So basically, we're just looking for a way to let cross-origin content opt-in to being shrink-wrapped and/or styled on a per-origin basis. On Thu, 12 Apr 2012, Adam Barth wrote: [...] something like an attribute on the html element might be a better mechanism [...] That wouldn't work because you need to know before you start parsing, because at any time after you start parsing you might have to render, and you need to have decided whether to shrink-wrap or not by then. Also, it's probably best if we don't make this something you can dynamically change while the page is loaded, at least unless there's a compelling use case. On Thu, 12 Apr 2012, Anne van Kesteren wrote: [...] the enormous growing number of one-off flags developers can attach to resources for various features is starting to get worrisome. Yes, reusing something that exists already seems like a solid win. It's not clear anything suitable exists, though. On Sat, 26 May 2012, Adam Barth wrote: [CSP] CSP doesn't seem to include any features that would let you limit who is allowed to iframe you, so I don't think CSP as designed today provides a solution for the per-origin part. Could it be extended? [X-Frame-Options] This doesn't let you chose on a per-origin basis whether you can be framed either (since you don't get an Origin header in the request, and the X-F-O header only gives a thumbs-up or thumbs-down in general). I'm dubious about extending X-F-O since it lacks a spec and so how exactly to change it in a backwards-compatible way is unclear and getting it wrong would be very dodgy. On Thu, 12 Apr 2012, Ojan Vafai wrote: we could add a special http header and/or meta tag for this, like x-frame-options, but for the child
