[OpenAjaxSecurity] [OpenAjaxInterop] Cross-Frame Messaging (was SMash questions and issues)
sbhola at us.ibm.com
Fri Sep 28 11:24:50 PDT 2007
interesting discussion. A couple of questions/comments:
- I don't quite understand the performance implications of full-duplex
versus two one-way channels. Since the browser modification proposals are
for asynchronous messaging, and that is also what we can implement using
fragments, it seems natural to require that the lower-level API support
asynchronous messaging in both directions.
- One issue with the channel/pipe abstraction offered by the lower-level
API is privacy. With SMash, the main mashup application can listen on any
channel, so it is not possible to implement private point-to-point
channels between two arbitrary frames in the mashup. If the HTML 5
proposal is implemented by browsers, this would be possible.
- Regarding standardizing the protocol itself, for example, the exact
fragment formats that SMash and XDDE use, it might be useful. On the other
hand, as these are hopefully temporary hacks till we get browser support,
it may not be worth too much effort. At minimum, we should document the
protocol names, so that different entities can communicate with each other
if they use the same protocol name. For instance, the SMash protocol could
be used by the hub, if the scheme in the hostname used in the
OpenAjax.hub.connect call referred to SMash.
"Gideon Lee" <glee at openspot.com>
Sent by: security-bounces at openajax.org
09/28/2007 10:48 AM
Please respond to
OpenAjax Alliance Security Task Force <security at openajax.org>
"OpenAjax Alliance Security Task Force" <security at openajax.org>,
<interop at openajax.org>
Re: [OpenAjaxSecurity] [OpenAjaxInterop] Cross-Frame Messaging (was SMash
questions and issues)
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.
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
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
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.
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
(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
(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
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
passed, I'd assume that we support try to achieve that with SMash-based
object so that it can go across frames? Do we encode it in JSON over UTF8
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
security mailing list
security at openajax.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the security