Re: [suborigins] serializing of origins

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