My favorites | Sign in
Project Home Downloads Wiki Issues Source
Search
for
IWCProjects  
List of system that enable inter-window or web worker communication
Featured
Updated Aug 31, 2011 by izuzak

This page will not be actively maintained. However, we have published a paper about the classification framework for cross-context communication in Web browsers together with a broad evaluation of existing systems. The paper presents a more detailed and advanced analysis of cross-context communication than the one addressed in this wiki page. You can find the paper here.

--- --- --- ---

This is an overview of systems that enable communication between different contexts or web workers running in the browser. The overview includes systems that enable program A executing in the browser to send data to program B also executing in the browser and enable program B to receive the sent data. Programs A and B must be web applications executing in different browsing context (windows, iFrames) or web workers.

This problem of web applications development is not new and lots of systems have been researched and built with the purpose of solving it. Therefore, let us know (in the comments of this page) if we didn't list a system you know of or if we mis-categorized a listed system. Also, some relevant systems that are either insufficiently described, not implemented (research concept) or archaic were left out from the overview but are listed at the end, with references.

Below is also a list of other articles that surveyed or analyzed this type of communication.

Each system is categorized based on the following criteria:

  • Mechanism or system name - name of system for cross-context communication or group of systems with same properties.
  • Type of system - is the system a simple mechanism implemented in browsers (browser built-in), a client-side system that doesn't in any way communicate outside the browser (pure client-side framework), a system that requires calls to a server component only to initiate a communication channel but not for actual data exchange (server-mediated initialization framework) or a system that routes messages through a server component (server-mediated communication framework)?
  • Cross-origin or same origin - does the system support cross-origin communication, only same origin or something else?
  • Cross-browser communication - can the system be used for cross-browser communication?
  • General purpose or application specific - can the system be used in any kind of web application or is it bound to a certain subset?
  • Browsing context support - does the mechanism support communication with browsing contexts?
  • Web worker support - does the mechanism support communication with workers?
  • Transport mechanism - which mechanism or system is used to transfer data from the sender and to the receiver?
  • Programming model - what type of programming model is exposed to programmers: message-oriented, shared-memory, publish-subscribe, rpc, streams?
  • Reliability - what kinds of reliability and fault tolerance does the system provide?
  • Discovery - does the system support discovery of possible receiving contexts and possibly a finer-grained level of discovery?
  • (TODO) Maximum message length - is there a limit to the size of messages that can be transported using the system?
  • (TODO) Message confidentiality -
  • (TODO) Message integrity -
  • (TODO) Sender authentication -
  • (TODO) Receiver authentication -
  • (TODO) Access control on receiver -
  • (TODO) Access control on sender -
  • Browser support - which browsers support the system?
  • Other notes - other relevant notes on the system.
  • More info - links to sites containing more information on the system.

Acknowledgments :

Related work, security considerations and existing systematizations

  1. Google Caja
  2. ADSAFE.
  3. Browser Security Handbook, especially sections on Gaps in DOM_access control and Script restriction frameworks
  4. K. Vikram, M. Steiner, Mashup component isolation via server-side instrumentation.
  5. A. Barth, C. Jackson, J. C. Mitchell, Securing Frame Communication in Browsers.
  6. A. Barth, J. Weinberger, D. Song, Cross-Origin JavaScript Capability Leaks: Detection, Exploitation, and Defense
  7. A. Barth, C. Jackson, W. Li, Attacks on JavaScript Mashup Communication.
  8. MASH SSL.
  9. F. De Keukelaere, S. Bhola, M. Steiner, S. Chari, S. Yoshihama, SMash: Secure Cross-Domain Mashups on Unmodified Browsers.
  10. C. Jackson, H. J. Wang, Subspace: Secure CrossDomain Communication for Web Mashups.
  11. C. Reis, Web Browsers as Operating Systems: Supporting Robust and Secure Web Programs.
  12. M. Akin, Solving Cross-Domain Issues When Building Mashups.
  13. S. Sire, A. Vagner, Increasing Widgets Interoperability at the Portal Level.
  14. S. Sire, M. Palmér, E. Bogdanov, D. Gillet, Towards Collaborative Portable Web Spaces.
  15. S. Bhola, S. Chari, M. Steiner, Security for Web2.0 application scenarios: Exposures, Issues and Challenges.
  16. J. Howell, C. Jackson, H. J. Wang, and X. Fan, MashupOS: Operating System Abstractions for Client Mashups.
  17. D. Renzel, C. Hobelt, D. Dahrendorf, M. Friedrich, F. Modritscher, K. Verbert, S. Govaerts, M. Palmer, E. Bogdanov, Collaborative Development of a PLE for Language Learning
  18. D. Crockford The module Tag.
  19. D. Akhawe, A. Barth, P. E. Lam, J. Mitchell, D. Song, Towards a Formal Foundation of Web Security
  20. S. Hanna, R. Shin, D. Akhawe, P. Saxena, A. Boehm, D. Song, The Emperor’s New API: On the (In)Secure Usage of New Client Side Primitives
  21. C. Reis, S. D. Gribble, H. M. Levy, Architectural Principles for Safe Web Programs

References

[1] A. Barth, HTTP State Management Mechanism, IETF Internet-Draft. Link

