W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2013

Serialized suborigins

From: Joel Weinberger <jww@chromium.org>
Date: Wed, 11 Sep 2013 16:21:14 -0700
Message-ID: <CAHQV2KkuszYSNJHG3Td0YS7tQZQtjqwhvoH2983G__GnELG-_Q@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi everyone. In our earlier thread, it seemed to me that we were converging
to an agreement that serialized suborigins are probably the best approach
to make sure suborigins fail closed. Of course, what that serialization
should look like is what really seems to be up in the air right now.

After talking with Adam Barth, we both agree that Brad's hashing proposal
has a lot of great advantages. Of course, as Michal pointed out, it also
isn't particularly developer friendly. Here's a quick set of suggestions
that Adam and worked out that I think eases some of the concerns.

We propose that we represent serialized suborigins as follows:
where the suborigin is a protocol literal, PORT is a standard origin port,
and HASH is a hashed combination of the host name and suborigin string.
Obviously, this is basically Brad's proposal, although we thought it was
important to make sure to keep a protocol and port in the representation.

Furthermore, we propose for a number of built-in functions to take care of
suborigins for the developer. The goal is basically that a developer should
never see (and certainly never write) a HASH value. The main API that comes
to mind is:

location.suborigin(name, [domain]) which returns a suborigin HASH value for
the suborigin named by name. If no domain is specified, returns the value
for the current domain, otherwise calculates it for the named domain.

This way, a developer never has to see or calculate these in client. When
checking one, it should be as simple as:
if (e.origin == location.suborigin("foo", "some.domain")) {

Of course, there are a variety of ways to go from here. Adam pointed out
that this actually has the interesting property that if you receive a
message from a suborigin, and the suborigin doesn't name itself, you can't
know a priori who sent the message. We could consider this a "good thing,"
but if we don't, we could always keep track of generated suborigin HASH
values in browser and provide an API call
location.lookupSuborigin(suborigin) which takes a suborigin value, looks it
up in browser, and returns a (domain, suborigin_name) pair.

In terms of the actual suborigin value, we define it as SHA256

Like I said, I like Brad's suggestion a lot, so I tried to write up a
slightly more formal version here. Thoughts?
Received on Wednesday, 11 September 2013 23:21:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:02 UTC