W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: postMessage: origin serialized too early

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 5 Aug 2009 10:29:38 +0200
Cc: Thomas Roessler <tlr@w3.org>, public-html@w3.org
Message-Id: <88DCE365-DD73-4249-9E6B-EFDB8BF8F383@w3.org>
To: Ian Hickson <ian@hixie.ch>
On 29 Jul 2009, at 02:44, Ian Hickson wrote:

> In practice, random numbers expose data about the system state,  
> which is
> one reason it's generally best to be more opaque.

Not a problem to worry about here, in the sense that it's regularly  
solved elsewhere.

>>>> (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.
> I agree that this might introduce problems, but I think in practice  
> it is
> just as likely to introduce problems if we actually expose some unique
> number than if we don't

How so?

Digging a bit deeper, the properties you need from string  
serializations of origins isn't even that they are unguessable --  
they're guessable all the time on the Web --, but that they are  
distinct from each other.  Therefore, whatever an opaque origin is  
serialized to needs to actually:

- be distinct from any possible non-opaque origin (you can achieve  
that by never having a ':' in there)
- be distinct for any two different opaque origins, and be the same  
each time for the same opaque origin object

One can achieve that even with simple sequence numbers (though these  
*really* leak state); there's any number of technologies that an  
implementation can take there.

As far as the spec is concerned, all it needs to say is that an opaque  
origin is serialized to a string, what the character repertoire is for  
that string, and that no two different opaque origins can be mapped to  
the same string.  How implementors choose to deal with that is up to  
them, but one could certainly have some guidance about random numbers,  
one-way functions, and whatever other fancy bells and whistles one  
would want to add.

> I'm not at all comfortable with exposing this data in a way that can  
> be
> shared around, and since the use cases are very minimal, I'd rather  
> just
> not worry about it and continue returning "null".

Any reason for your discomfort? (In particular given that origins on  
the Web can be shared around all the time.)
Received on Wednesday, 5 August 2009 08:29:49 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:49 UTC