[2] I. Hickson, HTML5 - Section 5 Loading Web pages, subsection 5.2 The Window object, subsection 5.2.1 Security, W3C draft. Link. C. Jackson, H. J. Wang, Subspace: Secure CrossDomain Communication for Web Mashups. Link.

[3] J. Lecomte, Introducing CrossFrame, a Safe Communication Mechanism Across Documents and Across Domains. Link.

[4] I. Zuzak, M. Ivankovic, The pmrpc library homepage. Link.

[5] S. Kinsey, The easyXDM framework homepage. Link.

[6] Apache Shindig RPC feature source code. Link.

[7] Apache Shinding PUBSUB feature source code. Link.

[8] The open-app project homepage. Link.

[9] I. Hickson, HTML5, Cross document messaging. Link.

[10] I. Hickson, HTML5, Channel messaging Link.

[11] I. Hickson, WebStorage, W3C draft. Link.

[12] I Hickson, Web SQL Database, W3C draft. Link.

[13] Apache Shindig, RMR transport implementation. Link.

[14] Apache Shindig, NIX transport implementation. Link.

[15] Apache Shindig, FrameElement transport implementation. Link.

[16] Postmessage jQuery plugin homepage. Link.

[17] xssinterface project homepage. Link.

[18] jQuery postmessage plugin homepage. Link.

[19] jquery hive plugin homepage. Link.

[20] I. Hickson, Web Workers, WHATWG draft. Link.

[21] OpenAjax Hub Specification 2.0. Link. OpenAjax Alliance implementation of OpenAjax Hub 2.0 Link.

[22] F. De Keukelaere, S. Bhola, M. Steiner, S. Chari, S. Yoshihama, SMash: Secure Cross-Domain Mashups on Unmodified Browsers. Link.

[23] Google Wave gadgets tutorial - Gadget state. Link.

[24] T. Nelkner, An Infrastructure for Intercommunication Between Widgets in Personal Learning Environments. Link.

[25] S. Wilson, P. Sharples, D. Griffiths, Distributing education services to personal and institutional systems using widgets. Link.

[26] E. Mullins, Local Connection Actionscript – Communicate between seperate Flash files. Link. Adobe Support, An example of communication between JavaScript and Adobe Flash Player. Link. Adobe support, LocalConnection. Link.

[27] (patent) H. Schneider, Communication between browser windows. Link.

[28] (patent) J. C. Everett-Church, Communication among browser windows Link.

[29] (patent) A. J. Simonoff, Interactive communication system permitting increased collaboration between users. Link.

[30] (patent) G. Clayton, V. Chen, A. Athsani, R. Martinez, System and method of inter-widget communication. Link.

[31] (patent) G. Corvera G. Moore D. Thorpe K. Kato, Inter-frame messaginf between different domains. Link.

[32] S. Zarandioon, D. Yao, V. Ganapathy, OMOS: A Framework for Secure Communication in Mashup Applications. Link.

[33] K. Zyp, http://www.sitepen.com/blog/2008/07/22/windowname-transport/. Link.

[34] Window.name transport implementation in easyXDM framework. Link.

[35] C. Jackson, H. J. Wang, Subspace: Secure Cross-Domain Communication for Web Mashups. Link.

[36] L. Hilaiel, jsChannel. Link.

[37] P. Kinlan, Web intents. Link.

Comment by okinsey, May 3, 2010

easyXDM: cross-origin | no | window.name, FIM, postMessage | message oriented, exposes RPC API, not yet (exposes the origin) | yes | async | push

Comment by okinsey, May 10, 2010

easyXDM isn't really 'server mediated' as it does not communicate with the server. It only requests a file (a special html file for window.name, and any url for FIM), which due to aggressive caching should only need be retrieved on the first request. This is in turn only to facilitate 'client-client' communication.

Comment by okinsey, May 12, 2010

The reference you have used for Window name attribute 33? isn't really in-browser as it is based on communication with the server.

Comment by project member izuzak, May 12, 2010

@okinsey: You're right. However, it does explain the mechanics of passing data unidirectionally between a window which creates another window, using the window.name parameter. I'll be glad to replace the current reference if you have a better one. Thanks!

Comment by bcop...@gmail.com, May 12, 2010

Well JMS is working at the server-level but can also push data (or be polled) with an AJAX client, or, any other combination of a server-side and one of the above systems...

JMS | in-browser and desktop | cross-origin | cross browser and cross-os instance (for desktop) | general purpose | yes | yes | (RESTful) HTTP or STOMP (TCP) | Topics (publish-subscribe) OR Queues (transactional) | yes | yes | all Topic-based pub/sub may expose data to all listening application instances (unless other encryption/filters or Broker-specific transport controls are applied) | JMS product/spec: http://java.sun.com/products/jms/ Apache ActiveMQ (popular implementation): http://activemq.apache.org/ | " unlimited... Max 70MB by default, but protocol should be limited only by implementation/server supports encrypted/signed messages... | Implementation-specific; spec speficies support for reliable message transfer | In-message, or, in the Broker connection management itself | In-message, or, in the Broker connection management itself | depends on chosen protocol/broker | depends on chosen protocol/broker


Sign in to add a comment
Powered by Google Project Hosting