[OpenAjaxSecurity] [OpenAjaxInterop] Cross-Frame Messaging (was SMash questions and issues)

Gideon Lee glee at openspot.com
Fri Sep 28 10:25:52 PDT 2007


I agree that local cross-domain communication is ugly and slow when implemented using purely cross frame fragment exchange.  That's why in SameDesk, we actually use a shared Java applet or shared Flash object to do the bulk communication; we use the fragment exchange only for the initial handshake between frames.  

When a user decides to open a foreign domain app on the webtop in SameDesk, the user simply types in the URL of the app.  The webtop opens the URL, appending a fragment which is the URL of the webtop.  So the app can then choose to communicate with the webtop if it supports XDDE.  The important point is that the two sides don't have to know and trust each other a priori.  Once the initial handshake is made, the two can negotiate between themselves the best way to communicate afterwards.

Local cross-domain communication is more useful than introduction though.  A good example is clipboard copy-n-paste.  It is just not cool, let alone secure, to copy the clip to a remote state-ful server.

BTW, all these hacks can go away if the browser vendors just decide to give us (1) a window.sendMessage to pass a string into an iframe and to a parent frame, (2) an event handler to receive the string as a normal event value. I'd think it is not too much to ask for if we lobby harder.



  ----- Original Message ----- 
  From: Kris Zyp 
  To: Gideon Lee 
  Cc: OpenAjax Alliance Security Task Force ; interop at openajax.org 
  Sent: Friday, September 28, 2007 11:42 AM
  Subject: Re: [OpenAjaxInterop] Cross-Frame Messaging (was [OpenAjaxSecurity]SMash questions and issues)

  Earlier I had suggested using the subspace approach, as I have implemented subspace and could donate my code (CrossSafe). Subspace solves most of these problems, because real JS objects can be passed between frames: no polling, no serialization, no fragmentation, no encoding, no need for compression, no 20Hz clicking. Previously it didn't sound like there was interest in this, but if there is, I will try to upload my code to the repository and when I get a chance see how it could integrate into the hub. And I should attend a meeting too... 

  On 9/28/07, Gideon Lee <glee at openspot.com> wrote: 
    My thoughts in blue.
      ----- Original Message ----- 
      From: Howard Weingram 
      To: OpenAjax Alliance Security Task Force ; interop at openajax.org 
      Sent: Friday, September 28, 2007 4:20 AM
      Subject: Re: [OpenAjaxInterop] Cross-Frame Messaging (was [OpenAjaxSecurity]SMash questions and issues)

      A. (Two layers...) I agree that there should be two API layers. But when I think about OAH pub-sub in particular, I wonder if it might impose a performance penalty if the lower-level API is generalized to be a "TCP-like" full-duplex binary data tunneling model.  It seems to me that an "email-like" string-based, one-way, and acknolwedged delivery will already be sufficient.  We will need two such pipes to do PUB and SUB.  But going from outer-frame to inner-frame requires a different implementation from the vice-versa in any case. 

      Now, I am actually not advocating either string-based or one-way only model.  (See response to C below). I'm just saying that if every character counts, there is indeed a performance difference. 

      B. Different upper level protocol implementations could 
      in fact be layered over the same lower level, and 
      different lower level protocols could implement the 
      same lower level API. We should consider standardizing
      the data stream protocol API as well as the higher level. 

      I agree.

      C. In cases where data is highly redundant and large messages
      are frequently sent, a data stream layer implemnentation might 
      include data compression. The cost of computation might be 
      much less than the cost associated with delivering fragmented data. 
      Note: I am NOT suggesting that we provide a reference implementation
      that does this. It is simply a possibility that some implemneters might
      choose for their own reasons. 

      Interesting.  Shouldn't compression be a feature of the OAH pub-sub implementations instead?  The pub-sub implementation has the whole JavaScript object/JSON structure to look at, so it could do many more clever things.  Indeed, in addition to intra-message compression, it can do inter-message compression, like building a string table dynamically. 

      At the lower level API, there really not much compression worth doing.  And we cannot forget that in the long term, the lower-level API is really meant as a lobbying effort for to the browser vendor anyway.  The browser itself can use native functionality to implement the lower level API. 

      But OAH-level compression has other significant uses in its own right -- server-side OAH in particular.

      For instance, in a mashup, the host and the widgets should by default use URL-encoded JSON as you suggest to negotiate the best compression.  But beyond the first conversation, clever OAH implementations can use more application-optimized representations to talk to each other. 

      There is clearly an opportunity for commercial competition of high-level OAH implementations and performance/compression could be a differentiation factor.  In contrast, nobody can compete with the browser when it comes to the low leverl API. 

      D. Messages being sent between frames need to be URL-encoded

      Well, I agree that URL-encoded JSON is probably the best choice for the initial exchange for representation negotiation.  But I do believe that we should introduce the concept for representation negotiation as part of the OAH 1.1 standard.

      I am also wondering if there should be at least a place-holder for identity negotiation.  It may be too much for us to take on for 1.1 time frame.  But we should design the high-level protocol in such a way that identity negotiation can take place.

      In particular, it seems that there may be some reason for us to talk to folks at MIT Kerberos Consortium.  Single sign-on and secure mash-up are really hand and glove.  One is really made for the other.  

      E. Gideon, what were your performance numbers for XDDE? Order of 
      magnitude, I mean?

      For each fragment to be sent and acknowledged, XDDE needs two iframe location change.  (Like SMash A.com contains 2 B.com contains A.com).  On most browsers, it seems that we can get at most 10 location change per second.

      So I say the best we can expect is 50K going one-way.

      F. (your #3) That kind of clicking is a royal pain.

      Yes, 20Hz... ugh.  

      G. Development of applications for a sandboxed mashup still requires
      developers to be quite careful. Even if the mashup itself successfully 
      prevents iframe X from accessing the contents of iframe Y won't do 
      any good if iframe Y is vulnerable to CSRF attacks by X. 


      Best Regards,
      Howard Weingram

        From: security-bounces at openajax.org [mailto: security-bounces at openajax.org] On Behalf Of Gideon Lee
        Sent: Thursday, September 27, 2007 4:02 PM
        To: OpenAjax Alliance Security Task Force; interop at openajax.org
        Subject: [OpenAjaxSecurity] SMash questions and issues

        We have something overlapping SMash at the SameDesk project and we call it XDDE (Cross Domain Data Exchange).  I have a small demo at:
        I haven't looked at the SMash code closely.  But as I listened to the SMash presentation, here are some questions/issues that we may need to sort through as we work towards Hub 1.1: 

        1. What is SMash using to have the outer frame signal an inner frame to check window.location changes?
        XDDE has the parent frame resize the child frame, alternatiing between +1 and -1, for each subsequent "fragment".  The child frame has an onresize event handler for the document.body .

        2. Does the SMash protocol allows arbitrarily long message and allow either side to initiatiate the conversation? In XDDE, that's what we do to allow that...
        (a) We always break up a long message into fragments.  And in delivery, when one side sends a fragment to the other side, it always waits for an ACK(nowledgement) fragment from the other side before sending the next fragment. 
        (b) In a Parent-Child relationship, we want to allow either party to initiate a request-reply conversation.  So to make the +1/-1 trick work, we actually have 4-layer deep iframe enclosure A-B-A-B instead of the A-B-A pattern in SMash. 
        (c) A long message begins with a length and an encoding description of the data fragment, followed by zero or more data fragments, followed by an end of message checksum fragment.  The reason we have encoding description is that different data can benefit from different encoding strategy. 
        So in a way, the conversation pattern is sort of like HTTP over TCP rather than an bi-directional UDP.  

        3. Does SMash cause annoying click sounds in IE 7 when long message with many #fragmet are sent?  For a short message, a click-click may not be that annoying.  But if it is a long message with many fragments, XDDE is very annoying because it sounds like old typewriters gone mad. 
        BTW, since a fragment can contain at most around 4K characters, it doesn't really take a very long message before the click-clack-click-clack becomes annoying.

        4. Are there any performance benchmark on SMash yet?  Even with the iframe resize trick (which helps the inner frame to respond almost immediately without installing a window timeout), we found that XDDE is not exactly fast enough for the type of transfer we were trying to do.  

        How we optimize the protocol depends a lot on the higher level model. When we did XDDE, it wasn't built around single-directional PUB-SUB, but more a request-reply pattern.   

        5. So given OpenAjax Hub 1.0 currently allows JavaScript objects to be passed, I'd assume that we support try to achieve that with SMash-based cross-domain-data-exchange too.  How do we plan to encode a JavaScript object so that it can go across frames?  Do we encode it in JSON over UTF8 over Base64?  

        These are my top five issues.  I'm sure I can come up with more when we go down to the detail.  Overall, I like the SMash idea because it is secure.  But I think performance and user experience should not be totally hand waved either.  Otherwise, people will just keep doing unsafe JSON. 



      interop mailing list
      interop at openajax.org

    interop mailing list
    interop at openajax.org 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20070928/cbc11ae9/attachment-0001.html 

More information about the security mailing list