Re: [suborigins] serializing of origins

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