W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2017

Re: [suborigins] serializing of origins

From: Mike West <mkwst@google.com>
Date: Tue, 11 Apr 2017 12:00:52 +0200
Message-ID: <CAKXHy=dawDBqvmMMtBXYXEzz4ZHyUAPVAoTswcaShWt-Thy-2w@mail.gmail.com>
To: Jochen Eisinger <eisinger@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
+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).


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

> 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
Received on Tuesday, 11 April 2017 10:01:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:00 UTC