Re: [suborigins] serializing of origins

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
>>>
>>
>>
>