Re: [suborigins] serializing of origins

+Dev, who I hope will have informed opinions about how Dropbox would like
to be using suborigins.

I think getting rid of the serialization change would be a win. The new
scheme has caused some weirdness in Blink's implementation, especially its
integration with other layers of the system that shouldn't really need to
know anything about suborigins.

Dev will correct me, I hope, but AFAIK the goal of the serialization scheme
is to ensure that applications that are not suborigin-aware fail closed
when a suborigin tries to talk to them. That is, when `https://example.com/`
with a suborigin of `foo` tries to `postMessage()` to another page on `
https://example.com/`, then simply checking the message's `origin`
attribute against `https://example.com/` should fail. Likewise for `origin`
header checks.

Another approach to those two cases would be what you suggest at the end of
your email: set the `origin` attribute of a `MessageEvent` from a suborigin
to `null` (not the string "null", but the object `null`), and add more
attributes to allow folks to do reasonable comparisons. It strikes me that
the `initiator` property you're suggesting might also be an opportunity to
stuff the `domain` into the `MessageEvent`, which might be independently
valuable. Hrm.

For the `Origin` header, it seems like we're already failing closed if
`Access-Control-Allow-Suborigin` isn't present in the response, right? If
that's the case, then why not add a `Suborigin` header to the request? (I
think this is basically what issue 11 in the spec is suggesting).

-mike

On Fri, Apr 7, 2017 at 10:11 AM, Jochen Eisinger <eisinger@google.com>
wrote:

> Hey all,
>
> I started to look at our suborigin implementation in blink, and one of the
> things I was stumbling over was the serialization of an origin with a
> suborigin, i.e. (scheme, host, port, suborigin) getting serialized to
> ${scheme}-so://${suborigin}.${host}:${port}/
>
> It seems that the main reason for doing this is to break postMessage for
> code that is not aware of suborigins. Is that the case?
>
> If that was the case, have we considered other ways to break this, e.g.
> make origin return the null value and add instead a new property to message
> (e.g. initiator with two properties origin and suborigin)?
>
> best
> -jochen
>