Re: [suborigins] serializing of origins

I dunno, my feeling is that we should cross that bridge once there's
actually a use case.

On Wed, Apr 19, 2017 at 9:01 PM Devdatta Akhawe <dev.akhawe@gmail.com>
wrote:

> Yup. My point is that UAs, other specs, web devs, might find it useful to
> serialize. We should try to write the spec without using the serialization
> but we should still define it so that we have something standard that
> others can use. I worry that leaving it undefined means that someone
> somewhere will come up with a scheme of their own which doesn't match what
> someone else came up with.
>
> On Apr 19, 2017 6:28 AM, "Jochen Eisinger" <eisinger@google.com> wrote:
>
> I can see that argument that if something in the codebase serializes the
> origin and we forgot about adopting it, it might just fall over and not
> grant access. However, there are also many places where we just serialize
> the origin and use it as a string, e.g., in the UI. So in the end, we have
> to audit the entire code base anyways..
>
> On Wed, Apr 19, 2017 at 5:24 AM Deian Stefan <deian@intrinsic.com> wrote:
>
>> On Tue, Apr 18, 2017 at 8:10 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
>> wrote:
>> > 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.
>>
>> Yeah, that came up in my conversation with Joe as well. It seemed like
>> internally,
>> the serialization makes it easier to not forget a place to check
>> suborigins where
>> origins are checked. If the implementation without serialization is
>> not too much more
>> complicated I'd +1 that we can make it easy for us to piggyback the
>> cowl label checks.
>>
>> -deian
>>
>>
>