Cross Frame Communications Support
From RuntimeWiki
Contents |
Title
Cross Frame Communication Support
Detailed write-up
Description
By assembling and integrating pre-built “mashup widgets” (data and code) from multiple sources onto the same web page, mashups make it possible to provide high-value web solutions in a much more cost-effective manner. Depending on how page authors assemble the mashup page, these widgets on the page may have unwanted access to the state of other widgets and the page. This is a security issue.
In order for mashups to be functional and secure, mashup widgets need not only ways to interact with each other, but also proper isolation from each other without unwanted accesses. With the current browser infrastructure, the viable way to properly isolate mashup widgets from each other to prevent unwanted access is to use “iframe”. For example, IBM researchers proposed “SMash” that uses iframe to isolate different widgets. OpenAjax Alliance is also considering using “iframe” as the mechanism for providing secure mashups.
However, due to the lack of cross frame communication mechanism, interaction between widgets in different frames is not possible except for a certain hacking. “SMash” uses the fragment ID of the URLs of different iframes to enable communication between them. Though this hack works on all browsers, it is not performant nor it is suitable for passing a large amount of data.
Possible Solution
We don't need a W3C standard for this. We just need browsers to implement something that can be used by Ajax toolkits under the hood. One or two JavaScript API methods would be sufficient, such as window.notify (topic, some data).
Background material that request this feature
- Gideon Lee
- Jon Ferraiolo
- Mashup Security Approaches
- SMash: Secure Cross-Domain Mashups on Unmodified Browsers“
Discussion
In this section, the contributors should express their opinions about this feature request, such as providing particular technical analysis or describing in prose why this feature is important (or not). It is recommended that each contributor create his own level-3 sub-section (e.g., === Jon Ferraiolo Comments ===).
It is OK for others to insert comments within other people's sections, but as a courtesy please make sure that it is clear which part of the section is original and which section are annotative comments. For example, perhaps annotative comments would be colorized (e.g., enclosed by <span style="color:red">JON: Here is what I think about what you are saying.</span>).
Jon Ferraiolo comments
Although my wiki page used the topic name "Mediated Cross-Frame Messaging", I don't think we need the browsers to do any mediating per se, just provide a publish/subscribe mechanism for cross-frame messaging from a child IFRAME to/from its parent so that mashups can work in a performant manner. Right now, mashups have to resort to slow communications hacks such as the IFRAME proxy approach which requires chunking the data and polling for changes. We want to have a replacement approach. We don't need a W3C standard for this, we just need particular browsers to implement something that can be invoked by JavaScript logic (e.g., OpenAjax Hub 1.1's secure mashup framework), even if there is conditional logic to invoke different low-level APIs for different browsers. Note that Google Gears probably can address this need, as can the cross-frame messaging feature in HTML5, so most likely if Gears is bundled or HTML5 cross-frame messaging is implemented, we don't need anything else.
Phase I Voting - Vote for Your Top 5 Features
NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:
Phase II Voting
More about this later.
