Re: postMessage: origin serialized too early

On 11 Jul 2009, at 01:29, Ian Hickson wrote:

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

That certainly helps, even though it's still surprising that  
window.postMessage() will fail under these circumstances.

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

So, moving away from the concrete use case, the (also soft) counter- 
arguments are:

1. Serializing two objects that don't compare as equal when it really  
matters (i.e., two distinct unique origins) to the same string feels  
like the kind of thing that, too, might lead to problems later on.

2. Long random numbers are commonplace in cryptographic protocols and  
don't cause trouble there -- why should they cause trouble here?  (In  
fact, you probably don't even need hard-to-guess numbers here --  
unique identifiers that cannot otherwise occur as origins should be  
enough for the security properties you're looking for here.)

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

+1 to "serialize to something" -- though, as noted above, the idea  
that two significantly distinct objects serialize to the same string  
strikes me as likely to cause trouble.

Received on Tuesday, 14 July 2009 13:49:32 UTC