[OpenAjaxSecurity] SMash questions and issues

Gideon Lee glee at openspot.com
Fri Sep 28 10:42:14 PDT 2007


Sumeer,

Thanks.  I think I answered most of the questions you posted in my response to Howard and Kris so I won't repeat them here.  On your question of resize causing repaint -- I'm pretty sure it does.  But it still seems to be faster than setting a fixed interval timeout.  Furthermore, IE in particular seems to be dragged to its knees when more than a few iframes start to run fixed small interval timeout. 

I'll check in our XDDE library into sourceforge next week so you can take whatever you like.

Thank you, Bertrand, for referring the click-sound issue to IE team. 

Gideon

  ----- Original Message ----- 
  From: Sumeer Bhola 
  To: OpenAjax Alliance Security Task Force 
  Cc: interop at openajax.org ; OpenAjax Alliance Security Task Force ; security-bounces at openajax.org 
  Sent: Friday, September 28, 2007 1:19 PM
  Subject: Re: [OpenAjaxSecurity] SMash questions and issues



  Gideon, 
  Responses to your questions, in blue below. 

  Sumeer (for the SMash team) 




        "Gideon Lee" <glee at openspot.com> 
        Sent by: security-bounces at openajax.org 
        09/27/2007 07:02 PM Please respond to
              OpenAjax Alliance Security Task Force <security at openajax.org> 


       To "OpenAjax Alliance Security Task Force" <security at openajax.org>, <interop at openajax.org>  
              cc  
              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: 
  http://www.samedesk.com:23460/~0.0.0/webhost/com.openspot.webhost.OResource/com/xdde/demo3/system.html 
  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. 

  SMash currently uses timers to poll the window.location value to detect if there is an incoming message. The timer interval is currently fixed to 10ms, though we have discussed the possibility of it being application configurable, and also making it adaptive (for example, faster timers when a message transmission is ongoing, or when we know the communication pattern, like request-response). 
  The XDDE resize approach sounds like a good alternative, and its probably worth comparing the performance (latency, throughput and CPU load). One question regarding that is whether the resize would trigger the rendering engine every time a resize happened. 
    
  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.   

  SMash does allow arbitrarily long messages, by breaking them up (in a manner similar to the Dojo XhrIframeProxy), and both the parent or child can initiate a message. Based on your description, the protocols seems similar, but there are some low-level differences: we don't send the length or encoding description. We do number the messages since we want to prevent a message integrity attack where an attacker overwrites a URL fragment with the empty fragment, thereby deleting part of a message that has been broken up into multiple messages. 
  The encoding aspect is where SMash is weak. We have debated doing URI-encoded JSON, but as of now the messages are just URI-encoded. Perhaps XDDE could contribute code to the sourceforge project for this? 
    
  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. 

  Yes, unfortunately it does cause those annoying click sounds on IE7. It is probably not a big issue for small and occasional data transfers that are triggered by user actions, which may be an important use case (navigation actions are the cause of the clicks in IE7, so users who haven't turned off that sound have a reasonable threshold for hearing them when they do something). 
    
  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. 

  Do you have a specific benchmark for XDDE? We are currently doing a performance evaluation of SMash and it would be good to have an idea of what kind of data is transferred in your application scenario. 
    
  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? 

  Passing JSON seems like a reasonable option. Arbitrary JavaScript, i.e., containing code as well as data, may not be a good idea, even if one could implement it. 
  We could look at the existing proposals or implementations for cross-domain communication within the browser and use that as a starting point for the discussion. The <module> tag proposal by Douglas Crockford uses JSON, while the HTML 5 proposal by WHATWG uses a DOMString (so it could be any format). 
    
  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. 
    
  Gideon 
    
    
    
    
    
    
    
    
    
    
    
    
   _______________________________________________
  security mailing list
  security at openajax.org
  http://openajax.org/mailman/listinfo/security




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


  _______________________________________________
  security mailing list
  security at openajax.org
  http://openajax.org/mailman/listinfo/security
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20070928/9caa2941/attachment.html 


More information about the security mailing list