[whatwg] The <iframe> element and sandboxing ideas

[Ian Hickson]

(Please only cc one mailing list when replying, to reduce cross-posting.)

On Sun, 25 May 2008, Jon Ferraiolo wrote:
> 
> Olaf suggested that there might be another attribute to propagate 
> events. This is definitely highly desirable in some scenarios. Note that 
> the CDF WG has done some work that relates at least partially, although 
> I wouldn't be surprised if Ian isn't all that positive on CDF. 
> Nevertheless, here is the spec: http://www.w3.org/TR/WICD/. The WICD 
> spec focuses on various aspects of not just event propagation, but also 
> hyperlink propagation and focus management. All of these topics seem 
> worthy of consideration in terms of bridging between the host web page 
> and any of the iframes it embeds.

I think this would be an interesting area to extend into, but I think we 
should wait until we have more experiense with <iframe sandbox> and 
<iframe seamless> before going there. I have, however, noted this proposal 
with the WICD link in the spec.


> 3) It seems to me that for some of the propagation areas (e.g., CSS 
> propagation, event propagation, focus-model integration) you would want 
> both the container and the component to opt-in before the propagation 
> occurred. For example, with CSS propagation, there may be cases where 
> the component only wants certain of its own characteristics to be 
> stylable by the parent. If you look at typical Ajax widgets, which use 
> CSS for controlling the visual rendering, there are some aspects which 
> are meant to be stylable by the developer, some aspects that are meant 
> to be "themable" (i.e., stylable via a shared theme), and other aspects 
> which the widget needs to control exclusively and should not be 
> overridden.

For widgets, XBL2 is probably the better way of dealing with this.


> I would assume that there are also security issues with allowing the 
> parent to override the styling of an embedded iframe because conceivably 
> someone could invoke a bank website within an iframe and it wouldn't be 
> good if the parent could override some of the CSS for the bank's 
> website. Similarly, you probably wouldn't want the parent frame to be 
> able to listen to keystrokes that happen within the child iframe (e.g., 
> your password). For some of the information passing between parent and 
> child, it might be best to somehow use a publish/subscribe mechanism 
> like how postMessage() works, where both both parent and child have to 
> opt-in before the propagation occurs.

Since seamless="" only works for same-origin resources anyway, I don't 
think there's any new problem here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'