Re: postMessage: origin serialized too early

On 12 Jun 2009, at 02:20, Ian Hickson wrote:

> 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.

Communicating out of (and back into) sandboxed iframes comes to mind  
as the other use case, besides the widget work.

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

> (It would also make it impossible to generate custom events of that  
> type.)

(I don't have a particular preference between origins as opaque  
objects and opaque origins that serialize into long, random strings;  
what I do care about is the symmetry breach that occurs in postMessage.)

Received on Sunday, 14 June 2009 10:16:16 UTC