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

Re: [suborigins] serializing of origins

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Tue, 18 Apr 2017 20:10:02 -0700
Message-ID: <CAPfop_1QE2LD1O4dDL-hxthM2mGKuSbZJwFOn+bHii42nBhmGg@mail.gmail.com>
To: Aleksandr Dobkin <dobkin@google.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>

[sorry for the delay; missed this thread by mistake]

My recollection of why we have suborigin serialization is that origins
as strings do tend to pop up in many places. @joel can correct me but
I believe it also made some things on the browser side easier. I don't
recall us (as in Dropbox) needing the serialization in particular: if
postMessage and CORS provides the suborigin, we should mostly be good.

My gut still says that we should have a serialization defined for
others to use if they want, but the spec shouldn't really need to use
it. The spec can define out how to grab the suborigin in common cases
like CORS, postMessage, etc. If we miss something, we can initially
rely on the suborigin serialization.


On 10 April 2017 at 06:34, Aleksandr Dobkin <dobkin@google.com> wrote:
> The serialized origin also makes an appearance in the Origin header in
> cross-domain XHRs and fetches. But, yes, I think the big driver of the
> particular syntax is being safe with with origin-checking content that is
> not aware of suborigins.
> Are you not happy with the specific syntax or the general idea of extending
> the origin string to include an additional element?
> The serialization does seem clunky, but I'm not sure the alternative are
> very much better.
>> 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, 19 April 2017 03:10:56 UTC

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