[suborigins] serializing of origins

# Jochen Eisinger (a month ago)

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

Contact us to advertise here
# Aleksandr Dobkin (a month ago)

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.

# Mike West (a month ago)

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

# Aleksandr Dobkin (a month ago)

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.

# Jochen Eisinger (a month ago)

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.

# Artur Janc (a month ago)

For context, I believe the most comprehensive discussion of suborigin serialization happened in 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 suboriginnull`, 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.

# Devdatta Akhawe (a month ago)

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

# Deian Stefan (a month ago)

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.

# Jochen Eisinger (a month ago)

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

# Devdatta Akhawe (a month ago)

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

# Jochen Eisinger (a month ago)

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:

Want more features?

Request early access to our private beta of readable email premium.