Re: postMessage: origin serialized too early

On Sun, 14 Jun 2009, Thomas Roessler wrote:
> > > 
> > > In HTML5, section 8.2.3, point 5, mandates that the origin attribute 
> > > of a MessageEvent event must be set to the unicode serialization of 
> > > the origin of the script that invoked postMessage.  That implies 
> > > that an opaque origin is serialized to the string "null" here.
> > > 
> > > As a consequence, when the event is handled, it is *not* possible to 
> > > set the targetOrigin parameter of a possible response message to a 
> > > value that would bind it to the original message's sender, if that 
> > > sender has an opaque origin.
> > > 
> > > Remedy: the origin attribute of an event of type MessageEvent ought 
> > > to behave like a proper origin, even if it is an opaque one; i.e., 
> > > be comparable to other opaque origins in the same-origin check, and 
> > > serialize to "null". Serialization should not occur when the 
> > > attribute is constructed.
> > 
> > This would require constructing an opaque JS object that represents an 
> > origin. This has never been exposed before. Do we really want to do 
> > this? What is the use case? The only cases on the Web where this can 
> > happen seem to be cases like data: URIs generating custom 
> > subdocuments, but that seems like a very strange edge case. In such 
> > cases, scripts can just communicate directly anyway.
> 
> Communicating out of (and back into) sandboxed iframes comes to mind as 
> the other use case, besides the widget work.

For that case, just send a MessagePort with your first message, and then 
use MessagePort communication instead of window.postMessage().


> > I think it would make more sense to wait until we have a clear need to 
> > do this before adding this feature. We can always retrofit it by 
> > making the objects serialise to a string.
> 
> So, what's the downside to serializing opaque origins into long random 
> numbers that can in turn be compared to them?

I don't know that I have a good reasoned downside. It strikes me as, well, 
ugly, though. It also seems like the kind of thing that would lead to 
problems later, though I don't have rational reason for this impression.


> (Or, put differently, what - besides CORS and the Origin proposal - is 
> the use case for serializing opaque origins into "null" throughout 
> HTML5?)

It's not a feature; there's no use case for it. It's just that we have to 
serialise to something to keep everything well-defined.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 10 July 2009 23:29:54 UTC