Re: [suborigins] serializing of origins

For context, I believe the most comprehensive discussion of suborigin
serialization happened in https://github.com/w3c/weba
ppsec-suborigins/issues/38 though IIRC most of it revolved around *how* to
serialize, rather than "why".

On Tue, Apr 11, 2017 at 10:08 PM, Jochen Eisinger <eisinger@google.com>
wrote:

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

In general I agree with the goal of not displaying any user-visible signs
that an application is in a suborigin; it's an implementation detail that
we don't need to expose. If omitting serialization is necessary to
accomplish this, so be it.

For developers, it will be ever so slightly more cumbersome to work with
suborigins if we do this. For example, if we make the `origin' of a message
from a suborigin `null`, then developers will have to inspect different
objects to learn about the sender of the message. If your suborigin uses
'unsafe-postmessage-send' then the receiver of the message can check
event.origin as usual; otherwise, they'll have to inspect
event.initiator.{origin,suborigin}. That's not too big of a deal, though,
and as Mike notes it shouldn't be a problem for CORS. The few other places
where developers tend to interact with the serialized origin
(location.origin) and which can't be easily changed to use an object should
also be okay.

Overall, my main reservation about the serialization discussion is that its
outcome isn't likely to solve any problems developers have, but they are
dependent on its outcome to know how to refactor their applications. At the
same time, if it leads to a more extensible notion of an origin that we
can, for example, make compatible with Mozilla's containers or other
similar ideas in the future, it's probably worth settling this now. So
given that neither approach seems terrible my suggestion would be to pick
the one that makes the most sense to you (likely what Jochen outlined in
the original post) and go with it.


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