Talk:Communications Hub TF

From MemberWiki

Jump to: navigation, search

Local vs. Server-side Communications Hub

Gideon Lee (Oct. 19 2006) glee@openspot.com

A background assumption that is clearly worth examining is the presumed server-side nature of the AJAX communication hub. At least in some usage scenarios, a purely in-process/browser-side messaging hub may be more suitable. Such background assumption may not make any difference in terms of the messaging API. However, as a working assumption, it may be feasible to allow for both kinds as we develop an API.

Why is a local messaging hub a good idea? After all, the browser is where all AJAX applications "meet" to work together for the end users. If a user wants to copy a chart from a spreadsheet to a word processor, both the source and the target of the data transfer are in memory. It just may save the Internet a lot of bandwidth if the inter-application data transfer doesn't have to go round trip over the wire. Furthermore, the more network traffic there is, the less robust the user experience will likely become. Most importantly, there is always a higher security risk with round-about network trips.

Is it technically possible to have a messaging hub, running inside the browser, that allows applications serving from different web sites/domains to exchange data completely locally? The answer is a conditional yes. Ever since browsers got IFRAME, it has been possible for a page from one domain to incorporate web content from other domains via IFRAME. Therefore, the answer is yes, with the conditions: (1) that the messaging hub needs to exist at a parent frame and is never gone, (2) that the applications can be made to run inside IFRAMEs, and (3) that a pre-agreed data exchange mechanism is available to enable the "framed" application to exchange messages locally across frame and domain boundary with the messaging hub. If an application can exchange message with the messaging hub, the messaging hub can forward it to other applications. So everyone can talk to anyone.

The third condition (3) may seem difficult to meet. After all, there is a long established browser ban against cross-frame cross-domain scripting. For example, the Internet Explorer policy, which is adopted essentially by other browsers, is explained at About Cross-Frame Scripting and Security. However, there is a difference between cross-frame cross-domain "scripting" and cross-frame cross-domain "messaging". From a strictly security point of view, browsers have always allowed cross-frame cross-domain messaging. The very act of navigating an IFRAME to a URL with a host different than one's own is a kind of cross-frame cross-domain messaging.

As a foundation for the SameDesk project -- a "Web OS" type product, my team developed a cross-frame, cross-domain messaging strategy called Local XDDE. In a nutshell, it is based on the browser behaviors that (a) that a frame in a frameset can always navigate the URL of another sibling frame, and (b) when a frame is navigated to a new source URL that is different than its old source URL only after the # (i.e. the "anchor" or "fragment" delimiter), no page reload will take place, even though the URL change is really there. Based on these two behaviors, it is possible to have a pair of sibling frames from different domains exchange data by essentially keep changing one another's URL, using the # trailing part to send data. The actual mechanism is of course more complicated and browser specific than that. To find out more, I outlined the issues at this overview doc:

Local XDDE Overview...

For a very basic demo, visit: Local XDDE Demo...

The new default security policy for IE 7 requires a workaround demo: Local XDDE Demo, with IE 7 workaround...

I see Local XDDE primarily as a workaround strategy for existing browsers, until new browser standard allows some sort of messaging between frame boundary. In my opinion, the security will not be affected at all if the browser supports such cross-frame messaging features, if only because there is already a workaround achieving the equivalent functionality based on existing features.

But whether we choose to use a cross-frame cross-domain mechanism or otherwise, the bigger point not to lose sight of is that a local messaging hub between applications coming from different domains -- be them AJAX, Applet, or Flash -- will make the web applications a little bit more competitive against traditional desktop applications. If the situation allows, it is worth considering as an alternative to server-side communication hub.

As I said in the beginning, such background assumption may not make any difference in terms of the actual API definition. However, as an assumption, it may be feasible to allow for pure-client side hub as we develop the API.


Client-side ... some relevant experiences / considerations

John Sheridan (Nov 3, 2006) <john.sheridan@eclayer.com>

One of the key questions posed by this task force is "is the communications hub necessary from an interoperability perspective?"

For me the answer is a resounding YES! My company has developed client-side technology that we call AJAX Bridges. This is essentially a gateway technology that allows one site to masquerade as another site via XMLHttpRequest. It also incorporates specialized client-side web-servers that provide access to relational databases, image manipulation libraries, etc. Ultimately, this is technology that is likely to make it into mainstream browsers.

To date all of our deployments have been in corporate environments with browser based applications simultaneously interacting with the users computer, the corporate intranet, and the public web. This raises some very interesting issues. When you give an application running in the browser the ability to masquerade you must also ensure that you do not compromise the integrity of the whole environment. It is not just about protecting the users computer. You must also protect the corporate intranet, particularly where applications are served in whole or in part from the public-web.

For our clients, Software as a Service (SaaS) is the key driver for change. The unthinkable is happening and code delivered from outside of the confines of the corporate intranet is being allowed to play inside the corporate environment. Like most companies, our clients prefer to keep their private data within their private networks. First generation SaaS applications either requied the user to export their data to the SaaS provider, or they used unbounded embedded technologies that could breakout of the browser and consequently could not be trusted. Second generation SaaS applications can use AJAX Bridges to safely interact with the data sources within the corporate intranet without the need to export the data. The browser is where the public and private webs meet. AJAX is the bridge that connects them.

We followed some simple principles to help underpin the integrity of the applications and systems that use our AJAX Bridges. I believe that these, or a variation of these principles are required to underpin any client-side AJAX gateway. In summary ...

  • To gain access to an AJAX Bridge the browser based application is required to declare its intention to masquerade to a given target site. The AJAX Bridge then queries the target site for its AJAX Access Control List (AJAX-ACL). This AJAX-ACL is simply a text file in the root path of the target site. It describes which paths within the target site are accessible via an AJAX Bridge, and to which sites they are accessible. The AJAX Bridge guarantees to respect the AJAX-ACL for a target site. This has proven very successful for us. So if some of our clients have specialized web applications delivered from trusted SaaS providers such as SalesForce.com, those applications can be enabled to interact with content from the corporate intranet. Applications from non-trusted providers are never allowed to play outside of the browser box. The other variation on this theme is that applications served from within the corporate intranet can create AJAX-Bridges to content on the public web.
  • In our initial implementation of our AJAX Bridges we used to prompt the user each time an application declared its intention to use an AJAX Bridge. Our rationale was that the user must be informed when a browser based application served from one site is attempting to access another site. This caused much annoyance amoung our users. Our initial reaction was to make it more sophisticated and to remember the users answers. But we eventually bowed to the pressure of our users and removed this functionality.
  • Trusted AJAX Bridges are automatically provided to specialized services on the users computer.
    • Each site is provided with a directory on the users computer that is private to the site.
    • A browser based application can create its own private relational database, create and manipulate image files, create and access subdirectories and files within the private directory allocated to the site.
    • Trusted AJAX Bridges cannot be used to launch or execute applications under any circumstances. Nor are they allowed to directly interact with other applications on the users computer. I've read many articles over the past few years highlighting the security risks associated with AJAX, but these are nothing compared to the vulnerability of traditional installed client applications when exposed to the wider networked world. There are few installed client applications that could cope with the issues that would arise if a browser based application was allowed to interact directly with them.