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

Re: [suborigins] serializing of origins

From: Aleksandr Dobkin <dobkin@google.com>
Date: Tue, 11 Apr 2017 17:55:52 +0200
Message-ID: <CAJGyu7Uy38bzZOoZqhf3O1_EN_64vsBSxQPrVmd-U9xw+kJVaw@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Jochen Eisinger <eisinger@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Jochem, are you not happy more with the specific syntax or the general idea
of extending the origin string?

Separate origin/suborigin attributes in the MessageEvent object are
workable, but seem like a little bit more when converting legacy code
compared to the existing solution.

On Tue, Apr 11, 2017 at 12:00 PM, Mike West <mkwst@google.com> wrote:

> +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/` <https://example.com/> with a suborigin of `foo`
> tries to `postMessage()` to another page on `https://example.com/`
> <https://example.com/>, then simply checking the message's `origin`
> attribute against `https://example.com/` <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
Received on Wednesday, 12 April 2017 15:07:06 UTC

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