Re: Sub-origins

I am not particularly excited about the hashing proposal. It adds
complexity to the scheme that may discourage developers, and I do not see
it offering any clear benefits over other possible serializations.

For some context, the original proposal we started with relied on encoding
the suborigin as a part of a serializable URL; in the original draft, I
suggested something like "http://$suborigin.example.com/", where '$' would
be any character that is not allowed to organically appear unescaped in the
host name part. This greatly simplifies the proposal because it avoids all
the concerns about backward compatibility with same-origin checks, CORS
headers, postMessage event properties, all sorts of permission prompts, and
so on. However, it has the downside of mucking with the URL syntax.

One of the counterproposals was the scheme mentioned by Joel,
"http+suborigin://example.com/". This approach has a higher likelihood of
creating incompatibilities - for eample, a server that only looks at the
host name field (but not the protocol) to permit or reject CORS requests,
could be in trouble. It also seems like a bad abuse of that part of the URL.

Since we expected this to come up in a public discussion anyway, we settled
on a clean but not backward-compatible approach of serializing the origin
as null in several specific cases, and exposing the suborigin data via a
separate channel. I agree that this carries some interesting risks.

/mz