Re: Sub-origins

I would just caution against being too casual about considering the browser
the only citizen of the SOP ecosystem, even if you happen to think the
recent history of such was misguided.

For an example of a protocol encoding and comparing origins, consider
"Universal 2nd Factor" (previously known as Gnubby) which Google is leading
the development of.
https://docs.google.com/document/d/1Jm_xAJTZGulMOkYOQm-fIQhhkd2VDr9578oh0KOwcEw/edit#heading=h.q5kqrl82hzpj

And also consider the rich extension ecosystem for Chrome utilizing origins
for security isolation.
https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final177_0.pdf

And the set of cross-origin attacks on mobile platforms recently explored
by MSR, and their proposed mitigation using an origin indication:
http://research.microsoft.com/pubs/200406/ccs127-wang.pdf

I'm interested in exploring a way to encode suborigins as first-class
citizens of URL space a bit further as an alternative to the hash scheme,
since the single-value URL is the near-universal means of communicating
resource information with embedded security boundaries between the various
pieces of the web ecosystem.


On Thu, Aug 29, 2013 at 8:53 AM, Michal Zalewski <lcamtuf@coredump.cx>wrote:

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