Re: Sub-origins

Just to throw this out there, I believe most of Adam and my objections to
Michal's serialized version of suborigins are around usability. However, I
think we probably alleviate most of that my simply requiring in the spec
that they never appear to a user (that is, a frame URL will always appear
in UI elements without the suborigin).

However, if I'm not mistaken, this brings a whole other set of legacy
problems. Part of the goal of the separate, structured suborigin was that
legacy browsers and servers looking in the traditional origin space would
see a normal origin (in the case of httpheaders) or nothing (in the case
of postMessage). However, in any of these serialized versions, a legacy
application will now see something that's *almost* a normal origin, but not
quite. That seems like a dangerous proposition in it's own right.

Perhaps I'm missing something, though. Brad, is this not a concern of
yours? How would we expect a legacy browser,  for example, to gracefully
handle a hash origin or http://foo$bar.com origin?
On Aug 29, 2013 9:42 AM, "Brad Hill" <hillbrad@gmail.com> wrote:

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