Re: Serialized suborigins

Regarding ports, I just meant to include the port somewhere since we ought
to support non-port 80 HTTP, etc. Didn't mean that to convey anything
beyond the regular scheme/host/port origin combination. Other comments are
inlined below.


On Thu, Sep 12, 2013 at 12:03 PM, Michal Zalewski <lcamtuf@coredump.cx>wrote:

> Hey,
>
> Honestly, I'm a bit struggling to understand what's the key benefit of
> doing suborigin://hashed-concat versus suborigin://non-hashed-concat -
> in that both of these representations will not be literal string
> matches for any existing origin if done sensibly (and using a literal
> suborigin:// further alleviates most fears).
>
One of the concerns brought up earlier is origin comparisons by non-browser
entities and trying to avoid matches at all cost. I agree that it seems
unlikely to get a match in a plugin, for example, if we did a
non-hashed-concat representation, but as I see it, why risk it? I could see
some crazy world in where somewhere deep in Flash, it does an origin
comparison that somehow skips whatever delimiter we have in place. But
you're right, I'm not too worried about it, so I'm certainly not tied to
the hash example.

>
> In either case, I think that keeping the communications between
> origins simple and intuitive should be a goal for both approaches.
> Perhaps base64 or rot13 is indeed a better idea.
>
Agreed, and either of those sounds good to me. Hashing just came to mind
first, but, yeah, both of those have properties that probably better
support what we care about.

>
> I agree with Brad's concern about having to preserve protocol, perhaps
> as a part of the hash.
>
Absolutely, and that was just an error in my proposal.  HASH really should
be a combination of *protocol*, hostname, and suborigin.

>
> /mz
>