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

Re: [suborigins] serializing of origins

From: Jochen Eisinger <eisinger@google.com>
Date: Tue, 11 Apr 2017 20:08:39 +0000
Message-ID: <CALjhuifWDp+Z3_-wMQAZUOYacw+DS-xN10C-m-egvOQnGPua7Q@mail.gmail.com>
To: Aleksandr Dobkin <dobkin@google.com>, Mike West <mkwst@google.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
I'm unhappy about the general idea of extending the origin string, as it
creeps into everything, including the browser UI, and I'd rather not bother
users with the serialization of a suborigin.

e.g. right now, the serialized origin shows up in all cookie & site data
related UI, which is surprising given that you never saw an URL of that
format in your location bar.

On Tue, Apr 11, 2017 at 5:55 PM Aleksandr Dobkin <dobkin@google.com> wrote:

> 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 Tuesday, 11 April 2017 20:09:27 UTC

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