Re: postMessage: origin serialized too early

On Wed, 5 Aug 2009, Thomas Roessler wrote:
> 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.

I think exposing data about the system state is an antipattern best 
avoided, personally, even if there are theoretically ways to do it right.


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

We can end up with people depending on the order that numbers are 
generated in, or we can end up depending on particular bugs in 
implementations, or any number of other things. I can't predict in advance 
what the problems would be. I agree that this is not a rational argument; 
I'm just saying that in my experience on the Web, exposing numbers like 
this is the kind of design that can lead to weird problems later, and so 
we should only do it if we have really clear and compelling use cases. I'm 
not convinced we do in this case.

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

Received on Thursday, 13 August 2009 23:27:51 UTC