Re: postMessage: origin serialized too early

On Wed, 27 May 2009, Thomas Roessler wrote:
>
> Background:
>   http://krijnhoetmer.nl/irc-logs/webapps/20090527
> 
> 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.

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.
 
(It would also make it impossible to generate custom events of that type.)

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

Received on Friday, 12 June 2009 00:25:15 UTC