Re: Sub-origins

I'm not particularly worried about the "guessability" issue since the only
way to enter a suborigin is if the server at that origin gives you that
name. Thus, there really isn't a way for an off-origin resource to enter
the suborigin anyway.

I don't object to the hash proposal, although I'm basically with Dev that
if we're really concerned about having a single string, I'd rather encode
it in a more legible way, such as "http+suboriginname://foo.com".

What are the particular external components that use a fixed-size
representation that you are concerned about? Various plugins? Because they
won't be allowed in suborigins anyway.

My basic view is that it's worth making the clean separation in
origin/suborigin both for legibility and simplification. That having been
said, I have admittedly little experience writing serious, big web
applications, so it's very possible I don't appreciate the complexity
adding the "split origin" (for lack of a better term) will cause. I've CC'd
Adam Barth and Michal Zalewski on this in the hopes that they might have a
more articulate thought on this.
--Joel


On Mon, Aug 26, 2013 at 4:14 PM, Brad Hill <hillbrad@gmail.com> wrote:

> I absolutely think that the generation should be standardized so it can be
> reproduced identically by servers and across-browsers (think WebRTC, as
> well).
>
> I worry that adding additional internal structure will produce the same
> failure modes in legacy components unaware of the structure that adding a
> second value would.
>
> There is also some smalle value for external components that use a
> fixed-size representation of an origin (granted that's not completely
> possible due to unknown size of scheme, but say they assume it will only be
> either http, https, etc) to have suborigins fit within that buffer.
>
>
>
> On Mon, Aug 26, 2013 at 3:54 PM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:
>
>> One problem I see is that this identifier (may it be origin +
>> suborigin-label, or the HMAC as you suggest) needs to be shared by the
>> server (for CORS) as well as the client (for postMessage). Helper
>> functions would work if this was only a client-side trait.
>>
>> But, since we want CORS APIs to also use this, the server has to
>> understand (and possibly generate) these identifiers. That means we
>> would need to standardize on the HMAC function (at least the hash
>> function). I am not sure we want to head down that path.
>>
>> If we really really want a single string for the origin (instead of
>> two), then figuring out a way to include the sub-origin in the URI
>> seems better than trying to standardize an HMAC.
>>
>> thanks
>> dev
>>
>>
>>
>>
>>
>> On 26 August 2013 15:42, Brad Hill <hillbrad@gmail.com> wrote:
>> > I imagine that there might be a helper function defined, or that
>> developers
>> > could do it themselves, or that you could have API sugar that helps out.
>> >
>> > -Brad
>> >
>> >
>> > On Mon, Aug 26, 2013 at 3:39 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
>> > wrote:
>> >>
>> >> > Content-Security-Policy: sandbox suborigin:'isolateme'
>> >> >
>> >> > Where the result of this is to set the origin representation to an
>> >> > HMAC_SHA256 of the origin with "isolateme" as the key.
>> >> >
>> >> > This gives the ability to developers to create convenient names for
>> >> > arbitrary groupings of site functionality, makes it extraordinarily
>> >>
>> >> I imagine that this is what an implementation might do. I am curious
>> >> about how developers would use it. For example, in an API like
>> >> postMessage where the developer has to name and use the origin (or in
>> >> CORS), the current proposal requires the developer to say
>> >> "{origin.com, isolateme}". Do you envision the developer writing this
>> >> HMAC value in the target origin field?
>> >>
>> >> thanks
>> >> Dev
>> >
>> >
>>
>
>