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

Howard Weingram weingram at tibco.com
Fri Sep 28 09:15:17 PDT 2007


We're in the mobile ajax session right now. I definitely intend to
comment but my comments will be delayed. :-)
 
Best Regards,
Howard Weingram


________________________________

	From: security-bounces at openajax.org
[mailto:security-bounces at openajax.org] On Behalf Of Gideon Lee
	Sent: Friday, September 28, 2007 7:49 AM
	To: OpenAjax Alliance Security Task Force; interop at openajax.org
	Subject: Re: [OpenAjaxSecurity] [OpenAjaxInterop] Cross-Frame
Messaging (wasSMash questions and issues)
	
	
	My thoughts in blue.

		----- Original Message ----- 
		From: Howard Weingram <mailto:weingram at tibco.com>  
		To: OpenAjax Alliance Security Task Force
<mailto:security at openajax.org>  ; 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
		JSON. 
		 
		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.

		 
		Right.
		 
		 
		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:
	
http://www.samedesk.com:23460/~0.0.0/webhost/com.openspot.webhost.OResou
rce/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.
			 
			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.
			 
			Gideon
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 
			 

		
________________________________


		

		_______________________________________________
		interop mailing list
		interop at openajax.org
		http://openajax.org/mailman/listinfo/interop
		

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


More information about the security mailing list