Re: Question about origin serialization

On Fri, 26 Sep 2008, Boris Zbarsky wrote:
> Ian Hickson wrote:
> > My understanding is that the specs now have just two functions (one 
> > for ASCII and one for Unicode). Is this not the case?
> No, because various places in the spec rely on different behaviors for 
> the non-triple origins.

True (e.g. document.domain), though I'm not sure if that's a real problem.

On Sat, 27 Sep 2008, Adam Barth wrote:
> What are the all the different string forms?  The two I'm aware of are:
> 1) postMessage's origin property
> 2) XHR's Origin header
> It seems like (1) and (2) could be made the same (modulo the ASCII-ness 
> of the Origin header) by having postMesasge use the string "null" 
> instead of "" for non-host origins.  Also, I think the behavior of 
> file:// URLs is slightly different as (1) uses "file://" and (2) uses 
> "null", but that seems like it could also be synchronized.

These both use the same definition now, I believe. (file:// processing is 
left up to the UA.) Non-scheme/host/port tuple origins serialize as the 
string "null".

On Sun, 28 Sep 2008, Boris Zbarsky wrote:
> In practice, we (Gecko) must be able to produce a string serialization 
> of all origins, because the Java security model relies on it.  (Yes, I 
> know I should have mentioned this before; I just did a search for places 
> where we actually stringify origins).
> I strongly suspect that returning an empty origin to Java would cause 
> security bugs, so we need to continue returning nonempty globally unique 
> strings there as needed.  I'd love to have proof that this suspicion is 
> wrong.
> The only remaining question is whether Java will see the same origins as 
> everything else; from a security standpoint this would be optimal, of 
> course.

Right now HTML5 defines that things that aren't scheme/host/port tuples 
are all serialized as "null". I guess we could define some sort of unique 
serialization, but I am very concerned that people would start deriving 
data from those origins or depending on them in some way.

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

Received on Monday, 20 October 2008 15:43:48 UTC